Memory & Data

Layer 7 of 12·Slice: Infrastructure services·Platform: Redis · Supabase PG17 · QuestDB · Neo4j · Qdrant

Scope of this page. Reference material for the Memory & Data layer: what it owns, what it must not own, and how Synedrix OS implements it today. It is descriptive, not normative — where this page and the Layer Taxonomy Table disagree, the taxonomy table wins.

What this layer is link

Memory & Data persists business state and contextual knowledge, and — per ADR-OS-002 — also owns the memory control plane: the governed process by which a record is formed, consolidated, promoted, recalled, decayed and erased. The layer has always had a memory substrate, five self-hosted stores each answering “where does a byte live”: Redis for hot state, Supabase PG17 for canonical relational truth, QuestDB for time-series, Neo4j for the context graph, and Qdrant for semantic vectors.

The layer count did not change to add this. Memory cognition is a control plane over persistence, in the same relationship Governance (Layer 9) has to execution — not a peer layer beside it. The umbrella term for the whole of Layer 7, substrate and control plane together, is memory fabric. Note that the fabric’s vocabulary also names Langfuse (LLM trace memory) and PostHog (behavioural memory) as two of its “seven stores,” but neither is a memory tier and neither maps to this layer in the platform table below — they remain Layer 10 observability platforms that happen to be readable memory, not tiers any record is write-authoritative in.

flowchart LR
  n1([Memory Data]):::term
  subgraph What it owns
    n2[The tier taxonomy]:::agent
    n3[Record lifecycle]:::agent
    n4[Recall mediation]:::agent
    n5[Promotion]:::agent
  end
  n1 --> n2
  subgraph What it must not own
    n6[Workflow sequencing]:::warn
    n7[Orchestration Layer]:::term
    n6 --> n7
    n8[UI logic]:::warn
    n9[Human Interface Layer]:::term
    n8 --> n9
    n10[Retention policy]:::warn
    n11[Business Instance Layer]:::term
    n10 --> n11
    n12[Context assembly for a specific agent run]:::warn
    n13[Agent Runtime Layer]:::term
    n12 --> n13
  end
  n1 --> n6
  subgraph Interfaces with
    n14[Agent Runtime]:::check
    n15[Orchestration]:::check
    n16[Governance Controls]:::check
    n17[Observability]:::check
  end
  n1 --> n14

What it owns link

Per the Layer Taxonomy Table, Memory & Data owns the stores themselves and, since ADR-OS-002, the lifecycle that governs what moves through them. Concretely, that means:

• Transactional databases, vector stores, graph stores, caches and audit state — the five-store substrate
• The tier taxonomy — eight tiers (working, episodic, semantic, procedural, profile, relational, graph, temporal) answering what kind of memory a record is, orthogonal to which store it lives in
• Record lifecycle — formation, consolidation, reflection, promotion, decay and erasure, per the Memory Fabric Spec §5 state machine
• Recall mediation — every memory read is a scoped, authorized tool call, never ambient context injected into an agent’s prompt
• Promotion — the governed transition of a record from one tier to a longer-lived one

Three invariants from CLAUDE.md and the Memory Fabric Spec §10 are load-bearing here and must never be violated: only the Memory Curator (os-agt-010) may commit durable memory — every other agent proposes; memory recall is an authorized tool call, never ambient context; and no memory record crosses a tier boundary without a governed memory.record.promoted event, and erasure leaves a tombstone rather than a silent hole in the audit trail.

What it must not own link

This layer persists and governs the memory lifecycle; it does not sequence work, render a UI, set retention values, or decide what a specific run needs to know. The taxonomy table draws all four boundaries explicitly.

The retention boundary is worth stating precisely because it is easy to blur: Layer 7 owns the retention mechanism — what a retention class means, how decay executes, what a tombstone is — while Layer 12 (business instance) owns the retention values, such as how long an operational-class record survives or what a regulated floor and ceiling are for a given jurisdiction.

Interfaces with link

Memory & Data is read from and written to by nearly every other layer, but four relationships carry the governed traffic:

• Agent Runtime (Layer 4) — LangGraph binds to the fabric through SynedrixMemoryStore, the compliance seam that implements BaseStore while rejecting direct writes and deletes; recall and formation-proposal calls happen on the hot path inside an agent’s run.
• Orchestration (Layer 3) — n8n owns the trigger and sequence for WF-OS-MEMORY-CONSOLIDATE, the scheduled background workflow that invokes the Consolidation & Reflection Agent and, ultimately, the Memory Curator’s commit.
• Governance & Controls (Layer 9) — the Memory Access Broker (os-agt-012) resolves scope before any store is queried, and Policy Guard (os-agt-002) gates promotions into relational, visibility widening beyond tenant, regulated-label promotions, and every erasure.
• Observability (Layer 10) — every recall opens a Langfuse span nested under the agent’s trace, and memory.* events aggregate into QuestDB for fabric-level signals such as memory growth rate and consolidation lag.

How Synedrix OS implements it link

The Memory Fabric Spec is the authoritative specification and its content is extensive. Its eight-tier taxonomy separates what kind of memory a record is from where it is stored: working (Redis, TTL-bound, explicitly never a source of truth), episodic (Supabase-authoritative, Qdrant-projected — the raw material every durable tier derives from), semantic, procedural and profile (same substrate split, each governed by supersession rather than in-place mutation), relational (the tier a domain pack co-owns), graph (Supabase for lineage links, Neo4j via NAMS for entities and edges), and temporal (QuestDB). Every governed record carries a 14-field envelope deliberately mirroring the event envelope — memory_id, tier, scope (tenant-first, always), provenance tracing back to a causing event, derived_from, confidence, validity_interval, consolidation_state, retention_class, and more — so a record with no provenance.source_event_id is non-compliant by construction. The lifecycle runs capture → formation → consolidation → reflection → promotion/decay/demotion → supersession or erasure, with authority split three ways: the Consolidation & Reflection Agent recommends, the Memory Curator commits, the Memory Access Broker approves access — no single agent both proposes and commits. Recall is specified as a tool call bound in active_tool_set (tool:memory-recall, tool:memory-propose) resolved through the same three-layer tool authorization model that governs every other tool, with scope intersected against the requester’s memory_profile and pushed down into the store query before retrieval, never filtered afterward. Promotion requires a memory.record.promoted event carrying the record’s correlation_id and causation_id unchanged, and certain promotions (into relational, widening visibility beyond tenant, regulated-label promotions) additionally require Policy Guard approval. Erasure destroys content in the write-authoritative store and every projection while a tombstone retains memory_id, content_hash, provenance and the approval reference — so a deletion can never silently punch a hole in the audit trail. Contradictions between two records are resolved by supersession, never by deletion.

The Memory Runtime Integration Guide binds that specification to concrete LangGraph and NAMS constructs. SynedrixMemoryStore implements LangGraph’s BaseStore interface as the compliance seam: its aget and asearch methods enforce scope checks and push filters into the query, while aput and adelete reject direct calls outright, routing writes to the tool:memory-propose proposal path instead of allowing an agent to bypass commit authority or erasure approval. Namespaces follow a strict (tenant_id, tier, scope_id) convention with tenant_id always first — fail-safe ordering, so a malformed namespace under-matches and returns nothing rather than leaking another tenant’s memory. The guide also fixes the hot-path/background split: recall and formation-proposal run inside the agent’s turn; consolidation, reflection, decay and demotion run in the scheduled WF-OS-MEMORY-CONSOLIDATE workflow; erasure runs as its own approval-gated, out-of-band compliance workflow.

ADR-OS-002 is the decision record behind both documents. It evaluated two external open-source memory systems — EverOS and NAMS (neo4j-labs/agent-memory) — and reframed the adoption question as a layer question: is memory cognition a peer of persistence (warranting a thirteenth layer) or a control plane over it (extending Layer 7)? It chose the latter, on the same reasoning that keeps Governance and Observability from duplicating the layers they govern. NAMS was adopted as a library over the existing self-hosted Neo4j — not a platform row, the same precedent LangChain set for LangGraph in ADR-OS-001 — while the NAMS hosted service was rejected as proprietary SaaS incompatible with Mode 3. The EverOS model (episode → consolidation → profile/skill distillation) was adopted as the canonical lifecycle; the EverOS runtime was rejected because its LanceDB and SQLite components would duplicate Qdrant and Supabase, breaking the stack’s non-overlapping-responsibilities rule.

Platform mapping link

Five platforms realize this layer, and none of them owns more than the tier(s) it is assigned:

OS agents at this layer link

Two OS agents from the Agent Registry are assigned to Layer 7:

A third memory control-plane agent, the Memory Access Broker (os-agt-012), mediates every recall and write proposal — but its registry entry places it at Layer 9 (Governance & Controls), not Layer 7, because mediating access is a governance function even though the thing it mediates access to lives here.

Layer principles that apply link

Two of the taxonomy table’s layer principles apply directly to this layer, and both were written specifically for it:

• 4. Memory is shared, access is scoped — agents need shared context to collaborate effectively, but memory access must remain selective and policy-aware; the memory_profile recall scope and the tenant-first namespace convention are this principle’s concrete implementation.
• 5. Memory moves only under governance — persisting a fact and deciding it is worth remembering are different acts; a record crosses a tier, is recalled into an agent’s context, or is erased only through a governed path that leaves lineage behind.

Related Synedrix OS documents link

• Layer Taxonomy Table — the authoritative row for this layer.
• Memory Fabric Spec — tier taxonomy, record envelope, lifecycle, recall and promotion contracts, retention and erasure.
• Memory Runtime Integration Guide — SynedrixMemoryStore, the NAMS binding, hot-path vs. background writes.
• ADR-OS-002 — the decision to extend Layer 7 with a control plane and adopt NAMS as a library.
• Agent Runtime Policy Spec — the three-layer tool authorization model memory recall passes through.
• Event Taxonomy Standard — the memory.* event catalog emitted by the control-plane agents.
• Agent Registry — os-agt-010, os-agt-011 and os-agt-012 full contracts.

Synedrix OS · Layer reference · Memory & Data