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.

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