Orbiplex Memarium

Orbiplex Memarium is the local memory-and-knowledge organ of an Orbiplex Node. Its constitutional mandate is to "preserve what should not disappear." Memarium manages four constitutionally defined memory spaces (personal, community, public, crisis) with space-specific policies for encryption, replication, retention, anonymization, and right-to-forget.

Memarium is an in-process Rust crate compiled with the daemon. It participates in the Node's middleware chain as a post-chain observer (with an optional PreInput context enricher), gaining observational and enrichment access to the peer message pipeline without ever acting as a dispatch-blocking handler. It stands on the existing storage trait boundary rather than inventing a parallel persistence mechanism.

Purpose

The component is responsible for the solution-level execution path of:

• local knowledge storage across four constitutionally defined memory spaces,
• space-specific policy enforcement (encryption, retention, replication, forget),
• middleware chain observation and context enrichment,
• host capability exposure for agents and middleware (memarium.read, memarium.write, memarium.index, memarium.cache, memarium.declassify),
• Agora synchronization tracking (recording outbound submissions and their confirmation status as local facts),
• archival integration (recording handoff provenance and caching retrieval results),
• crisis space management as a constitutional obligation.

Scope

This document defines solution-level responsibilities of the Memarium component.

It does not define:

• concrete module layout in an implementation repository,
• federated Memarium replication between nodes (future work),
• full curation or training pipeline (downstream consumers),
• specific full-text search or vector index implementation (runtime concern; see doc/project/60-solutions/022-semantic-index/022-semantic-index.md for the semantic projection boundary),
• frozen archival contract schemas (builds on current draft proposals).

Must Implement

Memory Space Management

Based on:

• doc/normative/20-vision/VISION.md (Memarium, memory spaces)
• doc/normative/40-constitution/CONSTITUTION.md (Art. II.4, V.7)
• doc/project/40-proposals/036-memarium.md

Responsibilities:

• manage four memory spaces (personal, community, public, crisis) as policy envelopes over the shared storage boundary,
• enforce space-specific encryption policy (mandatory for personal, community, crisis; optional for public),
• enforce space-specific retention policy (operator-controlled, group-governed, constitutional-minimum),
• enforce space-specific forget policy (immediate, governed, tombstone, restricted),
• validate cross-space promotion as an explicit transition requiring appropriate autonomy level,
• record promotion provenance as append-only facts.

Status:

• done — four memory spaces, encryption/retention/forget policy enforcement, cross-space promotion, append-only provenance, crisis seed population, and crisis status/resolve read models are implemented. The write path separates payload-envelope validation from policy enforcement, entry/fact ids include a monotonic suffix instead of relying only on wall-clock nanos, cache TTLs are clamped by space policy, and forget rejections carry structured denial reasons. Personal forget can be delegated through scoped passports, public forget tombstones, community forget verifies an append-only governance approval fact referenced by governance_ref before erasure, and crisis forget remains restricted. Operator grant issuance/install flow, lag-forced crisis detector coverage, the full PeerMessageChain/WSS → observer → Memarium query lifecycle, the launcher CLI minimum surface for memarium quarantine {list,accept,reject} / memarium declassify, the enforced strict-mode gate for classification fallback, a classification-aware archival export adapter for archival-package.v1, concrete Whisper and INAC/private AD classification egress adapters, contextual personal-space forget delegation, remote archivist handoff/retrieval control surfaces, and a SQLite derived read sidecar are now represented in code.

Observer-Based Chain Integration

Based on:

• doc/project/40-proposals/027-middleware-peer-message-dispatch.md (chain architecture, observer slots)
• doc/project/40-proposals/036-memarium.md

Responsibilities:

• implement a daemon-side MemariumPostChainAdapter that sees the effective payload (after all middleware mutations), the response, and the dispatch outcome, then forwards the Memarium-domain slice into memarium-runtime,
• compile declarative observe rules from merged middleware configuration at startup,
• match post-chain observations against compiled rules and record MemariumFact entries in the declared space with extracted fields,
• optionally register as per-phase observer for fine-grained visibility into where mutations occurred,
• optionally add a daemon-side PreInput adapter for MemariumContextEnricher semantics to annotate inbound messages with cached knowledge artifacts,
• never block, drop, reject, or mutate peer messages from any chain or observer position.

The observers and handlers are in-process trait implementations compiled into the daemon. They do not use loopback HTTP and share the same StorageRuntime as the rest of the daemon. The daemon owns chain-private traits such as PostChainObserver and PhaseObserver; memarium-runtime owns the neutral MemariumObservation port plus the compatibility observe_dispatch(message_kind, correlation_id, effective_payload) wrapper. This follows the trait-pipeline architecture documented in proposal 027 and the middleware README.

For stratification reasons, the post-chain adapter lives on the daemon side (it bridges daemon-private PostChainEvent/PostChainObserver types into memarium-runtime), while the semantic observer contract stays in memarium-runtime. The runtime crate never depends on daemon-private peer-message types.

Status:

• done — post-chain observer, per-phase observer registration, neutral MemariumObservation, declarative rule compilation, startup extract-path validation, and explicit null preservation for missing runtime extract values are wired. MemariumContextEnricher exists as a read-only domain trait; the daemon keeps it disabled by default until an operator config explicitly attaches enrichment behavior.

Declarative Observe Rules

Based on:

• doc/project/40-proposals/036-memarium.md

Responsibilities:

• define an ObserveRule contract specifying: message types, fact kind, target space, field extraction paths, optional condition predicate, enabled flag,
• compile observe rules from the memarium section of each middleware's configuration, merged through the daemon's standard deep_merge(factory_config, node_config) strategy,
• validate rules at startup: reject unknown space ids, validate extract path syntax, warn on unreachable rules,
• support operator overrides: node config can disable, modify, or add observe rules for any middleware.

Each middleware is the semantic expert for its own domain. Agora declares that agora-record.v1 messages are agora-submission facts in the public space. Dator declares that service-offer.v1 messages are offer-tracking facts. Memarium compiles and executes these rules without domain-specific knowledge.

Implementation note: rule compilation validates extract path syntax at startup, and space ids are validated structurally via enum deserialization before a rule can be executed. A missing extract path is preserved as an explicit JSON null in the recorded fact, so consumers can distinguish "field absent from the source" from "rule did not ask for this field."

Status:

• done — ObserveRule contract, config merge, startup validation, runtime matching, effective-payload extraction, explicit-null preservation, and operator override points are implemented.

Host Capabilities

Based on:

• doc/normative/50-constitutional-ops/AUTONOMY-LEVELS.md (memarium.read, memarium.index at A1/A2)
• doc/project/40-proposals/036-memarium.md

Related capabilities:

• memarium.read
• memarium.write
• memarium.index
• memarium.cache
• memarium.promote
• memarium.forget
• memarium.declassify
• memarium.quarantine (passport grant used by quarantine operations on the memarium.declassify endpoint)
• memarium.crisis_status
• memarium.crisis_resolve

Responsibilities:

• expose memarium.read (A1+): query entries by id, tag, artifact kind, within a space,
• expose memarium.write (A1+): append new entries subject to space policy validation,
• expose memarium.index (A2+): query index projections for entry counts, tag distributions, recent activity,
• expose memarium.cache (A1+): read-through cache with index lookup fallback to full scan,
• expose memarium.promote (A0): cross-space promotion requiring operator approval,
• expose memarium.forget (A0): right-to-forget requests subject to explicit operator approval and space forget policy,
• expose memarium.declassify (A0): append-only policy facts lowering a fact by one classification tier for a bound surface/topic/mode,
• expose quarantine list/accept/reject as A0 operations authorized by their own space-scoped memarium/quarantine grant rather than by synthetic declassification parameters,
• expose memarium.crisis_status (A1): operator-visible crisis seed and active finding view,
• expose memarium.crisis_resolve (A0): append-only operator force-resolution fact for a named detector,
• register capabilities through the daemon's host capability binding mechanism,
• serve in-process callers (agents, NSE hooks) through direct trait methods and out-of-process callers (middleware modules) through the host capability HTTP surface.

The nine endpoint capabilities are exposed as POST /v1/host/capabilities/memarium.<op> endpoints and run through the same passport-gated dispatch as Sealer (capability-binding::authorize, six-step pipeline). Quarantine is an operation family under the existing memarium.declassify endpoint but has its own memarium/quarantine grant. Revocation is integrated against local, static-file, Seed Directory, and delegation-target-id sources. The operator-vocabulary target tag is memarium:space:<space>[:community:<id>][:kind:<kind>][:entry:<id>]; crisis status and resolve use the crisis space target. memarium.declassify uses a separate memarium-declassify@v1 profile because authorization binds additional axes: surface, topic class, declassification mode, source tier, and target tier.

Why the Passport Gate Is Architectural

Memarium is a constitutional memory organ rather than a CRUD service. Code running inside the daemon therefore receives no ambient authority over memory. A signed passport externalizes the decision and binds the caller, capability, target, scope, validity window, and revocation handle at the admission boundary. This prevents the daemon from becoming a confused deputy merely because a module shares its process.

The gate also keeps A0 operator authority, A1 module authority, and A2 delegated nym authority structurally distinct. Delegation can be narrow, time-bounded, and revoked without copying credentials or teaching every domain engine how to recognize every caller class. The dispatch gate verifies authority; the Memarium engine executes an already-authorized operation and remains independent of deployment-specific identity mechanics.

The same boundary makes audit causal rather than forensic. A refusal, its stable status, correlation id, caller binding, grant, target, and audit decision are produced from one decision point instead of reconstructed later from unrelated logs. This is especially important for Crisis: a detector may report a condition, but only explicit operator authority may force memarium.crisis_resolve.

Removing the passport gate would therefore require either ambient in-process trust or duplicated authorization inside Memarium and every future constitutional organ. Both would break the intended stratification; the passport is the portable data contract that keeps authorization at the edge and execution in the engine.

Built-In Module Passport Bootstrap

Built-in modules MAY ship publisher-signed templates describing the Memarium capabilities they normally need, for example memarium.write to a bounded community space. Such a template is not a Memarium write passport. It is only a signed recommendation that local policy may use when installing or enabling the module.

The daemon authorizes Memarium host-capability calls from one of these authority sources:

1. a local executable passport installed by the operator or local deployment policy,
2. an executable passport fetched from an operator-configured trusted source, such as an organization policy server or community governance issuer,
3. a local passport auto-issued from a publisher template when local policy explicitly enables auto-issuance for that built-in module.

Local deny or local disable always wins. A local executable passport also shadows the publisher template, so updating local authority does not require changing the packaged software. If no executable passport can be resolved, passport_lookup_failed remains the correct denial status; an operator UI MAY surface the matching publisher template as an installation recommendation, but the dispatch gate still denies the request.

A module MUST NOT bootstrap Memarium write authority by fetching its own passport from an arbitrary network endpoint. External passports are valid only when the source and issuer are named by local policy for the exact capability and scope.

Operational issuance and activation steps are documented in doc/ops/memarium-passport-issuance.md.

Host API Wire Contract

The host API keeps the endpoint + op shape. Each request is sent to one of the nine memarium.* endpoints and carries an op field identifying the operation inside that capability. Successful responses carry status: "ok"; error responses carry a stable status: string, a free-form human reason, and may carry structured details. Clients should parse status programmatically and must not parse reason.

For HTTP target-bearing operations, community_id is required when space == "community", even though the local runtime storage shape does not need it. The daemon needs it to build the authorization target. entry_kind is required for memarium.write / write_entry through the mandatory artifact_kind field, and optional elsewhere; when present, it participates in profile matching. attributes are an open-world map<string,string> with bounded key count, key size, and value size. fields are an open-world JSON object with bounded key count, key size, encoded size, and depth. Runtime domain types and HTTP wire schemas remain separate contracts.

Entries and facts carry a first-class classification: classification.v1 label. The label is not encoded in attributes or fields. During the migration window, write requests that omit classification are accepted and stamped as Personal with ingress quarantine; once producers have been refactored, the contract should move to strict-required labels. The MVP migration gate is: no earlier than 2026-06-30, and only after fallback_stamped_facts_per_space_per_day == 0 for seven consecutive days. The daemon exposes this migration policy through:

[memarium.classification]
mode = "legacy-stamp-then-warn"
strict_not_before = "2026-06-30"
strict_after_zero_fallback_days = 7

The fallback counter is exported in runtime metrics under memarium_fallback_stamped_facts_per_space_per_day keyed by YYYY-MM-DD:<space>. When mode = "strict-required", the daemon now enforces this gate rather than only documenting it: unlabeled writes are rejected only after the configured date has passed and the configured consecutive-day zero-fallback window has been observed. Passport authorization runs before fallback stamping, and the counter is reconstructed from accepted, durable quarantine markers after restart. An unauthorized request therefore cannot postpone the strict-mode ratchet. All HTTP wire timestamp fields are RFC3339 strings; Rust SystemTime's serde object shape is an implementation detail and is not part of the Memarium host-capability contract.

Declassification never mutates the source fact. memarium.declassify appends a classification-declassified policy fact containing a DeclassifyFact. Context-free read/query paths compose the complete trail but retain source_tier as the conservative effective_tier; only a concrete egress adapter may derive a lower tier for its exact surface/topic/time under a current revocation view. A missing anchor or revocation view makes the exception inert. One-shot use appends classification-declassify-consumed before the effect, and read projections fold that policy fact into mode.consumed_at without mutating the original trail. Operator quarantine actions likewise write append-only policy facts (classification-quarantine-accepted / classification-quarantine-rejected), preserving the original ingress record. Accepted quarantine facts clear the read/query quarantine marker for the target entry or fact; rejected decisions remain append-only audit evidence. Decisions validate target existence, pending state, and terminal-decision idempotency. TransformationFact is evidence/provenance only in v1: it may be referenced from DeclassifyFact.evidence_ref, but every effective-tier lowering still requires an explicit, active DeclassifyFact. The host API schema is published as memarium-host-api.v1.schema.json with examples under doc/schemas/examples/*.memarium-host-api.json.

Response Status Codes

The enumeration below is closed for host-capability contract v1. Adding a new status is a minor version bump; removing or renaming a status is breaking. Codes from the dispatch gate map to exactly one audit decision string.

Status	HTTP	Audit decision	Retryable	Meaning
invalid_request	400 Bad Request	-	no	Malformed JSON, missing required field, wrong type, or enum outside the accepted range.
unsupported_op	400 Bad Request	-	no	Envelope shape is valid, but the op does not exist for this memarium.* host capability.
invalid_operator_reason	422 Unprocessable Entity	-	no	memarium.crisis_resolve reason is empty, longer than 2048 bytes, or contains unsupported control characters.
passport_lookup_failed	403 Forbidden	denied:passport-lookup-failed	no	Caller is identified, but no matching memarium-space-access passport is installed for this caller/capability target.
passport_invalid	403 Forbidden	denied:passport-invalid-signature	no	Passport structure or signature does not verify.
passport_expired	403 Forbidden	denied:passport-expired	no	Passport is outside its validity window.
binding_mismatch	403 Forbidden	denied:binding-mismatch	no	Passport does not bind to the resolved caller.
allowed_callers_mismatch	403 Forbidden	denied:allowed-callers-mismatch	no	Caller is not present in the passport's allowed caller set.
no_profile_matched	403 Forbidden	denied:no-profile-matched	no	No passport profile matches the grant and structured Memarium target.
policy_denied	403 Forbidden	denied:policy-denied	no	Issuer policy denied the request after the more specific denial classes did not apply.
revocation_stale	503 Service Unavailable	denied:revocation-stale	yes	Revocation view is outside the configured freshness budget.
revoked	410 Gone	denied:revoked	no	Passport id or delegation target id is revoked.
operator_only	403 Forbidden	denied:operator-only	no	Capability requires A0; module callers cannot invoke it directly.
classification_missing	400 Bad Request	-	no	A guarded surface requires a first-class classification label and none was supplied.
classification_mismatch	403 Forbidden	-	no	The source/effective tier is incompatible with the requested operation or destination.
declassification_required	403 Forbidden	-	no	The destination would be reachable only after a valid declassification fact, but none is active.
declassification_scope_expired	403 Forbidden	-	no	A declassification fact is invalid, expired, revoked, consumed, or not bound to the requested surface/topic/mode.
bound_subjects_not_public	400 Bad Request	-	no	Public egress carries full subject references instead of bound_subjects.public_projection.
quarantined	409 Conflict	-	no	The target is still in ingress quarantine and requires an operator accept/reject/declassify action.
source_tier_immutable	400 Bad Request	-	no	A request attempted to mutate or skip over the immutable source tier semantics.
space_policy_violation	422 Unprocessable Entity	-	no	Memarium space policy rejects the operation, e.g. plaintext write into an encryption-required space.
promotion_denied	403 Forbidden	-	no	Cross-space promotion would violate Memarium promotion rules. Details may classify specific cases such as crisis-closed promotion.
not_found	404 Not Found	-	no	Requested entry, fact, or cache key does not exist.
unknown_detector	422 Unprocessable Entity	-	no	memarium.crisis_resolve.detector is outside the detector whitelist. details.valid_detector_ids lists accepted ids.
memarium_unavailable	503 Service Unavailable	-	yes	Memarium host capability runtime is disabled or not currently available.
storage_unavailable	503 Service Unavailable	-	yes	Transient storage failure.
storage_error	500 Internal Server Error	-	no	Non-retryable storage failure.
internal_error	500 Internal Server Error	-	no	Unexpected host-side state. The response must not leak stack traces or secrets.

Authorization-level enforcement for memarium.forget is contextual in the daemon. A module caller may request personal-space forget through the normal passport gate when its passport grants memarium/forget for personal. Public forget remains operator-only at dispatch and becomes a runtime tombstone; community forget remains governed and requires an explicit governance reference before the runtime records erasure; crisis forget remains operator-only plus runtime-restricted. The next authorization hardening step is remembered operator approval: an explicit operator policy fact such as "always allow this participant or module to forget this class of personal entries"; it must carry scope, reason, issuer, audit trace, and a revocation path.

Status:

• done — all nine capabilities are live over real HTTP with passport-gated dispatch, audit sink, four revocation sources, contextual personal-space forget delegation, and governed community forget through explicit governance references. Point reads and policy read views now use a derived SQLite sidecar by default; it rebuilds from the append-only memarium:{space}:entries and memarium:{space}:facts streams, materializes memarium_entry_current, memarium_fact_current, and memarium_policy_current rows with as_of_tx_id, performs daemon startup catch-up when enabled, and keeps scan-based reads as the correctness fallback when the sidecar is disabled. The launcher now provides the minimum operator CLI over the existing host-capability contract (memarium quarantine {list,accept,reject} and memarium declassify), while richer node-ui / batch UX remains future work.

Agora Synchronization Tracking

Based on:

• doc/project/40-proposals/035-agora-topic-addressed-record-relay.md (Agora orthogonality)
• doc/project/40-proposals/036-memarium.md

Responsibilities:

• record Agora-bound submissions as MemariumFact entries in the public space, driven by observe rules declared in Agora's middleware configuration,
• record confirmation or failure as subsequent facts (sync-confirmed, sync-failed, sync-timeout) through additional observe rules,
• derive current synchronization status from the latest fact in the chain (append-only, no mutation),
• serve as the local cache of what the node contributed to Agora, queryable through memarium.read.

Agora does not depend on Memarium. Memarium does not depend on Agora. Agora declares observe rules in its config; Memarium compiles and executes them without Agora-specific knowledge.

Status:

• done — the Memarium side of the channel is implemented without depending on Agora internals: rule compilation, post-chain matching, fact append, and query are covered by tests. Agora's bundled middleware configuration publishes concrete ObserveRule entries for agora-submission, sync-confirmed, sync-failed, and sync-timeout, and the compiler → observation → append → query path protects those rules. Live relay behavior remains an Agora / Story-level operational test, not a Memarium contract blocker.

Archival Integration

Based on:

• doc/project/30-stories/story-003-remote-memory-preservation.md
• doc/project/40-proposals/012-learning-outcomes-and-archival-contracts.md
• doc/project/50-requirements/requirements-003-memory-archivists.md

Related schemas:

• archival-package.v1
• archivist-advertisement.v1
• retrieval-request.v1
• retrieval-response.v1
• learning-outcome.v1
• knowledge-artifact.v1

Responsibilities:

• accept promoted KnowledgeArtifact entries from the learning outcome pipeline,
• record archival package preparation and handoff results as facts with provenance,
• cache ArchivistAdvertisement entries from peer archivists in the community or public space,
• serve as local cache for previously retrieved archival material to avoid redundant remote retrieval.

Status:

• done — the Memarium domain layer owns a thin archival export adapter around archival-package.v1, and the daemon exposes authenticated local-operator backup plus remote handoff/retrieval control flows on top of it. POST /v1/memarium/backups prepares one staging bundle under <data_dir>/memarium/backups/, materializes per-item payload snapshots plus archival-package.v1 JSON files, and atomically promotes the directory only after the complete manifest succeeds; package ids include the backup id and ordinal. GET /v1/memarium/backups/{backup_id} rehydrates that manifest for later inspection. POST /v1/memarium/archival/handoffs preflights every package, submits each item to Artifact Delivery for INAC/archivist transport, and records append-only archival-handoff-requested, then archival-handoff-accepted or archival-handoff-failed facts with partial-submit diagnostics when AD rejects a later item. POST /v1/memarium/archival/retrievals builds and submits retrieval-request.v1 through Artifact Delivery, records archival-retrieval-requested, and records archival-retrieval-unavailable if the outbound request cannot be queued. Future retrieval-response acceptors may append found, denied, unavailable, or tombstoned facts and materialize returned entries/facts only through the ordinary Memarium write path. GET /v1/memarium/archivists reads cached archivist-advertisement facts. The adapter preserves classification, checks a fresh-enough revocation view for every declassification anchor, treats every exception as inactive when that view is stale, derives the exact export/topic projection, records one-shot consumption before bundle publication, and denies quarantined, malformed, revoked, consumed, or not-yet-declassified public-vault packages before handoff.

Caller identity is explicit at the daemon/host boundary: the authenticated control router passes AuthenticatedOperator, while the module-capability router passes Module. Absence of a module authtok is never interpreted as operator authority inside Memarium.

Crisis Space Management

Based on:

• doc/normative/40-constitution/CONSTITUTION.md (Art. V.7)
• doc/normative/20-vision/VISION.md (escape kit)
• doc/project/40-proposals/036-memarium.md
• doc/project/40-proposals/039-crisis-space-seed-v1.md (review candidate for the first constitutional seed bundle)

Responsibilities:

• enforce constitutional minimum retention for crisis entries (must not expire without explicit operator action),
• use operator-held encryption keys for crisis material (accessible without group consensus),
• maintain explicit crisis replication policy separate from general federation replication,
• pre-populate crisis procedures from a constitutional seed set on first node start,
• support updates through explicit operator or federation action only.

Status:

• done — the crisis space enforces its policies like the other three spaces, and the daemon now applies the reviewed constitutional seed synchronously during startup after storage and the Node AEAD key are ready. Proposal 039 deliberately defines v1 as an unsigned compiled bundle: trust comes from the reviewed Node binary, while the pinned digest detects same-version drift; detached signature verification is reserved for a future file-loaded seed. Autonomous detector facts, memarium.crisis_status, and memarium.crisis_resolve provide the first operator-facing crisis management loop.

May Implement

Context Enrichment (PreInput)

Based on:

• doc/project/40-proposals/036-memarium.md

Responsibilities:

• implement PeerMessageHandler on the PreInput chain to annotate inbound messages with cached knowledge artifacts relevant to the message type or topic,
• return Passthrough or Annotate (enrich context without modifying payload),
• never block or drop.

This handler may be deferred until agent integration patterns stabilize.

Status:

• optional

Federated Replication

Responsibilities:

• replicate community space entries among trusted federation peers,
• replicate public space entries through peer-to-peer replication as an alternative to Agora,
• enforce space policy on replication scope (personal never leaves node without explicit export),
• track replication status as facts.

This is future work after the local organ is stable.

Status:

• future

Payload Envelope Contract

Memarium entries carry a PayloadEnvelope with a discriminated PayloadEncoding:

• PlaintextJson — caller-supplied JSON body, admissible only in spaces whose EncryptionPolicy allows plaintext (public space, operator-opt-in elsewhere),
• SealedJsonV1 / SealedBytesV1 — an EncryptionEnvelope { sealed_by, key_ref, suite, ciphertext, nonce, aad_digest } produced by an upstream AEAD component (typically Sealer),

Memarium does not perform AEAD itself. Its responsibility at write time is to validate that the envelope matches the space's EncryptionPolicy (reject plaintext into a required space), record the envelope verbatim, and re-emit it on read. Every space whose policy requires encryption therefore depends on a caller that already speaks the sealed envelope — the dispatch-gate pattern in the daemon is the integration point.

Consumes

• learning-outcome.v1
• knowledge-artifact.v1
• archivist-advertisement.v1
• retrieval-response.v1
• Post-chain observations (effective payloads after middleware mutations)
• Declarative observe rules from middleware configuration sections
• PayloadEnvelope values produced by Sealer or other AEAD-speaking callers

Produces

• MemariumEntry (internal domain type, not a wire schema)
• MemariumFact (internal domain type, not a wire schema)
• Host capability responses for memarium.read, memarium.write, memarium.index, memarium.cache, memarium.promote, memarium.forget, memarium.declassify, memarium.crisis_status, memarium.crisis_resolve

Related Capability Data

Structured solution capability catalog:

• memarium-caps.edn

• memarium.read — read entries within a space (A1+)

• memarium.write — append entries to a space (A1+)
• memarium.index — query index projections (A2+)
• memarium.cache — read-through cache (A1+)
• memarium.promote — cross-space promotion (A0)
• memarium.forget — right-to-forget request (personal-space module delegation through passport gate; other spaces operator/governed/restricted, then constrained by space policy)
• memarium.declassify — append-only declassification/quarantine policy facts (A0)
• memarium.crisis_status — crisis seed and active finding view (A1)
• memarium.crisis_resolve — append-only operator force-resolution (A0)

Crate Boundary

memarium crate

Defines the trait boundary and domain types:

• MemariumSpace, SpaceId, policy types (encryption, retention, replication, forget)
• MemariumEntry, EntryId, ArtifactKind
• MemariumFact, FactId, FactKind
• ObserveRule, ObserveRuleSet — declarative fact-recording rule contract
• MemariumRead trait (query entries, facts, index)
• MemariumWrite trait (append entries, record facts)
• MemariumIndex trait (query projections)
• MemariumError error model
• Host capability request/response types

Does not depend on storage backend crates.

memarium-runtime crate

Implements:

• MemariumRead, MemariumWrite, MemariumIndex over StorageRuntime
• Space-to-stream mapping and policy enforcement
• MemariumRuntime::observe_dispatch(...) — neutral post-chain observation port driven by compiled observe rules
• ObserveRuleCompiler — compiles observe rules from merged middleware config
• MemariumReadProjection — narrow hook for derived read models
• optional MemariumContextEnricher semantics over Memarium-domain input; daemon-side chain adapters remain outside this crate
• Index projection from commit log

Depends on: memarium, storage, storage-runtime. It does not depend on the daemon crate or daemon-private peer-message chain traits.

memarium-read-sidecar crate

Implements a Solution 028-style derived SQLite read projection:

• source of truth: memarium:{space}:entries and memarium:{space}:facts
• technical replay bookkeeping: memarium_projection_tx and stream checkpoints
• current projections: memarium_entry_current, memarium_fact_current, memarium_policy_current
• replay-equivalence tests against the scan fallback, including forget, declassification, quarantine, rebuild, and privacy checks
• operator storage diagnostics: /v1/operator/storage/profiles reports the sidecar as a non-temporal read model with row counts and stream checkpoints

It implements the runtime-side MemariumReadProjection hook. The sidecar is rebuildable from append-only storage and is not a semantic event log. Its single SQLite connection remains a correctness-first MVP implementation; batching fact-policy lookups or introducing a read pool is a measured performance follow-up, not a semantic contract change.

daemon integration layer

Implements:

• MemariumPostChainAdapter implementing the daemon-private PostChainObserver trait
• mapping from PostChainEvent to MemariumRuntime::observe_dispatch(message_kind, correlation_id, effective_payload)
• Memarium runtime construction from effective daemon/middleware config

Depends on: memarium, memarium-runtime, storage-runtime, and daemon-private peer-message chain types.

Notes

Memarium is a constitutional organ at layer L2 in the system stratification (L0: Node, L1: Agent, L2: Memarium, L3: Swarm Protocol). Its implementation as an in-process crate reflects the constitutional requirement for co-lifecycle with the daemon and the operational requirement for low-latency agent access.

The chain integration follows the observer slot pattern (proposal 027): the daemon registers a Memarium post-chain adapter that sees effective payloads after all middleware mutations, not a dispatch handler. Fact recording is driven by declarative observe rules declared by each middleware in its own configuration, merged through the daemon's standard deep-merge strategy. This eliminates coupling between the memory organ and the semantic modules it observes.

The runtime-side expansion point is now the Memarium-domain MemariumObservation value. observe_dispatch(message_kind, correlation_id, effective_payload) remains as a compatibility wrapper for post-chain callers. PostChainObserver, PhaseObserver, and their event types remain daemon adapter concepts, not runtime dependencies.

Implementation-specific decomposition, file ownership, and delivery status belong in the concrete Node repository's implementation ledger.