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