Memory Fabric
Concrete implementation of the promotion-aware memory plane — storage, review queue, consolidation, redaction.
The Memory Fabric is the concrete implementation of the Memory plane. It owns the capture log, the candidate extractor, the review queue, the promotion pipeline, the tier storage, and the redaction layer.
Definition
A storage and policy layer that materializes the promotion pipeline (capture → candidate → review queue → promoted → compiled context). Reads expose only promoted memory; writes are typed by class, evidence-bound, contradiction-checked, and consent-gated.
Why it exists
The Memory model defines the contract. The Fabric is what stores it, indexes it, governs it, and exposes it to the Compiler. Without a concrete fabric, every team’s memory diverges and the runtime cannot guarantee that “remembered” facts are governed.
How it works
- Capture — every tool result, decision, and turn-level effect appends to an immutable event log; never queried by the Compiler directly.
- Extract — a consolidator transforms captures into typed candidate facts (entity, predicate, value, evidence_refs, confidence, class).
- Queue — candidates above a confidence floor enter the review queue; auto-approval policies may admit specific low-risk classes.
- Promote — approved candidates are tier-routed (
working/episodic/semantic/durable) with a contradiction check. - Recall — the Compiler queries promoted memory only, scoped by tenant, role, classification, and intent.
Storage tiers
| Tier | Backing | Retention | Indexing |
|---|---|---|---|
working | session store (in-process or Redis) | minutes to hours | by session_id |
episodic | tenant-scoped document store | hours to days | by user_id + workflow_id |
semantic | tenant-scoped graph + vector index | long-lived, explicit deprecation | by entity CEID |
durable | append-only log + indexed projection | months to years (policy-driven) | by entity CEID + decision_key |
All tiers carry tenant, classification, and provenance on every record.
Review queue
The review queue is a first-class store with operator UI hooks:
proposal_id(stable),candidate,class,tier_target,evidence_refs,confidence.consent_checkandcontradiction_checkresults computed at queue time.auto_promote_eligibleflag based on the pack’spromotion_thresholds.- Operator actions:
approve,edit,reject. Rejections are remembered with reason so the same noise is filtered next time.
Consolidation pipeline
capture log
↓
candidate extractor (typed transforms per source)
↓
review queue
↓
contradiction checker ←→ existing promoted records (same entity + predicate)
↓
tier router (per memory_layer.memory_policy)
↓
write-side redactor (PII, classification)
↓
tier storage + indexRead-side context assembly
When the Compiler recalls memory, the Fabric:
- filters by
tenant_id, role, anddata_classificationfrom the Run Context, - applies freshness windows and confidence thresholds from the pack,
- ranks by relevance to the active intent,
- returns each record with its provenance, originating capture event, and confidence.
Records below the recall threshold are not silently dropped — they are returned as low_confidence so the planner can decide to surface a clarifying question.
Write-side governance
Writes are typed by class:
| Write class | Purpose | Allow-list scope |
|---|---|---|
evidence_link | record a citation linking a decision to an evidence_ref | always allowed for governed decisions |
preference | persist a user preference | per pack memory_layer.write_classes_allowed |
decision_outcome | summarize a completed decision | per pack |
correction | first-class operator correction; outranks prior on the same key | requires correction_writer role |
Each class has its own retention policy, classification rules, and consent gating. Correction writes emit a learning signal to the Insight Synthesizer.
Contradiction handling
When a promotion targets the same (entity, predicate) as an existing record:
- if the new record’s confidence is materially higher and policy allows auto-resolve, the prior record is superseded with audit;
- otherwise, both records persist with
contradiction: truemarkers and the planner is required to handle the conflict on the next recall.
Redaction
Applied at the candidate stage, not at recall. The pack’s policy_layer.guardrails.redaction_rules (regex / classifier patterns) plus the Identity Layer’s classified attributes determine what is masked.
Implementation mapping
- Memory model — the spec narrative.
- Knowledge Graph — the substrate that promoted memory writes against.
- Identity Layer — CEIDs that key memory records.
- Governance — write classes, consent rules, redaction.
Interfaces
Inputs
- Capture stream from every plane
- Memory write policy and consent records
- Run Context (
tenant_id, role, classification scope) - Operator queue actions
Outputs
- Promoted records consumable by the Compiler
- Review queue items with consent + contradiction checks
- Write proposals for the next turn
- Contradiction events for operator review
Failure modes
- Capture log unbounded (mitigated by tier-by-tier compaction).
- Candidate extractor produces low-quality candidates that swamp the queue (mitigated by per-source confidence calibration).
- Auto-promotion policy too permissive — drift; mitigated by sample audit of auto-promoted records.
- Recall returns records past TTL because freshness window not honored — mitigated by index TTLs.
- Cross-tenant leakage through a shared semantic record (mitigated by tenant scoping at storage).
Operational concerns
- Storage and index cost budgets per tier.
- Operator throughput on the review queue; SLA per class.
- Contradiction backlog monitoring.
- Per-tier TTL alerts when records approach deletion.
- Backfill and compaction jobs run against pinned ontology versions, never
now.
Evaluation metrics
- Recall precision/recall against golden memory queries.
- PII write-back violation rate (target: zero).
- Review queue throughput (items/operator/day).
- Auto-promotion accuracy (sample-audited).
- Correction adoption rate (operator corrections that change downstream decisions).
Example
A typed memory write proposal for review:
{
"proposal_id": "mwp_2026_05_04_0931_a17",
"candidate": {
"entity_ceid": "customer:cus_77",
"predicate": "prefers_communication_channel",
"value": "email",
"evidence_refs": ["tool:crm.lookup:tc_212", "session:sess_42f1"],
"confidence": 0.93
},
"class": "preference",
"tier_target": "semantic",
"consent_check": "passed",
"contradiction_check": { "existing": null, "verdict": "no_conflict" },
"auto_promote_eligible": true
}Common misconceptions
- The Fabric is not the Knowledge Graph. Memory is what survived promotion; the graph is the broader substrate.
- Capture is not memory. Capture is the audit log; memory is the governed surface.
- Recall is not retrieval. Retrieval queries the graph; recall queries promoted memory only.
- Auto-promotion is not automatic. It is an explicit pack policy for specific low-risk classes.