MNEMOS + MIF alignment: contributing the MemPalace migration guide

[perlowja]

Hi Robert —

I've spent the last several months building MNEMOS (https://github.com/mnemos-os/mnemos), a self-hosted Postgres+pgvector agent memory system. Last week I extracted my own memory-portability format from it (mnemos-os/mpf), then discovered MIF a few hours after publishing — same problem space, your work is more comprehensive than mine, and the cognitive-triad grounding (Tulving / Cohen & Squire) is the right academic foundation. Your ADR discipline is excellent.

Rather than fork the ecosystem, I'd like to contribute. Two things:

1. Concrete first contribution: write the MemPalace migration guide + bidirectional converter.

MemPalace has 49k+ stars and an open thread asking for portability tooling (MemPalace/mempalace#1112) — there's an immediate audience for this work. I'll target Level 3 conformance with PROV provenance, bi-temporal tracking, and proper memoryType classification.

2. Distribution.

I have working channels into Linux Foundation AI & Data and prior connections to GitHub OSPO. If MIF is going to graduate from "founder-led spec" to "ecosystem standard," it'll need a path through one of those bodies. I can help shape that path when the time is right — not now, but in the v0.2 → v1.0 trajectory.

Questions before I start:

• Migration guide convention: I see Mem0 / Zep / Letta / Subcog / Basic Memory listed in MIGRATION-GUIDE.md with prose. Do you want the MemPalace section to be prose-only, or are you accepting working Python tools alongside the prose?
• For dual-format output, are there reference converter utilities in scripts/ I should build on, or does each migration guide ship its own?
• MemPalace's hierarchical Wing / Room / Hall structure is structural, not functional — mapping it to semantic / episodic / procedural needs a judgment call. I'll propose a default but want your read on it.
• Test vector conventions — happy to ship canonical MemPalace exports as round-trip fixtures.

If MemPalace lands well I'd follow with MNEMOS itself — but one at a time, and MemPalace first because of the open community thread.

— Jason (@perlowja)

[perlowja]

Following up on this with concrete offers, in order of what I think is most valuable to MIF — happy to do any subset, all of them, or none if they don't fit your direction.

The work below is already done in MNEMOS / MPF; contribution is mostly about adapting to MIF's shape, not net-new engineering.

Reference material at https://github.com/mnemos-os/mpf — parallel JSON envelope spec I shipped before discovering MIF, intentionally simpler than yours. The bits flagged below are where MNEMOS's experience exceeds what's in MPF v0.1.

---

1. Edge-case test vectors from a 70-round adversarial review

MNEMOS's CHARON portability subsystem went through 70+ rounds of multi-shot adversarial review (Codex, mostly) over the past several weeks before we shipped v0.2. The review caught real bugs — not syntax-level findings but semantic ones an importer at scale would hit:

• Cross-tenant validation on sidecar record_id (a malicious envelope could attach a sidecar to a memory belonging to a different owner)
• Retry idempotency under partial-commit failures (per-row SAVEPOINT pattern; tracking inserted_record_ids for post-verify)
• Snapshot consistency for export (REPEATABLE READ READ ONLY transaction wrapping memories + all sidecar fetches)
• DoS bounds on sidecar export (hard cap with LIMIT cap+1, return 413 on overflow)
• Trigger-guard interaction with batched DELETE (charon-trigger-guard migration; session-GUC-gated cleanup)
• Topological-sort requirements on memory_versions DAG import (parent must land before child)
• COALESCE-tolerance for sidecar timestamps with naive datetime handling
• ~30 more

I can distill these into spec-shaped test vectors for vectors/. Each vector is "envelope shape that exercises edge case X, expected behavior Y." Format-agnostic — a MIF implementation will hit the same edge cases as MPF's. This is probably the highest-leverage contribution: months of someone-else's-bug-hunting in a few hours of your reviewing.

2. Compression manifest sidecar specification (Level 3 gap)

Your spec mentions compression sidecars at Level 3 but the shape is undefined. MNEMOS has a working model:

{
  "compression_manifest": [
    {
      "id": "cmp_001",
      "memory_id": "mem_001",
      "engine": "apollo",
      "engine_version": "s-ivb-1.0",
      "original_content_hash": "sha256:...",
      "compressed_content_hash": "sha256:...",
      "compression_ratio": 0.42,
      "quality_score_original": 75,
      "quality_score_compressed": 92,
      "winner_candidate_id": "cnd_xyz",
      "judge_decision": "compressed_wins",
      "created": "2026-04-26T10:00:00+00:00"
    }
  ]
}

Key invariant: a compressed candidate replaces the live row only after passing a quality floor (judged by an LLM or rule-based scorer). The manifest preserves the lineage so operators can audit "which engine compressed which memory, and was the decision sound?"

If MIF wants this, I can write the spec section + JSON Schema addition + reference test vectors.

3. Memory-version DAG sidecar (complement to PROV / bi-temporal)

MIF's bi-temporal model (transaction time vs valid time) tracks WHEN. A version DAG tracks WHAT — the actual edit chain. They're complementary.

MNEMOS's shape:

{
  "memory_versions": [
    {
      "id": "ver_001",
      "memory_id": "mem_001",
      "version_num": 1,
      "branch": "main",
      "commit_hash": "0000...0001",
      "parent_version_id": null,
      "merge_parents": null,
      "content": "first version content",
      "snapshot_at": "2026-01-10T09:00:00+00:00",
      "snapshot_by": "alice",
      "change_type": "create"
    },
    {
      "id": "ver_002",
      "memory_id": "mem_001",
      "version_num": 2,
      "branch": "main",
      "commit_hash": "0000...0002",
      "parent_version_id": "ver_001",
      "content": "second version content",
      "snapshot_at": "2026-01-15T11:30:00+00:00",
      "snapshot_by": "alice",
      "change_type": "update"
    }
  ]
}

Plus a memory_branches shape for HEAD pointers + merge_parents for branches/merges. It's git-lite for memory.

Use case: "show me what this fact looked like before my last edit." PROV tells you provenance; the DAG tells you history. Different questions, both useful.

4. MemPalace migration guide + bidirectional converter

(From the original issue above. Concrete deliverable, working code, MemPalace's 49k-star community has an open thread asking for portability tooling.)

---

I'm happy to do whichever of these align with your roadmap. If you want me to PR all four, I can space them out (one at a time, smallest first to validate the contribution flow). If only the MemPalace adapter is in scope, I'll start there and queue the rest as Issues for later.

— Jason

[zircote]

@perlowja

Thank you for this, and my apologies for the late reply. I am only now returning to MIF after a busy spring (much of it spent offline).

Your timing is relevant. Before taking on new migration work, I have been exploring a pivot: aligning MIF with the Open Knowledge Format (OKF) that Google published this week. OKF defines a minimal interoperability surface and deliberately leaves the content model open, which is precisely the space MIF already fills. The realignment would make every MIF bundle a valid OKF bundle and reframe AI memory as the first profile rather than the core identity. That shift touches several of the conventions your questions reference (migration guide structure, the converter utilities in scripts/ and the type mapping), so I would rather settle the direction with you than have you build against a moving target.

The feature branch fo the OKF alignment is zircote/MIF/tree/develop/v1.0.0

Your offer is exactly the kind of contribution I hoped MIF would attract, and the MemPalace thread is a strong first target. The distribution channels you describe (Linux Foundation AI & Data, GitHub OSPO) are also the right path for graduating this from a founder-led spec to an ecosystem standard.

If you are willing, let us start a discussion and work through the OKF direction and the MemPalace mapping in detail. I will open a thread and tag you, or you are welcome to open one and I will respond there.

Robert Allen

[perlowja]

Makes sense to align MIF with OKF before I build the converter. Agree on the dedicated thread so we're not chasing a moving target.

Good news on scope: most of what I offered already exists and survives the pivot. MNEMOS's portability format (MPF v0.2, ncz-os/mpf) already ships migrations/mif.md and migrations/mempalace.md, conformance vectors/, W3C PROV record provenance, and optional bi-temporal tracking, with MNEMOS (CHARON, /v1/export and /v1/import) as the reference implementation. So the contribution is mostly upstreaming and retargeting, not net-new.

A framing for the thread: MIF as an OKF memory profile. OKF gives the substrate (markdown + frontmatter, type, index.md / log.md, path-as-ID, tolerant consumers that preserve unknown keys). MIF adds the memory semantics OKF omits, expressed as preserved custom keys:

• type constrained to the cognitive triad (semantic / episodic / procedural)
• id (urn:mif:<uuid>) plus namespace mapped to directory path
• provenance (W3C PROV) and bi-temporal valid_from / valid_to
• L3 citations, summary + compressed_at (compression manifest)
• the memory version / edit-chain DAG mapped onto OKF's reserved log.md, which lines up cleanly
• the .memory.json JSON-LD twin stays as the machine-processable form

Conformance Levels 1 to 3 then layer on OKF (L1 = OKF-valid plus triad type; L3 adds citations, compression, and the version DAG). Only the MPF-to-OKF base mapping depends on the OKF direction; the memory sidecars, converter, and vectors are stable, and I can bring them whenever the substrate settles.

Happy to open the dedicated thread with a concrete MPF/MemPalace to OKF field mapping (I have a draft) so we're working from specifics. What conformance level do you want the first MemPalace example to target?

[zircote]

@perlowja

Open a pull request against develop/v1.0.0 whenever you are ready. Nothing here gives me concern.

That branch is the OKF-founded line. The realignment proved a lighter lift than I anticipated, and the prominent schemas are stable. I am still pressure-testing it in a couple of projects that consume it, so expect minor tweaks, though nothing that should move the ground under your mapping.

Your framing of MIF as an OKF memory profile is correct, and it is the identity I am steering toward. Target the first MemPalace example at Level 1 (OKF-valid plus triad type) so we validate the base mapping and the contribution flow on something small, then layer up to Level 3 once the substrate proves out. Bring the version-DAG-onto-log.md idea into the thread as well, since I want to examine that one closely.

Open the dedicated thread with your draft field mapping and tag me. Working from your specifics will serve us better than my describing the direction in the abstract.

Robert Allen

[perlowja]

Opened #65 (draft, against develop/v1.0.0) with the Level-1 first step: a MemPalace → MIF AI-Memory field mapping (profiles/ai-memory/MEMPALACE-MAPPING.md) plus two worked Level-1 examples — a MemPalace entity → semantic observation (with a KG triple as a typed relationship) and a drawer → episodic session. Both pass okf_validate.py and the md↔json-ld lossless roundtrip. Bitemporal validity is deferred to a Level-3 version-DAG sidecar (not folded into created/modified), per your layering guidance. Would value your read on the triad assignment + the literal-object-triple handling before I add the bidirectional converter and layer up to L2/L3.

[zircote]

@perlowja

Thank you for the Memory Portability Format (MPF) proposal, and for choosing to align with the Modeled Information Format (MIF) rather than compete with it. The bottom line is this. The substance of your proposal is welcome, most of the per-unit gaps it cites are already closed on the develop/v1.0.0 branch, and the corpus envelope is the genuine open work. Five pull requests now address your concerns directly. Once you confirm those concerns are resolved to your satisfaction, we will cut the v1.0.0 release.

Your concerns, mapped to concrete work

Concern in #77	Where it is addressed
Provenance depth (W3C PROV)	#85
supersedes / edit lineage	already present (see corrections)
Compression manifest	per-unit fields already present (see corrections)
.memory.md / .memory.json naming	#81
Fact / Event via a new memoryCategory	#83
Vendor coupling (DoclingDocument embed)	#84
Capability discoverability	#82
Container Profile / corpus envelope	not in core; your draft #78 plus a dedicated ADR

Related context: the original mapping work is #65 (MemPalace to MIF Level-1), and the broader thread is the discussion at https://github.com/orgs/modeled-information-format/discussions/60. I have not re-read #60 in full for this reply, so treat that pointer as the venue rather than a claim about its current contents.

Corrections, offered precisely

Several premises in the proposal describe a pre-1.0.0 MIF. The branch has moved past them. I note these only so the envelope work starts from the current surface.

• Provenance is present. The unit already carries a provenance object (sourceType, confidence, trustLevel). PR feat: optional W3C-PROV provenance layer + honest framing (deliverable A) #85 deepens it with an OPTIONAL W3C-PROV-aligned layer (wasGeneratedBy, wasAttributedTo, wasDerivedFrom) and corrects documentation that previously overstated full PROV compliance. The accurate framing is a lightweight core plus an optional PROV layer.
• supersedes is present. It is a first-class relationship type, not a missing field. Edit lineage composes from supersedes and derived-from relationships together with the bi-temporal temporal block.
• Compression is present per unit. summary and compressedAt exist at Level 3. A corpus-level compression manifest is a separate, envelope-level concern (see below).
• .memory.md and .memory.json were removed in 1.0.0. Concept files use the .md extension only, and JSON-LD is a derived .jsonld projection. PR docs: scrub stale .memory.md/.memory.json naming (deliverable E) #81 scrubs the remaining stale references in the public documentation.
• memoryCategory is unnecessary. conceptType (semantic, episodic, procedural) already expresses Fact and Event. A Fact maps to semantic, an Event maps to episodic, refined by namespace and ontology-defined types. PR docs: taxonomy guidance — Fact/Event via type+namespace (deliverable D) #83 documents this so a parallel taxonomy is not introduced.

In the spec / Not in the spec

In the spec (added or clarified on develop/v1.0.0 by the five PRs):

• Optional W3C-PROV provenance layer and honest provenance framing (feat: optional W3C-PROV provenance layer + honest framing (deliverable A) #85).
• Vendor-neutral DocumentReference and a documents[] array, so source documents travel by reference rather than by embedding a vendor schema (feat: vendor-neutral DocumentReference (deliverable B) #84).
• A capability matrix and a synced field reference, so the 27 top-level properties are discoverable (docs: add capability matrix + link SCHEMA-REFERENCE (deliverable C) #82).
• Taxonomy guidance establishing that Fact and Event need no new field (docs: taxonomy guidance — Fact/Event via type+namespace (deliverable D) #83).
• Documentation hygiene for the 1.0.0 naming (docs: scrub stale .memory.md/.memory.json naming (deliverable E) #81).

Not in the spec (and not planned for v1.0.0 core):

• The Container Profile and its corpus records[] envelope. The unit-level model is settled. The multi-record transport envelope is a distinct layer, and it belongs in a dedicated Architecture Decision Record (ADR). It is exactly what your draft PR Proposal: Container Profile (corpus envelope) — spec §, example [draft] #78 proposes.
• The mif-converters ecosystem (vendor adapters, Charon import and export, Docling ingestion). This is useful work, but it is a sibling-repository concern with its own ownership and maintenance burden, not part of the core specification.

What is yours to define, resolve and adopt

The corpus envelope is the real open question, and it is yours to drive. Specifically:

• Reconcile the envelope with Open Knowledge Format (OKF) transport and with MIF's existing directory-bundle model. A single-file records[] JSON corpus is a different container shape than the directory bundle that MIF and OKF already define.
• Decide the envelope's document posture on top of the per-unit DocumentReference introduced in feat: vendor-neutral DocumentReference (deliverable B) #84, so the two layers compose rather than duplicate.
• Carry the proposal through issue Proposal: Adopt the MPF Corpus Envelope as a MIF Container Profile #77 and PR Proposal: Container Profile (corpus envelope) — spec §, example [draft] #78 to a Container Profile ADR. We will review the design and decide there.

Release

Once you have reviewed the five PRs, confirmed the per-unit concerns are addressed and acknowledged that the Container Profile is correctly scoped as separate follow-on work, we will tag and release v1.0.0. The release is gated on your acknowledgment that your concerns are met.

Thank you again for the careful proposal. I look forward to your review. If you feel I have missed or overlooked any details correct or direct me. I look forward to our collaboration.