Skip to content
Press / to search

Memory Fabric

Concrete implementation of the promotion-aware memory plane — storage, review queue, consolidation, redaction.

Implementation GuideLast reviewed: Edit on GitHub
At a glance

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

  1. Capture — every tool result, decision, and turn-level effect appends to an immutable event log; never queried by the Compiler directly.
  2. Extract — a consolidator transforms captures into typed candidate facts (entity, predicate, value, evidence_refs, confidence, class).
  3. Queue — candidates above a confidence floor enter the review queue; auto-approval policies may admit specific low-risk classes.
  4. Promote — approved candidates are tier-routed (working / episodic / semantic / durable) with a contradiction check.
  5. Recall — the Compiler queries promoted memory only, scoped by tenant, role, classification, and intent.

Storage tiers

TierBackingRetentionIndexing
workingsession store (in-process or Redis)minutes to hoursby session_id
episodictenant-scoped document storehours to daysby user_id + workflow_id
semantictenant-scoped graph + vector indexlong-lived, explicit deprecationby entity CEID
durableappend-only log + indexed projectionmonths 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_check and contradiction_check results computed at queue time.
  • auto_promote_eligible flag based on the pack’s promotion_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 + index

Read-side context assembly

When the Compiler recalls memory, the Fabric:

  • filters by tenant_id, role, and data_classification from 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 classPurposeAllow-list scope
evidence_linkrecord a citation linking a decision to an evidence_refalways allowed for governed decisions
preferencepersist a user preferenceper pack memory_layer.write_classes_allowed
decision_outcomesummarize a completed decisionper pack
correctionfirst-class operator correction; outranks prior on the same keyrequires 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: true markers 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

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.