mema Whitepaper — englische redaktionelle Webfassung

mema: A Verifiable Seven-Layer Memory Architecture for Trustworthy AI Agents

Source-artifact edition: 2.26.0 Date: 2026-07-21 Author: Ardin Ibraimi Website presentation: editorial derivative, reconciled 2026-08-26; derived from, but not byte-identical to, the immutable internal source artifact below Immutable internal source artifact: d542fba556a7d4d78094ec782277eda18c79cb18:docs/WHITEPAPER.md · Git blob f12fa1da06ada3bbcdb3a729f71f19ce14a6f1d4 · SHA-256 62a9bda13f4f083ff45866f3a34df82453107904815ffc3b9c58304f61b563bd · 51,063 bytes / 972 lines · not publicly available Public source baseline: package 2.22.13 at c37dbf7, source-available under BUSL-1.1, whose default grant excludes Production Use; tagged versions v2.0.0 through v2.8.0 remain MIT-licensed Public runtime evidence: a reproduced bun test run at c37dbf7 passed 536 tests across 61 files with 1,361 expectation calls; the README’s 538 / 63 / 1,362 figures are a stale documentation claim, not runtime evidence Internal implementation evidence: build d542fba was locally verified as the v2.26 runtime; it is 25 commits ahead of the public repository and is not publicly available Release status: the immutable internal source artifact records 562 automated tests and eleven historical review rounds for the internal v2.26 evidence baseline. This editorial website presentation is not a public v2.26 release note and does not assert production readiness. Public source, internal implementation, source artifact, editorial presentation, benchmark evidence, and roadmap items are kept separate throughout.

Abstract

We present mema, an external memory architecture for AI agents that can wrap selected records as hash-checkable knowledge assets. The system is organized as seven composable layers: episodic ingestion, temporal-semantic facts, cognitive reflection, governance, hybrid retrieval, a cryptographically chained audit log, and an asset layer that can bind selected wrapped records to a content hash, metadata hash, asset version, and stable resolvable identifier (UAL). Inspired by Zep’s bi-temporal knowledge graph [1], Hindsight’s epistemic separation [2], Mem0’s production memory pipeline [3], and OriginTrail’s Decentralized Knowledge Graph (DKG) [4], mema combines retrieval with explicit provenance, tenant-scoping controls, erasure control, and a pluggable anchoring interface. The primary substrate is a markdown vault: source records remain human-readable without the derived SQLite indexes and logs. The architecture is principle-faithful in three commitments: extracted data remains outside the answer model, governance decisions are explicit, and the core has no graph- database or blockchain substrate dependency. The public 2.22.13 automatic /v2/observe path stores filtered extractor results directly as approved; separate draft/approve endpoints exist for other untrusted producers. This distinction is important: extraction is inference over external records, not model-weight training, and filtering is not the same as human approval.

1. Introduction

LLM agents are stateless by default. Agent-memory systems such as Zep and Graphiti [1, 11], Hindsight [2], Mem0 [3], MemGPT/Letta [5], Cognee, OriginTrail DKG [4], and since 2026 Anthropic’s managed memory stores with Dreams [10] address this at different boundaries. The design questions relevant to mema are:

1. Inspectable substrate the user can audit with cat
2. Tenant-scoped records and retrieval as a structural property
3. Cryptographic provenance including content/metadata hashing
4. Purpose-bound recall with explicit policy decisions
5. Erasure controls that can support GDPR Article 17 / Swiss nFADP Article 32 processes (targeted tombstones exist; cascade to derived records remains planned, see section 5.2)
6. Bi-temporal facts distinguishing world validity from epistemic state
7. Hybrid retrieval that fuses keyword + semantic + graph + temporal + policy
8. External anchoring that does not require a blockchain dependency
9. Vendor neutrality: runs without OpenAI, Anthropic, Neo4j, or IPFS

mema’s central thesis is that these properties can be delivered as composable layers rather than as bolted-on policies on top of an intelligence-led design. Treating each concern as its own layer, with a clear contract to the next, produces a system that is faster to evolve, easier to audit, and explicit about which properties are implemented or still limited.

2. Related work and positioning

2.1 Zep / Graphiti

The 2025 Zep-authored paper [1] describes a Neo4j-backed three-tier graph and reports 71.2% on LongMemEval with GPT-4o. That is a historical architecture and setup-specific vendor result, not a description of the current managed product. Current documentation [11] separates Zep from Graphiti: Zep uses a proprietary managed Context Graph Engine and documents temporal fact history, source-episode provenance, RBAC/ABAC, audit, retention, and tenant isolation. Graphiti is the Apache-2.0 open-source temporal context-graph framework and can be self-hosted with pluggable graph backends.

Zep documents Cloud, BYOK, and BYOC deployment; BYOC means the customer’s VPC. Its public documentation does not establish a customer-datacenter or air-gapped managed-Zep offer. Deletion controls also vary by scope: user-wide and node deletion are documented, while episode deletion has residual-state caveats. These are narrower claims than either “no erasure” or “hard erasure.”

mema adopts a bi-temporal model: valid_from, valid_to, invalidated_at, superseded_by are explicit frontmatter fields on every fact. mema diverges on substrate: facts are markdown files, not graph nodes. Multi-hop traversal walks derived_from pointers rather than executing Cypher.

2.2 Hindsight

The Hindsight architecture [2] organizes memory into four logical networks (world facts, agent experiences, synthesized entity summaries, evolving beliefs) driven by three operations: retain, recall, reflect. Retrieval fuses vector, BM25, graph, temporal, and reciprocal rank fusion. Reported LongMemEval: 83.6% overall with an open 20B backbone, up from a 39% full-context baseline on the same model.

mema borrows the epistemic separation: Layer 3 stores experiences, observations, and beliefs as distinct record kinds with confidence and superseded_by fields. mema diverges on synthesis governance: reflection runs as an explicit, deterministic, rule-based pass (with an opt-in LLM-augmented mode, reflectLLM, that is capped and evidence-anchored), so the same evidence always yields the same beliefs.

2.3 Mem0

Mem0 [3] focuses on production personalization: online LLM extraction of salient memories from conversation, vector + graph hybrid storage, automatic consolidation. Reported: >90% token cost reduction and 91% latency reduction vs full-context baselines on LoCoMo.

mema converged on write-time extraction. The v2.0 design rejected online LLM extraction; work through v2.14 added an extractor to /v2/observe. In public 2.22.13, the automatic path applies consensus, evidence, and supersession filters, then stores the resulting facts and entities directly as approved. Separate draft/approve endpoints exist for other untrusted producers. These controls must not be described as a human approval step, and the earlier write-path description is no longer true. Extraction remains inference over explicit external records; it does not train or modify the answer model’s weights.

2.4 OriginTrail / DKG

OriginTrail’s Decentralized Knowledge Graph [4] organizes information as Knowledge Assets: versioned records with content hashes, metadata hashes, stable resolvable identifiers (UAL), provenance, ownership, and optional external anchoring (Trace Protocol, IPFS). Originally designed for supply-chain traceability (SBB rail components), the model generalizes to any high-trust knowledge substrate.

mema’s Layer 7 directly adopts the Knowledge Asset pattern:

• content_hash (SHA-256 of body) and metadata_hash (SHA-256 of canonical frontmatter) provide integrity verification
• asset_version increments on real changes
• ual (Uniform Asset Locator) provides stable references (mema://owner/{owner}/{kind}/{scope}/memory/{id})
• verification_status lifecycle (unverified → verified → anchored)
• pluggable anchoring interface; the local receipt is implemented, while a customer audit bundle and external sinks such as OriginTrail DKG are planned

mema deliberately operates without a blockchain dependency: the anchor interface is local-by-default and is designed to admit external sinks such as OriginTrail DKG, customer-side ledgers, or IPFS. Those sinks are not part of the verified baselines described here. This preserves the no-vendor-lock-in invariant while keeping the architectural option open.

2.5 SuperLocalMemory (Qualixar)

SuperLocalMemory [12] describes an AGPL-3.0-or-later memory control plane with a local SQLite/sqlite-vec core, multiple retrieval channels, and policy, provenance, audit, export, and erasure surfaces. Its core operating mode can avoid cloud-provider calls, while model downloads, connectors, backup, and other network paths remain separate deployment choices. Capability and benchmark claims are project-reported; the project’s own documentation notes that some v4 benchmark evidence is carried forward from v3. Release-specific independent verification therefore remains necessary.

2.6 Provem

Provem [13] describes itself as an open-source research project for memory governance. It can use a small built-in retrieval backend or wrap another memory store. When wrapping a backend, Provem explicitly does not improve that backend’s recall; its stated boundary is deciding whether to write, serve, scope, erase, or abstain while retaining provenance. Its governance, security, and benchmark results are project-reported, and its current documentation does not claim an external security audit or production certification. The current repository main is Apache-2.0, while the published 0.1.0 PyPI artifact predates that change and declares MIT; release-specific review is therefore necessary.

2.7 Anthropic managed memory stores and Dreams (2026)

Anthropic documents platform-native agent memory in Managed Agents [10]: workspace-scoped stores of text files that mount into sessions, plus Dreams, an offline curation job that reads a store and session transcripts and emits a reorganized store for review. This is a managed platform boundary rather than a claim about model-weight continual learning. Hosting, retention, eligibility, and review behavior are service policies that can change; procurement work must verify them against the current platform documentation instead of relying on this paper’s snapshot.

2.8 Positioning boundaries

A single feature matrix hides deployment, licensing, evidence, and scope differences. The defensible comparison is narrower:

• Zep / Graphiti: managed proprietary platform versus self-hosted OSS temporal graph; current Zep governance, temporal history, and scoped deletion controls must not be reduced to binary absence.
• SuperLocalMemory (Qualixar): local control-plane project with broad project-reported surfaces; release-specific independent validation remains necessary.
• Provem: research governance layer with a built-in or wrapped backend; a wrapped backend retains responsibility for its recall quality.
• mema: explicit external records and retrieval rather than model-internal learning. Public 2.22.13 is inspectable; the v2.26 implementation is internal; customer-datacenter packaging, independent evidence export, and HOPE integration remain roadmap items. Production readiness is not asserted.

“Not publicly documented” is not evidence that a capability is absent. This paper therefore avoids binary conclusions where a current primary source does not establish the operating boundary.

3. The seven-layer architecture

┌─────────────────────────────────────────────────────────────────┐
│  L7  Asset       (content_hash + metadata_hash + UAL + anchor)  │
├─────────────────────────────────────────────────────────────────┤
│  L6  Audit       (SHA-256 hash-chained log, full RECALL trace)  │
├─────────────────────────────────────────────────────────────────┤
│  L5  Retrieval   (keyword + IDF + vector + graph + policy)      │
├─────────────────────────────────────────────────────────────────┤
│  L4  Governance  (purpose, retention, provenance, hard-erase)   │
├─────────────────────────────────────────────────────────────────┤
│  L3  Cognitive   (experiences, observations, beliefs, reflect)  │
├─────────────────────────────────────────────────────────────────┤
│  L2  Semantic    (entities + facts + bi-temporal validity)      │
├─────────────────────────────────────────────────────────────────┤
│  L1  Episodic    (raw conversations, documents, tool calls)     │
└─────────────────────────────────────────────────────────────────┘

Each layer is one or more TypeScript files under src/v2/layer{N}-*.ts. The filesystem layout mirrors the architecture: data/episodes/, data/facts/, data/cognitive/, data/v2-entities/, data/_meta/audit.sqlite, data/_meta/vectors.sqlite, data/_meta/anchors.sqlite.

3.1 Layer 1: Episodic (layer1-episodic.ts)

An Episode is a raw event: conversation turn, document ingestion, tool call, environmental observation. Immutable after write. The evidence base for everything higher.

interface Episode {
  id: string;              // ULID
  timestamp: string;
  actor: string;
  owner: string;
  kind: "conversation" | "document" | "tool_call" | "observation";
  content: string;
  source?: string;
  refs?: string[];
}

Stored as data/episodes/{owner}/{YYYY-MM-DD}/{ulid}.md with frontmatter.

Since v2.14.1, POST /v2/observe invokes extraction by default: persisting an episode can trigger chunking, N-pass extraction, evidence filtering, entity linking, and supersession-aware fact recording. In public 2.22.13 the filtered automatic result is written with approved status; it does not traverse a human approval step. Large episodes are split on structural boundaries and extracted in bounded parallel, then merged. The episode remains the external evidence record regardless of what extraction yields.

3.2 Layer 2: Semantic entities and facts (layer2-entities.ts, layer2-semantic.ts)

Entities are the canonical referents that facts subject/object point at. Aliases let “Marcel”, “Marcel R.”, “marcel@machtsinn.ai” resolve to one entity. CRUD operations: createEntity, findEntityByName, mergeEntities (for when two entities turn out to be the same referent: alias union, redirect stub).

Semantic Facts carry Zep-style bi-temporal validity:

interface SemanticFact {
  id: string;
  subject: string; predicate: string; object: string;
  valid_from: string;              // when true in the world
  valid_to: string | null;         // when stops being true
  invalidated_at: string | null;   // when WE learned it was wrong
  superseded_by: string | null;
  derived_from: string[];          // episode IDs
  confidence: number;
  owner: string;
}

getFactsValidAt(owner, time) returns the set of facts that were both world-valid AND known-good at time.

3.3 Layer 3: Cognitive (beliefs, observations, experiences) + reflection

(layer3-cognitive.ts, layer3-reflection.ts)

interface CognitiveRecord {
  id: string;
  kind: "experience" | "observation" | "belief";
  content: string;
  confidence: number;
  derived_from: string[];
  reflected_at: string;
  superseded_by: string | null;
  owner: string;
}

Automated reflection (reflect()) runs offline and rule-based. It:

1. Marks each tool_call/observation episode in the window as an experience with confidence 0.7.
2. Aggregates entity mentions across episodes; entities mentioned in ≥2 episodes and ≥min_support times become observations with confidence scaled by frequency.
3. Groups facts by subject::predicate; clusters with ≥min_support convergent facts produce beliefs with confidence weighted by support count and source confidence.

The rule-based reflection pass makes no external API calls and returns explicit abstention states. In the internal baseline, changes after public 2.22.13 add retract-on-abstain behavior: when new evidence (an entity alias merge, a historical backfill) turns a previously drawn conclusion into a conflict, the stale belief is superseded onto an explicit unresolved marker instead of staying live. An opt-in LLM-augmented mode (reflectLLM) exists for experimental insight mining; it is capped per window and every draft it produces must anchor to verbatim evidence and pass the Layer 4 draft/approve lifecycle.

3.4 Layer 4: Governance (layer4-governance.ts)

interface Governance {
  purpose: string[];
  retention_until: string | null;
  jurisdiction?: string;             // "CH" | "EU" | "US" | ...
  data_classes?: string[];           // ["pii", "financial", ...]
  evidence: {
    source_hash: string;             // SHA-256 of source content
    excerpt: string;                 // ≤500 verbatim chars
    actor: string;
    ingested_at: string;
  };
  allowed_actors?: string[];
}

policyCheck(governance, ctx) enforces at retrieval time:

• Retention expiry → policy_deny:retention_expired
• Purpose mismatch → policy_deny:purpose_not_allowed
• Actor not in allowlist → policy_deny:actor_not_in_allowlist

On the covered recall path, policy denials are logged to L6 with op: POLICY_DENY and the reason.

Governance blocks attach at ingestion or later: POST /v2/record/:id/governance (v2.26.0) binds a block to any stored record the caller owns. The evidence hash is computed server-side from the record’s stored body, never from caller-supplied text, and the mutation lands in the audit chain as a GOVERN row. Attaching to a record already wrapped as an L7 asset refreshes its hashes and bumps the asset version, so later integrity checks compare against the recorded post-change version.

Hard erasure (hardErase) overwrites file content with a tombstone containing erasure metadata, distinct from v1’s soft-forget flag. Known limitation, stated plainly: erasure currently tombstones the targeted record without cascading. A cascade that follows derived_from chains to facts and beliefs derived from an erased episode is designed but not yet implemented. Any GDPR Article 17 or nFADP erasure process must therefore identify and erase derived records explicitly and be validated in the deployment’s wider legal and operational process.

3.5 Layer 5: Retrieval: keyword + vector + graph + temporal + policy

Implementation spans layer5-retrieval.ts, layer5-embeddings.ts, layer5-graph.ts.

Pipeline at recall time:

1. Keyword via ripgrep across all markdown
2. Vector via cosine over local-hash embeddings (or pluggable embedder: OpenAI / Voyage / on-demand)
3. Owner filter: scope candidates to the requested owner
4. Layer filter: restrict to specific kinds if requested
5. Temporal: for facts, apply validity windows
6. Tombstone: skip hard-erased and soft-forgotten records
7. Policy: per-record policyCheck
8. Fused scoring:

score = 0.30 × idf_normalized
      + 0.25 × title_boost
      + 0.25 × vector_cosine
      + 0.10 × record_confidence
      + 0.10 × layer_prior

9. Graph expansion: for each top hit, walk derived_from up to 2 hops to build a linked evidence chain where those relations exist
10. Audit: returned result metadata and linked evidence identifiers are logged to L6 on the covered path

The internal v2.24+ baseline adds a source class (statement, document, marketing, external) that flows into the facts derived from it. Marketing-class records stay recallable but are demoted by 25% in ranking and keep their label in results, reducing the chance that an aspirational brochure claim outranks an attributed statement from a signed letter. Confidence in mema means “confidence the source said it”; the source class records what kind of source did the saying. Both fact and episode hits expose source and source_class in their payload (v2.26.0), so a dashboard can label provenance without touching the vault.

3.5.1 Verifiable recall packet

On supported record paths, a hit returned by /v2/recall can include the following fields; availability depends on record type, governance metadata, and whether the record was wrapped as an asset:

{
  "kind": "fact",
  "id": "01KR...",
  "score": 0.86,
  "score_components": { "idf": 0.72, "title": 0.80, "vector": 0.41, ... },
  "excerpt": "Pillar 3a tax optimization strategy ...",
  "governance": { "allowed": true, "reason": "policy_pass" },
  "ual": "mema://owner/ardin/fact/marcel-r/memory/01KR...",
  "content_hash": "sha256:abc...",
  "metadata_hash": "sha256:def...",
  "asset_version": 1,
  "verification_status": "anchored",
  "why_retrieved": "rare-term keyword match + title match + semantic similarity (0.41)"
}

A consumer can independently verify the hit by re-hashing the file at ual and comparing it to content_hash. This checks record integrity at that boundary; it does not establish that the record’s content is true.

3.6 Layer 6: Audit (layer6-audit.ts)

SHA-256 hash-chained log of recorded operations.

interface AuditEntry {
  seq: number;
  ts: string;
  op: "OBSERVE" | "EXTRACT" | "INVALIDATE" | "REFLECT"
     | "RECALL" | "POLICY_DENY" | "ERASE";
  actor: string;
  owner: string;
  purpose?: string;
  record_ids: string[];
  evidence_chain?: string[];
  reason?: string;
  prev_hash: string | null;
  curr_hash: string;        // SHA-256(prev_hash || canonical_payload)
}

verifyChain() walks entries and recomputes hashes. Tests exercise covered modification, removal, and reordering scenarios and expect a failed result at the affected sequence. That is evidence for those tested cases, not a general claim about every storage or operator threat.

3.7 Layer 7: Asset (layer7-assets.ts)

Every record can be wrapped as an asset, promoting it from a plain markdown file to a versioned, hash-stamped, UAL-addressable verifiable artifact.

interface AssetMetadata {
  ual: string;
  content_hash: string;       // SHA-256(body)
  metadata_hash: string;      // SHA-256(canonical_frontmatter)
  asset_version: number;
  verification_status: "unverified" | "verified" | "anchored";
  anchored_at?: string;
  anchor_targets?: string[];  // ["local", "customer-audit-bundle", ...]
}

Verification: verifyAssetIntegrity(path) recomputes hashes and returns whether the file has been mutated since it was last wrapped.

Anchoring: anchorAsset({ filePath, target }) records the asset’s hash at a target sink. The implemented target described by this edition is local: a receipt row in data/_meta/anchors.sqlite. It shares a trust root with the vault (same disk and operator), so it provides a local consistency signal, not independent evidence against an actor with filesystem access. Independent customer evidence bundles and external sinks such as OriginTrail DKG [4] or IPFS remain planned interfaces, not supported public exports.

Lifecycle: unverified (default after wrapping) → verified (after human review) → anchored (a receipt exists at the configured target; with the implemented local target this means a local receipt, not external publication).

4. Empirical evaluation

4.1 Test suite: 562 automated tests

At internally verified build d542fba, the recorded suite comprises 562 tests across 70 files (1,459 assertions) and passed in that verification run. Coverage grew in bands:

Findings in the recorded review rounds produced versioned changes and regression tests, so the suite preserves part of that historical review record.

4.2 Recall benchmark: 25 queries on 347-document personal corpus (measured 2026-05, v2.0)

Compared three configurations against the imported corpus (~/Documents/pai/finance-plan/ + ~/Documents/pai/machtsinn/, 347 markdown documents covering Swiss finance, machtsinn business strategy, engineering decisions, sales research, operations logs). Queries span: exact lookups, paraphrase, document type, synthesis, multi-keyword.

For each query, we defined expected keywords that the canonical correct document’s title/alias should contain. This permits reproducible scoring without LLM judges.

v2-fused over v1: +52.0 percentage points on P@1. The local-hash embedder used in v2-fused is a simple discriminating baseline; substituting OpenAI text-embedding-3-small (auto-detected via OPENAI_API_KEY env) is expected to widen the gap further on paraphrase-heavy queries.

4.3 What the numbers mean and do not mean

• Single corpus: 347 documents, one tenant, German + English mixed. Cross-corpus generalization is future work.
• Keyword-anchored queries: the test set is realistic for personal- recall use cases but tilts toward queries where exact-term matches are achievable. Paraphrase-heavy benchmarks (LongMemEval, LoCoMo) test the vector layer more aggressively and remain open work.
• No LLM judge: relevance is keyword-defined for reproducibility.
• A disclosure on large-scale numbers: one internal LongMemEval run (May 2026) produced a headline accuracy figure that was later invalidated, because the local extractor in use at the time was regurgitating its few-shot examples instead of extracting from input. That number is not reported here and should not be cited. No LongMemEval-class result exists for mema that we consider defensible; publishing one awaits a full re-run with the current governed extraction pipeline.
• The single regression (Q10, “founder decision pack”) returns the same canonical doc at v2 rank 2 vs v1 rank 1; v1 ranked it via a coincidental “partner” keyword bleed.

4.4 Adversarial review history

mema records eleven historical adversarial review rounds across architecture, security, extraction, reflection, and benchmark methodology. Findings produced versioned changes and regression tests in the reviewed baselines. This history is useful engineering evidence, but it is not a current security assessment or release approval: a later source state can introduce new behavior, and the public repository does not yet match the internally verified v2.26 baseline.

For that reason, this edition no longer labels a historical round as “all fixed” or turns an old test result into a current assurance statement. A future public release needs source parity plus a fresh, independently reviewed security and operations record. Production readiness is not asserted here.

4.5 Threat model

The architecture considers authenticated cross-tenant access, malformed API input, prompt-injected source content, and direct mutation of vault or SQLite state. Tests cover selected boundary, audit-chain, size, and retrieval-failure cases. Their exact scope belongs to the version under test and must not be read as universal coverage.

Material operator responsibilities remain outside the core: OS access control, transport security, identity integration, secrets, backup and restore, monitoring, key custody, upgrade safety, availability, and independent evidence retention. A customer-datacenter operations package and evidence export are roadmap items; no supported public package is claimed by this edition.

4.6 Architectural property tests

Beyond the recall benchmark, the test suite verifies non-recall properties that matter for enterprise trust:

• Cross-tenant leak: owner B querying for owner A’s verbatim content returns zero results (tests/v2/professional.test.ts).
• Audit hash chain: tampering with any historical audit entry causes verifyChain() to return valid: false with the broken seq number.
• Hard erase: post-erase, the file on disk no longer contains the original content; the tombstone + audit reference remain.
• Retention expiry: a record with retention_until in the past returns policy_deny: retention_expired at recall, regardless of keyword match.
• Asset integrity: silently modifying a wrapped asset’s body causes verifyAssetIntegrity to return valid: false with the failing hash identified.

4.7 Internal seven-layer exercise (2026-07-18)

On 2026-07-18, seven independent audit agents probed one layer each against an internally operated v2.22.14 instance with concurrent document ingestion: reading the layer’s code to establish its contract, then exercising the HTTP stack and inspecting the vault files it produced. This was an internal point-in-time exercise, not production certification. Recorded results:

Audit-process note: probe records written during the audit were removed afterward through the system’s own governed /v2/erase, leaving audit-chained tombstones; the chain verified valid: true across 34,893 entries after cleanup. The audit also surfaced a deployment sharp edge recorded in the exercise: the x-owner header was a benchmark override and was ignored in the exercised deployment mode, where owner context derived from the API key.

4.8 Internal Swiss Trust Memory Bench run: 9/9 (2026-07-21)

Where LongMemEval and LoCoMo measure memory intelligence, the Swiss Trust Memory Bench (bench/swiss-trust-bench.ts) measures the trust properties that differentiate mema in regulated deployments. Each scenario is an end-to-end assertion against an internal instance, phrased so that a regulated buyer can read the output as a procurement checklist. The recorded internal v2.25.0 run (2026-07-21) passed all nine scenarios. This is point-in-time test evidence, not a public release or operations approval:

One harness defect was found and fixed in this run: the permissive scenario relied on the server’s default policy mode while the bench’s own instructions start the server in strict mode, which made the scenario unpassable by construction. It now requests permissive mode explicitly. The fix is a versioned commit like every other finding.

4.9 Scripted seven-layer demonstration (v2.25.0)

demo/run-demo.ts walks all seven layers against a fresh, isolated vault in one deterministic run: verbatim ingestion, automatic supersession for a person’s employer next to a deliberate refusal to auto-replace a company address, as-of queries at three moments, rule-based reflection with explicit abstentions, purpose-limited recall (deny and allow on the same record), retrieval receipts, hard erasure with a recorded legal basis followed by a still-valid chain, and live tamper detection on a wrapped asset. The runner exits non-zero if any step misbehaves, so the demonstration doubles as an end-to-end smoke test. Episodes are ingested with extraction skipped and facts recorded explicitly with evidence excerpts: a demonstration must tell the same story on every run, and extractor output does not.

5. Implementation status

Internal build d542fba contains implementation surfaces across all seven layers. The table is an internal point-in-time inventory, not a public release or operations approval:

The internal v2.23+ baseline includes two read-oriented product surfaces on the same HTTP stack: an audit dashboard at /ui (overview, chain status, review queue, and a traceability explorer whose provenance drawer can follow supported answer paths to linked source documents) and a graph viewer at /graph that renders the episode/fact/entity/belief network directly from the vault. Both consume the public API; neither has write access.

5.1 Permanent non-goals (preserved invariants)

These are not gaps; they are design decisions that mema commits to:

• Model-internal training is outside the MEMA core. LLM extraction and optional reflection are inference over external records; they do not modify the answer model’s weights. The public automatic observe path applies deterministic filters and writes the result as approved, while other producer paths expose draft/approve transitions. The raw episode remains the underlying external evidence record, but its presence does not prove an extracted claim true.
• Graph database substrate: never. Multi-hop traversal walks in-frontmatter pointers (derived_from, subject-grouped facts). Postgres recursive CTEs are an acceptable optimization if grep becomes the bottleneck; Neo4j-as-substrate is not.
• Blockchain dependency: never. The L7 anchor interface is designed to admit blockchain sinks (OriginTrail DKG, IPFS) as future pluggable targets, but mema runs fully without them; those external sinks are not implemented in the verified baselines described here.

5.2 Roadmap and unresolved boundaries (editorial reconciliation 2026-08-25)

• Episode idempotency. /v2/observe has no content-hash dedup yet; re-ingesting the same document mints a duplicate episode and can inflate corroboration counts. Top of the queue.
• Erasure cascade. Follow derived_from chains on hardErase so erasing an episode also tombstones facts and beliefs derived from it, with an audit row per tombstone. Designed, not built.
• Deterministic consolidation pass (“dream pass”): an operator-run offline replay that rebuilds a shadow vault (episode dedup, entity registry-before-replay, world-time fact replay, full-window reflection) for diff review and swap, with the consolidation itself recorded as an auditable event in the source chain.
• LongMemEval / LoCoMo re-run with the governed extraction pipeline and an operational embedder, published if it survives adversarial review of the methodology.
• Vector index operations. The 2026-07-18 internal exercise found the vector index can go silently stale (manual reindex is required, and the vector health check does not validate stored paths), degrading recall to the keyword path without any operator signal. Planned: incremental indexing on write and a health check that samples path validity.
• Anchor target validation and a supported external sink. Today any target string yields status anchored with a local receipt; the interface needs target validation, and the customer-audit-bundle sink is a candidate external target.
• Customer-datacenter operations package. Target state: runtime, vault, keys, backups, updates, and monitoring under customer control with no mandatory MEMA cloud. Supported HA, restore, upgrade, and operations runbooks are not publicly verified or offered yet.
• Customer evidence export. Produce a supported, customer-checkable bundle of selected records, hashes, policy decisions, and audit excerpts. The local anchor receipt is not an independent export.
• Governed HOPE adapter. Explore an optional, disabled-by-default boundary around a future model-internal continual-learning module. HOPE outputs would remain untrusted candidates or bounded ranking signals and could not bypass MEMA policy, evidence, approval, erasure, or audit controls. No HOPE runtime is implemented in the public or internal MEMA baseline.
• Per-jurisdiction physical storage placement (today, jurisdiction is stored as metadata without physical placement) and multi-region replication with audit-log consistency guarantees.

6. Reproducibility

The public commands below reproduce the inspectable 2.22.13 baseline at c37dbf7; they do not reproduce internal v2.26 or its 562-test evidence. The internal build cannot be independently fetched until its source is published. Our reproduced bun test run at this commit passed 536 tests across 61 files with 1,361 expectation calls. The checked-in README still claims 538 tests, 63 files, and 1,362 expectations; that documentation is stale and is not runtime evidence.

git clone https://github.com/machtsinnch/mema && cd mema
git checkout c37dbf7935ed94e3fabf93c522a42db8638e671e
bun install

# Start server (with permissive rate-limit for development)
MACHTSINN_RATE_LIMIT_BURST=10000 ./scripts/start.sh

# Import a corpus
bun scripts/import-tree.ts /path/to/your/markdown/folders

# Build the vector index (one-time, idempotent)
curl -X POST http://localhost:3001/v2/vector/reindex -H "x-api-key: dev-ardin"

# Run the public-baseline test suite (observed: 536 tests / 61 files / 1,361 expectations)
bun test

# Run the v2 recall benchmark (25 queries × 3 configs)
python3 bench/recall-benchmark-v2.py

# Verify audit chain integrity at any time
curl http://localhost:3001/v2/audit/verify -H "x-api-key: dev-ardin"

Modify bench/recall-benchmark-v2.py to match your corpus by editing the QUERIES list; each entry is (label, query, [expected_keywords]).

7. Conclusion

mema’s architectural contribution is a separation of concerns: explicit episodes, facts, cognitive records, policy decisions, retrieval traces, audit entries, and hash metadata remain outside the answer model. LLM extraction is inference over those records rather than model-internal continual learning. Integrity checks can show whether a wrapped record changed; they do not prove that its contents are true.

On the small internal benchmark (25 queries, a 347-document personal corpus, measured 2026-05 on v2.0), the fused retrieval stack recorded 96.0% Precision@1 versus the v1 baseline’s 44.0% with keyword, IDF, local-hash vector, title boost, and policy filtering. Section 4.3 defines the limitations. No cross-system or large-scale benchmark result is claimed.

The deployment target remains regulated Swiss and EU organizations that need inspectable storage and explicit governance. A target is not a release: public source remains 2.22.13, internal v2.26 is not publicly available, supported customer-datacenter operations and independent evidence export are planned, and production readiness is not asserted.

References

1. Rasmussen, P. et al. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv:2501.13956 (2025). https://arxiv.org/abs/2501.13956

2. Latimer, C. et al. Hindsight is 20/20: Building Agent Memory that Retains, Recalls, and Reflects. arXiv:2512.12818 (2025). https://arxiv.org/abs/2512.12818

3. Singh, M. et al. Mem0. arXiv:2504.19413 (2024). https://arxiv.org/abs/2504.19413

4. OriginTrail. Decentralized Knowledge Graph (DKG) Whitepaper. OriginTrail Foundation (2018–2025). https://origintrail.io/ecosystem/whitepapers SBB Cargo case study: trusted real-time component traceability. The Knowledge Asset model, UAL identifier, and provenance/anchoring pattern inspired mema’s L7 architecture.

5. Packer, C. et al. MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560 (2023). https://arxiv.org/abs/2310.08560

6. Park, J. et al. Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023. (Source of mema’s relevance+recency+importance+trust scoring foundation.)

7. Lightman, H. et al. Let’s Verify Step by Step. (Process Reward Models, 2023.) Informs mema’s per-hit why_retrieved rationale.

8. EU GDPR Article 17 (Right to Erasure). Regulation (EU) 2016/679.

9. Swiss nFADP (neues Datenschutzgesetz). Bundesgesetz über den Datenschutz, in force 2023-09-01. Article 32 (erasure right).

10. Anthropic. Claude Managed Agents: Memory and Dreams. Platform documentation, retrieved 2026-07-18. https://platform.claude.com/docs/en/managed-agents/memory and https://platform.claude.com/docs/en/managed-agents/dreams.

11. Zep. Zep versus Graphiti; Fact model; deployment and security; deletion semantics. Current product documentation, retrieved 2026-08-25. https://help.getzep.com/zep-vs-graphiti, https://help.getzep.com/facts, https://help.getzep.com/security-compliance, and https://help.getzep.com/deleting-data-from-the-graph.

12. Qualixar. SuperLocalMemory. Repository, architecture, compliance limits, and license, retrieved 2026-08-25. https://github.com/qualixar/superlocalmemory/tree/060cdb1fa954af9febdf9a057d4d849c2909611c, https://github.com/qualixar/superlocalmemory/blob/060cdb1fa954af9febdf9a057d4d849c2909611c/docs/ARCHITECTURE.md, and https://github.com/qualixar/superlocalmemory/blob/060cdb1fa954af9febdf9a057d4d849c2909611c/docs/compliance.md.

13. Jackiewicz, B. Provem. Repository, claims/limitations, and licensing, retrieved 2026-08-25. https://github.com/BernhardJackiewicz/provem/tree/f6ce1b69c27a8c7eee78a0d15d6cb018d836922f, https://github.com/BernhardJackiewicz/provem/blob/f6ce1b69c27a8c7eee78a0d15d6cb018d836922f/docs/claims.md, and https://github.com/BernhardJackiewicz/provem/blob/f6ce1b69c27a8c7eee78a0d15d6cb018d836922f/LICENSING.md.

Appendix A: File layout

mema/
├── src/
│   ├── api.ts                      # v1 + v2 mounting
│   ├── storage.ts, search.ts, ... # v1 implementation
│   ├── db.ts                       # v1 audit log (preserved)
│   └── v2/
│       ├── types.ts, schemas.ts    # all v2 type definitions
│       ├── layer1-episodic.ts
│       ├── layer2-entities.ts, layer2-semantic.ts, layer2-factcheck.ts
│       ├── llm-extractor.ts        # governed extraction (consensus + evidence gates)
│       ├── layer3-cognitive.ts, layer3-reflection.ts, layer3-judgment.ts
│       ├── layer4-governance.ts, layer4-supersession.ts
│       ├── layer5-retrieval.ts, layer5-rrf.ts, layer5-embeddings.ts
│       ├── layer5-graph.ts, layer5-graph-view.ts, memory-packet.ts
│       ├── layer6-audit.ts         # hash chain + external witness
│       ├── layer7-assets.ts        # hashes + UAL + anchor + lifecycle
│       ├── temporal.ts, predicates.ts, atomic.ts
│       └── api.ts                  # v2 HTTP routes
├── data/
│   ├── entities/, generalized/, users/             # v1 vault
│   ├── episodes/{owner}/{date}/{ulid}.md           # L1
│   ├── facts/{owner}/{ulid}.md                     # L2 facts
│   ├── v2-entities/{owner}/{ulid}.md               # L2 entities
│   ├── cognitive/{owner}/{kind}/{ulid}.md          # L3
│   └── _meta/
│       ├── log.sqlite                              # v1 audit (preserved)
│       ├── audit.sqlite                            # L6 hash-chained
│       ├── vectors.sqlite                          # L5 vector index
│       └── anchors.sqlite                          # L7 anchor receipts
├── tests/                                          # 562 tests, 70 files
│   ├── *.test.ts                                   # v1 isolation + security
│   └── v2/                                         # smoke, professional, assets,
│                                                   # security rounds, extraction,
│                                                   # v2.22.x review regressions,
│                                                   # l3-retract-on-abstain,
│                                                   # dashboard-era regressions
├── bench/
│   ├── recall-benchmark.py                         # original 15-query
│   ├── recall-benchmark-v2.py                      # 25-query × 3 configs
│   ├── swiss-trust-bench.ts                        # 9 trust scenarios (4.8)
│   └── longmemeval-harness.ts                      # LongMemEval retrieval harness
├── demo/                                           # scripted 7-layer walkthrough (4.9)
└── docs/WHITEPAPER.md                              # this document

Appendix B: HTTP surface (v2)