Brain/Spine Platform And Governed Memory Deep Dive 1 of 2
Date: 2026-04-21
Status: technical architecture note
AI governance platforms need a deterministic control substrate around
stochastic reasoning. This stack separates product surfaces, operational
workflow truth, semantic reasoning, authority compilation, lower acceptance,
and raw execution mechanics so AI-generated work can become governable
enterprise state instead of opaque agent output.
Memory belongs in that same control model. It is not a convenience feature or
an implementation detail of retrieval. Memory is a future control input. If a
remembered fragment can influence a mutation, approval, plan, tool call,
customer-facing answer, or operator decision, then that fragment participates
in the control plane and must carry provenance, scope, staleness, revocation,
and ownership.
Primary repository surfaces:
- GitHub - nshkrdotcom/app_kit: Shared app-facing surface monorepo for the nshkr platform core: composition, wiring, host-facing surfaces, default bridges across outer_brain, Citadel, jido_integration, and read-model publication, with a stable entrypoint for product applications that should not stitch the lower stack manually. · GitHub
- GitHub - nshkrdotcom/mezzanine: Neutral high-level reusable monorepo for the nshkr stack: Ash-driven business semantics, configurable workflow machinery, operational state models, and reusable application logic above AppKit and below proving-ground products, built to run global AI operations across distributed clusters through pure effects projected to execution_plane. · GitHub
- GitHub - nshkrdotcom/outer_brain: Semantic runtime above Citadel for raw language intake, context assembly, model orchestration, semantic journaling, reply publication, and restart-safe intent synthesis into structured policy decisions across the stack. · GitHub
- GitHub - nshkrdotcom/citadel: The command and control layer for the AI-powered enterprise · GitHub
- GitHub - agentjido/jido_integration · GitHub
- GitHub - nshkrdotcom/execution_plane: Execution Plane is an Elixir/OTP runtime substrate for boundary-aware AI infrastructure, unifying process execution, protocol framing, transport lifecycle, realtime streams, JSON-RPC control lanes, and future sandbox-backed placement under one composable kernel for agentic systems. · GitHub
- GitHub - nshkrdotcom/ground_plane: Shared lower infrastructure monorepo for the nshkr platform core: contracts, Postgres durability helpers, projection publication glue, lease and fence primitives, replay-safe ids, and common runtime infrastructure used by outer_brain, Citadel, jido_integration, and app-facing surfaces. · GitHub
- GitHub - nshkrdotcom/stack_lab: Local distributed-development harness and proving ground for the full stack: repeatable single-node and multi-node boot, Postgres-backed durability drills, fault injection, trace plumbing, end-to-end examples, and operator-facing smoke paths for outer_brain, Citadel, jido_integration, and execution_plane development. · GitHub
- GitHub - nshkrdotcom/AITrace: The unified observability layer for the AI Control Plane · GitHub
Executive Thesis
This architecture is best understood as a monolith-compatible, physically
bounded control platform for agentic execution.
It is not a conventional monolith where every subsystem can reach into the same
database and call any internal module. It is also not a premature microservice
mesh. The intended first deployment can run as a single node or single
application assembly, but the boundaries are real: public DTOs, repo/package
ownership, no-bypass gates, lease scopes, idempotency keys, authority packets,
fences, claim-checks, audit facts, and projection contracts. The system pays
the boundary tax early so that later distribution is a deployment change and
capacity exercise, not an architectural rewrite.
The platform separates four concerns that are often collapsed in simpler agent
systems:
- Product-facing application surfaces.
- Deterministic workflow and governance state.
- Semantic reasoning and context assembly.
- Lower execution, connector, and runtime facts.
The named stack components map to those concerns:
- AppKit is the northbound product and operator boundary.
- Mezzanine is the reusable deterministic operational substrate: packs,
workflows, leases, decisions, evidence, audit, projections, archival, and
operator/control-room state.
- OuterBrain is the semantic runtime: context packs, prompts, semantic
journals, strategy checkpoints, normalized semantic failures, and reply
publication.
- Citadel is the deterministic Brain kernel: structured host ingress,
authority, policy compilation, local continuity, planning context, and
Brain-to-Spine handoff.
- Jido Integration is the Spine/lower acceptance gateway: durable intake,
connector contracts, credential and auth lifecycle, lower facts,
tenant-scoped substrate reads, review projections, and sidecar anchors.
- Execution Plane is the hazmat runtime zone: raw mechanics, placement,
process/HTTP/JSON-RPC lanes, attach/stream pressure, and sandbox-adjacent
execution concerns.
- Ground Plane supplies shared primitive contracts.
- StackLab proves the assembled system and its failure modes.
- AITrace can provide reasoning and execution observability, but is not truth.
Memory integration falls out of this architecture. Memory should not be
modeled as one central database and should not be assigned wholesale to a
single sidecar. In this stack, memory integration is a governed pair of planes:
- The recall plane: read-only, provenance-bearing context admission into
semantic reasoning.
- The promotion plane: evidence-backed, reviewable, revocable projection of
durable outcomes into future recall surfaces.
The recall plane is where memory may influence a model. The promotion plane is
where outcomes become eligible to inform later runs. Those planes must be
separate because an AI system that can freely read and write its own memory
inside the same reasoning loop has created an unreviewed control path.
The stack already contains the beginning of that separation:
- OuterBrain owns semantic context assembly and explicitly rejects provider
memory, RAG engines, and model-specific cognition as platform truth.
- Citadel owns host-local authority, planning context, and an advisory memory
record shape.
- Mezzanine owns the pack-level context-source declarations, trusted context
adapter activation gates, workflow/evidence boundaries, and tenant-scoped
lower-read leases.
- Jido Integration owns lower execution facts and a narrow derived-state
attachment seam for higher-order sidecars.
- AppKit owns northbound boundary enforcement so product apps cannot bypass
those lower owners.
That shape is more sophisticated than assigning memory wholesale to one
sidecar. A memory projection sidecar can be valid, but it should be one
implementation of the promotion plane, not the definition of memory integration
for the platform.
Why Serious Engineers Will Challenge This
The strongest objection to this architecture is correct: it is complex.
A battle-tested distributed systems engineer will ask why this is not just:
- one application database
- one workflow engine
- one vector store
- one job queue
- one agent runtime
- one observability stack
That simpler architecture is often the right answer for a small product. It is
not obviously the right answer for an AI governance platform where stochastic
model output can trigger external side effects, update durable enterprise
state, cross tenant boundaries, enter audit trails, or become context for later
automated action.
The platform should accept complexity only where it protects an invariant.
Every boundary in this stack needs to justify itself by preserving at least one
of these properties:
- ownership: one component owns a category of truth
- replay: state can be reconstructed after restart without asking a live
process what happened
- idempotency: retries do not duplicate effects
- tenancy: reads and writes carry explicit tenant and installation scope
- authority: mutations are admitted only after policy compilation
- review: human or automated gates are durable state transitions, not UI
affordances
- revocation: leases, credentials, adapters, and memory fragments can be
invalidated
- evidence: actions and projections can be traced back to source records
- blast-radius control: raw runtime mechanics cannot leak upward as product
truth
If a boundary does not preserve one of those properties, it is probably
ceremony. If it does, it is not ceremony; it is the point of the system.
The core design wager is that AI agents should be treated as volatile,
non-deterministic compute nodes inside a deterministic governance substrate.
The model may reason, summarize, plan, and propose. The deterministic platform
owns identity, leases, state transitions, idempotency, review state, audit,
projection, revocation, and replay. That split is the reason the architecture
looks heavier than a normal agent loop.
The complexity ledger should be explicit:
| Seam |
Complexity Introduced |
Invariant Protected |
Proof Mechanism |
| Product → AppKit |
Product code must use DTO surfaces instead of direct lower imports |
Product apps cannot bypass governed writes, operator reads, reviews, or leased lower reads |
no-bypass scans, AppKit surface tests, product certification DTOs |
| AppKit → Mezzanine |
Northbound DTO mapping and backend behaviours |
Product surfaces do not own workflow, installation, review, lease, or lower-fact truth |
schema registry verification, bridge contract tests |
| Mezzanine → OuterBrain |
Context-source descriptors and semantic-runtime boundary |
Semantic reasoning can use context without owning durable workflow truth |
trusted adapter validation, context-pack provenance, semantic failure carriers |
| OuterBrain → Citadel |
Semantic output becomes structured Brain intent |
Model output cannot directly mutate lower systems |
authority compilation, semantic validation, normalized failure routing |
| Citadel → Spine |
Governed handoff packets, outbox, resync |
Brain intent crosses into lower truth once, idempotently, with receipts |
stable identifiers, downstream receipts, restart reconciliation |
| Spine → Execution Plane |
Lower runtime packetization and narrowed scopes |
Raw mechanics cannot learn product truth or widen authority |
lower contracts, runtime conformance, attach/stream pressure tests |
| Mezzanine → memory projection |
Promotion coordinator and evidence refs |
Memory cannot become an unreviewed second ledger |
promotion decisions, audit facts, revocation tests |
| Memory → OuterBrain |
Read-only recall request/response shape |
Retrieved context cannot mutate state or smuggle hidden authority |
read-only adapter contract, provenance checks, negative recall tests |
This is also the standard for deleting complexity. If a seam cannot name an
invariant and a proof mechanism, it should be simplified or removed. The
architecture is defensible only if its boundaries are continuously executable,
not merely described.
Why Memory Needs Governance
Memory governance is not about making a vector database bureaucratic. It is
about recognizing what memory does in an agentic system.
In a conventional application, cached context is often an optimization. In an
AI execution platform, memory can become a hidden policy input. A remembered
preference can change a tool call. A recalled incident can bias a review. A
summarized customer conversation can influence a future deployment. A stale
fragment can cause a model to reapply an obsolete instruction. A cross-tenant
fragment can leak data. A provider-native memory feature can persist secrets
outside the platform’s audit and revocation model.
So the question is not “why govern memory?” The question is “when may a stored
or retrieved fact influence a future action?” The answer must be explicit.
A governed memory fragment needs to carry at least:
- source: what truth record, evidence record, artifact, review, or semantic
session produced it
- scope: which tenant, installation, actor, subject, workflow, session, and
policy context can see it
- class: whether it is advisory, semantic-session state, durable derived
projection, operator annotation, or incident/forensic evidence
- staleness: whether the underlying source has changed
- revocation: whether the fragment or source has been suppressed, redacted, or
invalidated
- admissibility: which policy or trusted adapter made it available for recall
- conflict owner: which component wins if the memory disagrees with source
truth
Without those fields, memory is an untyped side channel. A side channel that
influences future actions is a bypass.
Platform Plane Map
%%{init: {"theme": "base", "themeVariables": {"fontFamily": "Inter, ui-sans-serif, system-ui", "primaryColor": "#f8fafc", "primaryTextColor": "#0f172a", "primaryBorderColor": "#475569", "lineColor": "#475569", "secondaryColor": "#e0f2fe", "tertiaryColor": "#fef3c7"}}}%%
flowchart TB
subgraph ProductPlane["Product and operator plane"]
Product["Product app / operator shell"]
AppKit["AppKit<br/>northbound governed surfaces"]
end
subgraph OperationalPlane["Deterministic operational plane"]
Mezz["Mezzanine<br/>packs, workflow, leases, decisions, evidence, projections"]
end
subgraph BrainPlane["Brain plane"]
OB["OuterBrain<br/>semantic runtime and context assembly"]
Citadel["Citadel<br/>authority, policy, continuity, Brain handoff"]
end
subgraph SpinePlane["Spine and lower truth plane"]
Spine["Jido Integration<br/>durable intake, connector contracts, lower facts"]
Hazmat["Execution Plane<br/>raw runtime mechanics and placement"]
end
subgraph ProofPlane["Proof and observability"]
StackLab["StackLab<br/>assembled proofs and drills"]
Trace["AITrace / telemetry<br/>trace joins and execution cinema"]
end
Product --> AppKit
AppKit --> Mezz
Mezz --> OB
OB --> Citadel
Citadel --> Spine
Spine --> Hazmat
Mezz -. "operator projections / reviews" .-> AppKit
Spine -. "lower facts / receipts" .-> Mezz
Hazmat -. "raw outcomes" .-> Spine
StackLab -. "proves seams" .-> AppKit
StackLab -. "fault drills" .-> Spine
Trace -. "trace_id joins" .-> Product
Trace -. "trace_id joins" .-> Hazmat
classDef product fill:#e0f2fe,stroke:#0369a1,stroke-width:2px,color:#0f172a;
classDef operational fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#0f172a;
classDef brain fill:#f0fdf4,stroke:#15803d,stroke-width:2px,color:#0f172a;
classDef spine fill:#f1f5f9,stroke:#475569,stroke-width:2px,color:#0f172a;
classDef proof fill:#fae8ff,stroke:#a21caf,stroke-width:2px,color:#0f172a;
class Product,AppKit product;
class Mezz operational;
class OB,Citadel brain;
class Spine,Hazmat spine;
class StackLab,Trace proof;
style ProductPlane fill:#f8fafc,stroke:#0369a1,stroke-width:2px,color:#0f172a;
style OperationalPlane fill:#fff7ed,stroke:#b45309,stroke-width:2px,color:#0f172a;
style BrainPlane fill:#f0fdf4,stroke:#15803d,stroke-width:2px,color:#0f172a;
style SpinePlane fill:#f8fafc,stroke:#475569,stroke-width:2px,color:#0f172a;
style ProofPlane fill:#fdf4ff,stroke:#a21caf,stroke-width:2px,color:#0f172a;
This diagram is the simplest mental model:
- AppKit keeps products honest.
- Mezzanine keeps operations durable and reusable.
- OuterBrain lets stochastic reasoning happen without owning durable truth.
- Citadel turns semantic or typed intent into governed Brain packets.
- Jido Integration accepts or rejects lower work and owns lower-fact truth.
- Execution Plane runs dangerous mechanics without learning product meaning.
The spine-to-hazmat split is important here because raw execution is below the
governance and acceptance layers. Products and semantic runtimes do not scrape
it directly.
Monolith First, Physically Bounded From Day One
The initial deployment should be allowed to run as a monolith.
That does not mean the architecture should be a monolith internally. A useful
monolith for this system has physical boundaries inside the codebase:
- separate repos and packages for owner domains
- public DTOs instead of shared internal structs
- explicit contract packets instead of PID or process identity leakage
- no-bypass scanners to prevent product and AppKit drift into lower layers
- idempotency keys and stable identifiers at every handoff
- lease and authorization scopes on lower reads and stream attachment
- audit and evidence records before derived projections
- clear owner-of-truth rules for resync after restart
This lets the first deployment avoid premature distributed consensus while
still proving the system will survive distribution later.
%%{init: {"theme": "base", "themeVariables": {"fontFamily": "Inter, ui-sans-serif, system-ui", "primaryColor": "#f8fafc", "primaryTextColor": "#0f172a", "primaryBorderColor": "#475569", "lineColor": "#64748b", "secondaryColor": "#ecfeff", "tertiaryColor": "#fef9c3"}}}%%
flowchart TD
subgraph Today["Initial deployment: one deployable assembly"]
TApp["AppKit"]
TMezz["Mezzanine"]
TOB["OuterBrain"]
TCit["Citadel"]
TSpine["Spine"]
THaz["Execution Plane"]
TApp --> TMezz --> TOB --> TCit --> TSpine --> THaz
end
subgraph Later["Later deployment: cells and independent durability groups"]
PCell["Product/API cell"]
OCell["Operational workflow cell"]
BCell["Brain semantic/authority cell"]
SCell["Spine intake cell"]
ECell["Execution cells"]
PCell --> OCell
OCell --> BCell
BCell --> SCell
SCell --> ECell
end
TApp -. "same DTOs, leases, ids, packets" .-> PCell
TMezz -. "same workflow/evidence contracts" .-> OCell
TOB -. "same context/provenance contracts" .-> BCell
TCit -. "same authority handoff contracts" .-> BCell
TSpine -. "same lower-fact contracts" .-> SCell
THaz -. "same runtime contracts" .-> ECell
classDef today fill:#e0f2fe,stroke:#0369a1,stroke-width:2px,color:#0f172a;
classDef later fill:#f0fdf4,stroke:#15803d,stroke-width:2px,color:#0f172a;
class TApp,TMezz,TOB,TCit,TSpine,THaz today;
class PCell,OCell,BCell,SCell,ECell later;
style Today fill:#f8fafc,stroke:#0369a1,stroke-width:2px,color:#0f172a;
style Later fill:#f0fdf4,stroke:#15803d,stroke-width:2px,color:#0f172a;
The practical rule is: local function calls are fine during the monolith
phase, but the payloads must already be serializable contract payloads with
stable logical identity. If an internal handoff requires a process identifier,
shared mutable state, unscoped direct SQL, or a live in-memory object, it is
not a future distributed seam.
End-To-End Operating Model
A governed run should be explainable without naming implementation details.
- A product or operator enters through AppKit with a request context.
- AppKit validates the product boundary and calls the appropriate northbound
surface.
- Mezzanine resolves installation, pack revision, workflow state, lease
posture, decision gates, and configured context sources.
- If semantic reasoning is required, Mezzanine enters OuterBrain through the
semantic surface with context-source declarations and runtime bindings.
- OuterBrain assembles a read-only context pack from trusted adapters,
records provenance and diagnostics, and produces semantic output or a
normalized semantic failure.
- Citadel receives typed or semantic intent, constructs deterministic Brain
context, applies authority and policy, and emits a governed handoff.
- Jido Integration accepts or rejects the lower submission, narrows auth and
runtime scope, records durable lower facts, and exposes bounded reads.
- Execution Plane performs raw mechanics and returns lower outcomes to the
Spine.
- Mezzanine updates workflow, evidence, decision, projection, audit, and
archival truth.
- AppKit renders product/operator state from northbound DTOs.
- Memory recall and promotion happen only at their allowed seams: read-only
context admission before reasoning, and evidence-backed derived projection
after durable outcomes.
sequenceDiagram
autonumber
participant Product as Product / Operator
participant AppKit as AppKit
participant Mezz as Mezzanine
participant OB as OuterBrain
participant Citadel as Citadel
participant Spine as Jido Integration
participant Hazmat as Execution Plane
participant Memory as Governed Memory Surfaces
Product->>AppKit: Request with tenant, actor, trace
AppKit->>Mezz: Northbound work/control/query call
Mezz->>Mezz: Resolve pack, workflow, leases, gates
Mezz->>OB: Semantic task with trusted context declarations
OB->>Memory: Read-only recall request with scope and provenance requirements
Memory-->>OB: Context fragments with provenance/staleness
OB->>OB: Build context pack and semantic journal
OB->>Citadel: Semantic intent / normalized failure
Citadel->>Citadel: Compile authority and planning context
Citadel->>Spine: Governed lower handoff
Spine->>Spine: Accept, reject, narrow, or fence
Spine->>Hazmat: Runtime execution request
Hazmat-->>Spine: Raw outcome and runtime facts
Spine-->>Mezz: Lower receipts and bounded facts
Mezz->>Mezz: Evidence, workflow, review, audit, projection
Mezz->>Memory: Eligible promotion event with evidence refs
Memory-->>Mezz: Derived projection receipt
Mezz-->>AppKit: Operator/product DTOs
AppKit-->>Product: Governed state and actions
The sequence is illustrative. Many product reads stop at AppKit and Mezzanine.
Many typed commands do not need semantic reasoning. Some operator actions are
local Mezzanine workflow signals. When a request crosses layers, the boundary
shape stays predictable.
Brain, Spine, And The Middle Layer
The architecture uses “Brain” and “Spine” as a durability and responsibility
split, not as branding.
The Brain is where intent is interpreted and governed:
- OuterBrain handles semantic interpretation, context assembly, prompt
construction, provider-neutral semantic failures, and semantic reply
publication.
- Citadel handles deterministic authority, structured ingress, host-local
continuity, policy compilation, planning context, and Brain-to-Spine
handoff.
The Spine is where accepted lower work becomes durable operational fact:
- Jido Integration owns durable lower intake, connector contracts, auth and
credential lifecycle, lower receipts, lower events, lower artifact refs,
tenant-scoped readbacks, review projections, and derived-state anchors.
Mezzanine sits above and around both as the neutral operational layer:
- It is not the semantic Brain.
- It is not the lower Spine.
- It is the durable product-neutral machinery for packs, installation
activation, workflow runtime, execution ledger, lifecycle, decisions,
reviews, evidence, projections, operator control, audit, archival, and
lower-read leasing.
That middle layer is why the stack can support many products without each
product becoming a mini control plane. Products call AppKit. AppKit delegates
to Mezzanine. Mezzanine composes the Brain and Spine according to pack,
workflow, policy, tenant, and installation state.
The Hyperscalar Enterprise Shape
The long-term enterprise version of this architecture is cell-based.
An initial monolith can prove the contracts. A hyperscalar deployment can split
by region, tenant class, product family, data residency zone, execution risk,
or workload tier without changing the logical ownership model.
A plausible global shape is:
- product/API cells close to users and enterprise control planes
- regional Mezzanine cells for workflow, decision, evidence, and operator
projections
- regional or tenant-isolated Brain cells for semantic runtime and authority
compilation
- Spine intake cells with durable lower ledgers and connector/auth control
- execution cells near data, sandboxes, GPUs, private networks, or customer
regions
- cold archival and incident-export systems for long-retention evidence
- memory projection cells scoped by tenant, region, data class, and policy
- proof cells that continuously run StackLab-style drills against staged and
production-like seams
In that world, AppKit remains the product boundary, Mezzanine remains the
operational substrate, OuterBrain remains semantic, Citadel remains authority,
Jido Integration remains lower acceptance, and Execution Plane remains raw
runtime mechanics. The implementation may become distributed, but ownership
does not dissolve.
The enterprise value is not only scale. It is explainability under pressure.
When a global customer asks why an automated agent changed something, the
platform should be able to reconstruct:
- the tenant and actor context
- the installation and pack revision
- the semantic context that was admitted
- the authority and policy decisions
- the lower execution receipts
- the review or waiver state
- the memory fragments that influenced the run
- the evidence that allowed any memory promotion
- the revocations or suppressions in force at the time
- the final product/operator projection
That is the difference between an agent demo and an enterprise control plane.
Memory Thesis
Memory in a governed agentic platform is not a truth source. It is an
admissible context source with provenance, scope, staleness, and revocation.
The platform truth sources remain:
- semantic-session facts and prompt/context hashes owned by OuterBrain
- authority, policy, host context, and advisory planning records owned by
Citadel
- workflow, installation, lease, decision, audit, projection, archival, and
control-room facts owned by Mezzanine
- lower run, attempt, event, artifact, connector, and target facts owned by
Jido Integration and Execution Plane
Memory may summarize those truths, index them, rank them, cluster them, or make
them retrievable, but it must not replace them.
A memory fragment is safe to use only when the consumer can answer:
- Who is allowed to see this fragment?
- What source record or evidence does it summarize?
- Which policy or governance decision made it admissible?
- Is it stale, revoked, quarantined, or redacted?
- Is it advisory context, durable evidence, or an operator-approved derived
projection?
- Which component owns the underlying truth if a conflict appears?
The answer must be carried as structured data, not as tribal knowledge in an
adapter.
Sidecar-Only Memory Is Insufficient
A memory projection sidecar can be a compliant implementation detail, but it is
too narrow to define platform memory.
Valid sidecar constraints:
- OuterBrain does not own provider memory, RAG engines, or model-native memory
as platform truth.
- OuterBrain context adapters are read-only contributors to context-pack
assembly.
- The Jido Integration contracts define a higher-order sidecar seam on the
core/contracts seam.
- Jido Integration’s
DerivedStateAttachment exists precisely so sidecars can
persist derived enrichments while anchoring them to SubjectRef,
EvidenceRef, and GovernanceRef.
- Memory-like sidecars must not copy lower-gateway truth and become a second
control-plane ledger.
Limits of a sidecar-only model:
- The stack does not define memory as a single sidecar-owned database. It
defines memory-related seams across OuterBrain, Citadel, Mezzanine, and Jido
Integration.
- “Only persists derived state” is necessary for lower-fact sidecars, but it
does not cover all memory classes. Citadel has advisory memory records.
OuterBrain has semantic-session context packs and provenance. Mezzanine has
context-source declarations and trusted adapter activation gates.
- “Storage after action passes through Jido Integration” is too simple.
Durable memory promotion may need evidence from OuterBrain semantic
validation, Citadel authority, Mezzanine decisions or reviews, Jido lower
outcomes, and operator suppression or revocation records.
- A future memory system should not require every memory implementation to live
under Jido Integration. It should require every memory implementation to
satisfy the same evidence, governance, recall, and revocation contracts.
A memory projection sidecar is therefore one participant in the promotion
plane. It is not the platform’s memory architecture.
Stack Responsibilities
OuterBrain
OuterBrain is the provider-neutral semantic-runtime gateway above Citadel. It
owns durable semantic-session truth, prompt and strategy shaping, context-pack
construction, tool-manifest snapshots, semantic quality checkpoints,
provider-neutral semantic failure carriers, live semantic-session fencing, and
restart-safe reply publication.
The important memory-relevant contracts are:
OuterBrain.ContextAdapterReadOnly.v1OuterBrain.SemanticContextProvenance.v1OuterBrain.SemanticDuplicateSuppression.v1OuterBrain.SemanticActivityNormalized.v1OuterBrain.SemanticActivityPayloadBoundary.v1Platform.SuppressionVisibility.v1OuterBrain.Contracts.ReplyPublicationOuterBrain.Prompting.ContextPackOuterBrain.Prompting.ContextFragmentOuterBrain.Prompting.ContextAdapterRegistry
OuterBrain’s memory stance is strict:
- It can assemble context.
- It can read from configured context adapters.
- It can record prompt hashes, context hashes, provenance refs, diagnostics
refs, claim-check refs, and bounded routing facts.
- It can publish provisional and final semantic replies with deterministic
suppression.
- It must not treat raw provider memory, RAG state, provider-native bodies, raw
prompts, raw context packs, raw artifacts, or workflow history as northbound
DTO truth.
- It must not grant context adapters mutation permissions during semantic
evaluation.
In other words, OuterBrain is the recall orchestrator and semantic provenance
producer. It is not the durable memory store.
The context-pack path is especially important. ContextPack.build/3
takes semantic state, declared context sources, runtime bindings, and an
adapter registry. For each configured source, it sends a bounded request to the
registered adapter and expects a list of structured fragments. Each fragment
must include content, provenance, staleness, and metadata. The pack records the
source report, adapter key, fragment count, merge strategy, and degraded/error
state.
This is the platform’s implemented recall interface.
Citadel
Citadel is the host-local Brain kernel. It accepts structured ingress at the
kernel boundary, compiles authority and planning decisions, preserves host-local
session continuity, and projects Brain-authored packets toward the shared
Jido Integration contracts layer.
Citadel owns:
- canonical Brain context construction
- structured host ingress
- authority packet construction
- policy and planning context
- host-local session continuity
- runtime coordination
- projection into invocation, review, trace, and derived-state seams
Citadel explicitly does not own durable lower run, attempt, review, approval,
artifact, credential, provider runtime, or raw natural-language truth.
Citadel currently contains a memory-relevant value:
Citadel.MemoryRecord
That record has:
memory_idscope_refsession_idkindsummarysubject_linksevidence_linksexpires_atconfidencemetadata
Citadel also exposes Citadel.Ports.Memory, an advisory memory seam with:
put_memory_record/1get_memory_record/2rank_memory_records/1
The port contract is deliberately advisory. A write can be
:stable_put_by_id or :best_effort. Reads are keyed lexically by
memory_id or ranked by scope, session, kind, and limit. This is useful for
host-local planning and summaries, but it is not a ledger.
Citadel therefore provides a second memory class:
- OuterBrain memory is recall context for semantic reasoning.
- Citadel memory is advisory planning context for the Brain kernel.
Both may point at the same source facts, but neither owns those facts.
Mezzanine
Mezzanine is the neutral business-semantics and workflow substrate. It owns the
platform machinery that decides which contexts can be activated, which lower
facts can be read, which workflows are durable, and which reviews or operator
actions are authoritative.
Memory-relevant Mezzanine seams include:
Mezzanine.Pack.ContextSourceSpecMezzanine.Authoring.BundleMezzanine.ConfigRegistryMezzanine.WorkflowRuntimeMezzanine.WorkflowRuntime.ActivitySideEffectIdempotencyMezzanine.LeasingMezzanine.IntegrationBridge.ReadDispatcherMezzanine.ControlRoom.IncidentBundleMezzanine.ControlRoom.IncidentExportBundleMezzanine.ControlRoom.ForensicReplayMezzanine.DecisionsMezzanine.Reviews- audit, archival, projection, and retry posture contracts
ContextSourceSpec is the pack-level declaration that a read-only source can
feed OuterBrain context assembly. It carries:
source_refdescriptionbinding_keyusage_phaserequired?timeout_msschema_refmax_fragmentsmerge_strategy
The key point is that a product pack can declare memory-like context sources
without owning memory runtime code. The Mezzanine config registry validates
context adapter descriptors against trusted registry configuration before
activation. Unknown adapters, missing bindings, invalid descriptors, stale
installation revisions, invalid policy refs, and pack-authored platform
migrations are rejected before runtime activation.
That gives the platform a supply-chain and installation gate for memory
adapters.
Mezzanine also controls the lower-fact read path. Its integration bridge
builds a typed Jido.Integration.V2.TenantScope from authorized context,
checks execution lineage, rejects lower-id overrides, and calls the bounded
Jido Integration LowerFacts surface. Product code is expected to enter
through AppKit and carry Mezzanine read leases plus authorization scope.
For memory, this means lower facts can be recalled only through:
- an authorized workflow or operator context
- an execution lineage
- a tenant and installation scope
- lease and revocation checks
- bounded lower-facts operations
Mezzanine is therefore the policy, lease, workflow, and evidence envelope
around memory. It should not become a vector store, but it should govern which
memory adapters are trusted, which facts can be read, and which derived memory
updates can be promoted.
Jido Integration
Jido Integration owns the lower acceptance gateway and public lower contracts
for connector discovery, invocation, auth lifecycle, runtime targeting, review
packet projection, lower facts, and substrate-facing reads.
Memory-relevant Jido Integration contracts include:
Jido.Integration.V2.SubjectRefJido.Integration.V2.EvidenceRefJido.Integration.V2.GovernanceRefJido.Integration.V2.DerivedStateAttachmentJido.Integration.V2.ReviewProjectionJido.Integration.V2.TenantScopeJido.Integration.V2.LowerFactsJido.Integration.V2.SubstrateReadSliceExecutionEvent.v1ExecutionOutcome.v1
The lower-facts surface is intentionally bounded:
- submission receipts
- run state
- attempt state
- event streams
- artifact refs
- scoped trace resolution
It does not assemble product projections, operator packets, memory summaries,
or review aggregates.
DerivedStateAttachment is the key memory-adjacent contract. It states that
higher-order repos may persist their own enrichments, memories, lineage, and
scores, but those records must remain anchored to node-local source truth
through explicit subject, evidence, and governance refs.
That is the right sidecar contract for a future memory projection service:
- store repo-local memory records
- anchor each record to
SubjectRef, EvidenceRef, and GovernanceRef
- avoid copying lower-gateway-owned truth
- avoid becoming a second review, approval, run, or artifact ledger
- expose derived state through its own bounded API
But Jido Integration should not be the semantic recall owner. Its role is lower
truth and sidecar anchoring.
AppKit
AppKit is the northbound application-surface and product-boundary enforcement
point. Product repos must use AppKit surfaces for governed writes, operator
reads, reviews, installation bootstrap, semantic assist, trace lookup, and
leased lower read access.
For memory integration, AppKit matters because it prevents product apps from
calling Mezzanine, Citadel, Jido Integration, or Execution Plane directly for
governed behavior. A product can author a pure Mezzanine.Pack model contract,
including context source declarations, but runtime behavior must flow through
AppKit and the lower owner seams.
That means memory is not allowed to become a product-local bypass path.
Execution Plane
Execution Plane owns lower runtime execution and effect projection mechanics.
It should not own semantic memory. It may produce lower events, artifacts,
process output, HTTP results, JSON-RPC results, and runtime state that later
become eligible for memory projection, but memory sidecars should consume those
through Jido Integration and Mezzanine, not through direct runtime scraping.
Ground Plane, StackLab, And AITrace
Ground Plane supplies generic lower contracts and projection helpers. It is
not the memory owner.
StackLab is the proving harness. It should prove that memory recall and memory
promotion do not bypass AppKit, Mezzanine leases, Citadel authority, OuterBrain
semantic boundaries, or Jido Integration tenant scope.
AITrace can be useful as an observability layer for reasoning spans, tool
calls, and trace visualization. It should be treated as trace evidence or
developer observability, not as memory truth.
Ownership Diagram
%%{init: {"theme": "base", "themeVariables": {"fontFamily": "Inter, ui-sans-serif, system-ui", "primaryColor": "#f8fafc", "primaryTextColor": "#0f172a", "primaryBorderColor": "#475569", "lineColor": "#475569", "secondaryColor": "#ecfeff", "tertiaryColor": "#fef9c3"}}}%%
flowchart TB
Product["Product / operator UI"]
AppKit["AppKit<br />northbound boundary"]
Mezz["Mezzanine<br />workflow, packs, leases, evidence"]
OB["OuterBrain<br />semantic context and provenance"]
Citadel["Citadel<br />authority, planning, advisory memory"]
JI["Jido Integration<br />lower facts and sidecar anchors"]
EP["Execution Plane<br />runtime execution"]
Sidecar["Memory projection sidecar<br />optional, derived state"]
Product --> AppKit
AppKit --> Mezz
Mezz --> OB
OB --> Citadel
Citadel --> JI
JI --> EP
Mezz -. "trusted context source descriptors" .-> OB
OB -. "read-only context fragments" .-> Citadel
Mezz -. "tenant-scoped lower reads" .-> JI
JI -. "SubjectRef / EvidenceRef / GovernanceRef" .-> Sidecar
Sidecar -. "recall fragments with provenance" .-> OB
classDef boundary fill:#e0f2fe,stroke:#0369a1,stroke-width:2px,color:#0f172a;
classDef semantic fill:#f0fdf4,stroke:#15803d,stroke-width:2px,color:#0f172a;
classDef governance fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#0f172a;
classDef lower fill:#f1f5f9,stroke:#475569,stroke-width:2px,color:#0f172a;
classDef sidecar fill:#fae8ff,stroke:#a21caf,stroke-width:2px,color:#0f172a;
class Product,AppKit boundary;
class OB semantic;
class Citadel,Mezz governance;
class JI,EP lower;
class Sidecar sidecar;
Memory Classes
The word “memory” hides several different data classes. The platform should
name them separately.
1. Semantic-Session State
Owner: OuterBrain
Purpose:
- preserve the state of one semantic interaction or semantic session
- construct prompt/context packs
- maintain commitments and unresolved questions
- support deterministic reply publication and restart-safe recovery
Allowed to influence:
- prompt assembly
- semantic strategy
- reply publication
- semantic validation and reask paths
Not allowed to replace:
- lower run facts
- workflow facts
- authority decisions
- review decisions
- product state
2. Advisory Planning Memory
Owner: Citadel, with backing implementation behind Citadel.Ports.Memory
Purpose:
- expose host-local summaries, prior choices, preferences, lessons, or planning
hints
- give the Brain kernel an advisory recall surface
- preserve a lexical
memory_id for stable lookup
Allowed to influence:
- planning
- summarization
- host-local continuity
- policy-context enrichment when explicitly admitted
Not allowed to replace:
- authority packets
- execution governance
- review packets
- derived-state attachment
- lower evidence
3. Pack-Declared Context Sources
Owner: Mezzanine for declaration and activation; OuterBrain for runtime
context assembly
Purpose:
- declare memory-like context sources in pack manifests
- bind source refs such as
workspace_memory to trusted adapter keys
- restrict usage phase, fragment count, timeout, schema, and merge strategy
Allowed to influence:
- OuterBrain context-pack assembly
- semantic recall during preprocessing, retrieval, or repair
Not allowed to replace:
- adapter trust registry
- runtime authorization
- provenance checks
cont…
