Skip to content

Architecture

Claims Ledger

How MetaMemory distills memories into bi-temporal claims — facts that supersede cleanly on update, support point-in-time queries via asOf, and arbitrate conflicts with per-agent trust.

Last updated: March 2026

Overview

Alongside raw memories, MetaMemory maintains a claims ledger: an extraction pipeline distills stored memories into atomic facts — subject, predicate, value — with provenance back to the source memory. When a fact changes (a user switches jobs, a vendor gets replaced, a decision is reversed), the new claim supersedes the old one instead of contradicting it at retrieval time.

The ledger enforces one invariant everywhere: exactly one live current value per claim. Retrieval injects these "known current facts" into context, so agents answer from the current state of knowledge rather than whichever old conversation ranked highest.

The Bi-Temporal Model

Every claim is tracked on two independent time axes:

  • Valid time — when the fact was true in the world (validFrom / validUntil).
  • System time — when MetaMemory learned the fact, and when it was superseded or invalidated in the system.

Separating the two means late-arriving information is handled correctly: if you learn today that a contract actually ended last March, the ledger records both when it ended (valid time) and when you found out (system time) — and point-in-time queries answer accordingly.

Point-in-Time Queries

The get_claims_asofMCP tool answers "what did we know about X as of a given date?" — use it for past states of a fact, not current values (current values are already injected by retrieve_context):

get_claims_asof
{
  "subject": "Alice",
  "predicate": "employer",   // optional — omit for every known fact
  "asOf": "2026-03-01T00:00:00Z",
  "limit": 20
}

subjectis free text, matched against everything stored about that subject. The response includes each fact's value as of that moment plus a freshnessCursor you can feed into the change feed below.

Change Feed

get_claim_changesanswers "what changed since I last read?" It returns a page of claim change events — created, superseded, contested, reinforced, disputed — each with the freshly re-resolved current value:

get_claim_changes
{
  "sinceCursor": "<nextCursor from the previous call>"
}

Pass the nextCursor from a previous call (or the freshnessCursor from get_claims_asof) to page forward; omit it to start from the beginning. This lets a separate agent or process keep its view of "what does MetaMemory currently believe" in sync without re-reading everything.

Trust-Weighted Arbitration

In multi-agent fleets, claims carry agent attribution, and each principal has a trust weight (0-1) that governs conflict arbitration:

  • Below 0.5, a challenger from that principal can never evict another principal's current claim value.
  • At 0.75 or above, its claims need no corroboration.
  • In between, corroboration from other sources tips the ladder — and a contested claim never silently voids the established current value.
set_agent_trust
{
  "principalId": "token:agent-123",
  "trustWeight": 0.8,
  "status": "active"        // or "quarantined"
}

This is an admin operation — use it to promote vetted agents or quarantine a misbehaving one without deleting its history.

REST Equivalents

GET  /v1/claims/asof?subject=Alice&asOf=2026-03-01T00:00:00Z
GET  /v1/claims/changes?sinceCursor=...
PUT  /v1/agents/:principalId/trust
{ "trustWeight": 0.8, "status": "active" }

All claim reads are tenant-scoped and respect visibility scopes; erased facts are tombstoned so a re-ingested copy of deleted content cannot resurrect them.

Memory that gets smarter over time

Two lines of MCP config. Bring your own provider keys — validated, encrypted, under your control. Your AI remembers across sessions — and the system learns which retrieval works best for you.