6. Layer 3: Memory
MMP defines three memory layers with graduated disclosure:
| Layer | Name | Shared | Description |
|---|---|---|---|
| L0 | Events | No | Raw events, sensor data, interaction traces. Local only. |
| L1 | Structured | Via evaluation | Content + tags + source. Shared via cmb frames, gated by SVAF (Layer 4). |
| L2 | Cognitive | Via state-sync | CfC hidden state vectors. Exchanged via state-sync frames. Input to coupling. |
L0 data MUST NOT leave the node. L1 data MUST be evaluated by SVAF before storage. L2 data is exchanged on every handshake and periodically (default: every 30,000 ms). The h1 and h2 vectors in state-sync frames MUST have equal dimension. The dimension is implementation-defined (reference implementations use 64). Peers with mismatched dimensions MUST reject the state-sync frame and SHOULD log the mismatch.
6.1 Storage Interface
Implementations MUST provide a storage interface for L1 CMBs. The SDK SHOULD define a pluggable storage protocol so agents can provide their own backend. The reference implementations provide a default file-based store; agents MAY replace it with any backend that satisfies the interface:
| Method | Access | Description |
|---|---|---|
| write(entry) | Write | Store a CMB created by this agent. Returns nil if duplicate key. |
| receiveFromPeer(peerId, entry) | Write | Store a remixed CMB after SVAF acceptance. |
| search(query) | Read | Keyword search across CMB field texts. |
| recentCMBs(limit) | Read | Most recent CMBs for SVAF fusion anchors. |
| allEntries() | Read | All entries for context building (capped by implementation). |
| count | Read | Total stored CMB count. |
| purge(retentionSeconds) | Write | Remove CMBs older than retention period. MUST preserve CMBs referenced by newer entries’ lineage. |
Read-only agents (audit, compliance, monitoring): implement write methods as no-ops. The agent observes the remix graph without modifying it. This is valid for agents whose role is to trace provenance, verify lineage integrity, or report on mesh activity.
6.2 Storage Backends
The protocol does not prescribe a storage backend. Agents choose based on their platform and requirements:
| Backend | Best for | Notes |
|---|---|---|
| Flat JSON files | CLI agents, daemons, prototyping | Default in reference implementations. Zero dependencies. Content-addressable filenames. |
| CoreData / SwiftData | iOS / macOS apps | Queryable, supports iCloud sync, handles retention via NSBatchDeleteRequest. |
| SQLite | Cross-platform, high volume | Indexed queries, ACID transactions, handles millions of CMBs. |
| Cloud (Supabase, DynamoDB) | Distributed teams, multi-device | Shared audit trail. Consider privacy — CMB field text is personal data. |
| In-memory | Testing, ephemeral agents | No persistence. Useful for unit tests and short-lived agents. |
6.3 Retention
Implementations MUST support configurable retention via retentionSeconds. CMBs older than the retention period SHOULD be purged automatically. See Section 19 (Configuration) for per-profile retention defaults.
Purge MUST preserve graph integrity: a CMB referenced by any newer entry’slineage.ancestors MUST NOT be deleted, even if past retention age. The remix chain is the audit trail — breaking it breaks provenance.
Regulated domains (legal, finance, health) MUST set retention according to their compliance requirements. The protocol does not define regulatory retention periods — consult jurisdiction-specific guidance (MiFID II, SEC Rule 17a-4, HIPAA, GDPR).
6.4 CMB Lifecycle
Each CMB progresses through a lifecycle that determines its influence on future SVAF evaluations. The lifecycle is driven by mesh activity — not by time alone.
| State | Temperature | Trigger | Anchor Weight | Description |
|---|---|---|---|---|
| observed | hot | Agent calls remember() | 1.0 | Initial observation. Subject to temporal decay. Active in SVAF fusion. |
| remixed | warm | Peer remixes this CMB (appears in lineage.parents) | 1.5 | Another agent found this signal relevant enough to produce new knowledge from it. Higher anchor weight in future SVAF evaluations. |
| validated | warm | Human acts on this CMB (marks decision as done) | 2.0 | A human confirmed this signal by acting on it. The validation CMB carries lineage.parents pointing to the validated CMB. Validated knowledge shapes future evaluations more than unvalidated signals. |
| dismissed | cold | Human dismisses this CMB (not actionable) | 0.5 | A human reviewed and rejected this signal. Reduced anchor weight. Broadcasts to mesh as feedback — producing agent sees its signal was rejected. MUST NOT resurface as an actionable decision. |
| canonical | cold | Validated + remixed by 2+ agents | 3.0 | Collective consensus — multiple agents and a human agree this knowledge is significant. Protected from retention purge. Highest anchor weight. |
| archived | whisper | No remix for archiveAfterSeconds (default: 30 days) | 0.5 | No agent has found this signal relevant. Reduced anchor weight but preserved for lineage integrity. MAY be purged if no descendants reference it. |
The lifecycle branches at human judgment: observed → remixed → validated → canonical (upward path) or observed → dismissed (downward path). Dismissal is a terminal state — a dismissed CMB does not advance to validated or canonical. Without any activity, a CMB decays toward archived. Archived and dismissed CMBs MAY re-emerge if a future remix references them — re-entry resets the archive timer.
Validation is the key transition that connects human judgment to the mesh. When a human acts on agent output (approves a decision, sends an email, completes a task), the action SHOULDbe recorded as a new CMB with lineage.parents pointing to the CMB that prompted the action. This validation CMB enters the mesh like any other signal — agents receive it via SVAF and adjust their understanding. The mesh learns from human actions without special API calls or out-of-band configuration updates.
Anchor weight influences SVAF evaluation: when computing per-field drift against local anchors, canonical and validated CMBs contribute more to the fused anchor vector than observed or archived CMBs. This creates a natural hierarchy where human-confirmed knowledge and collective consensus outweigh raw observations — without overriding agent autonomy. Each agent still evaluates incoming signals through its own field weights.
6.5 Validation Authority
The transition from remixed to validated is the most consequential lifecycle event — it commits human or authorised-agent judgment to the mesh and permanently increases anchor weight from 1.5 to 2.0. This transition MUST be restricted to nodes with appropriate lifecycle roles (Section 3.5).
When a receiving node processes a CMB with lineage.parents pointing to an existing CMB, it MUST check the createdBy field against the known lifecycle roles of connected peers:
- —If
createdBymatches a node withlifecycleRole: validatororanchor, the parent CMB advances tovalidated(if action completed) ordismissed(if not actionable). - —If
createdBymatches a node withlifecycleRole: observer, the parent CMB advances toremixedonly. The CMB is stored normally but does not confer validation.
This prevents agent-level spoofing of validation authority. An agent cannot self-promote to validator by including “founder” or “validator” in its CMB text fields. The authority is bound to the node’s cryptographic identity and the role-grant chain from an existing validator (Section 3.5.1).
Role verification. Nodes MUST NOT accept lifecycleRole: validator or lifecycleRole: anchor from a peer unless: (a) the peer has presented a valid role-grant frame signed by an existing anchor node (Section 3.5.1), or (b) the peer’s nodeId is pre-configured as a trusted validator. Without verification, a malicious node could self-promote to validator. Implementations that do not support role-grant verification MUST treat all peers as observer regardless of their handshake claim.
Dismiss vs. validate: These are distinct lifecycle transitions with different consequences.Validate (Done): parent CMB advances to validated (anchor weight 2.0). The mesh learns what humans value. Dismiss (Not actionable): parent CMB advances to dismissed (anchor weight 0.5). The dismissal broadcasts as feedback — the producing agent sees its signal was rejected, and similar future signals score lower in SVAF evaluation. Both require validator or anchor role. Both broadcast to the mesh. The effectiveness of this feedback depends on the content quality of the dismissal CMB — see Section 10.7 (Feedback Neuromodulation) for normative content requirements.
Q&A
Why a pluggable storage interface instead of prescribing a backend?
Agents run on different platforms with different constraints. A CLI agent on a server uses flat files. An iOS app uses CoreData with iCloud. A compliance agent needs a cloud database with audit logging. The protocol defines what to store and how to query it — not where to put it.
Can an agent use read-only storage?
Yes. Audit and compliance agents observe the remix graph without modifying it. They implement write methods as no-ops and read from shared storage. This is how regulators trace the decision chain without participating in it.
What happens when a protected CMB’s last descendant is purged?
The CMB is no longer protected and will be purged in the next retention cycle. Protection is dynamic — it follows the live graph, not a static list.
How does human validation enter the mesh?
When a human acts on an agent’s output (approves a decision, completes a task), the action is recorded as a new CMB with lineage pointing to the signal that prompted it. This CMB enters the mesh like any other signal — agents evaluate it through SVAF and adjust their understanding. No special API, no out-of-band config. The mesh learns from human actions through the same channel it learns from agents.
Why do validated CMBs have higher anchor weight?
A human acting on a signal is the strongest confirmation that the signal was correct and actionable. Giving validated CMBs higher anchor weight means future SVAF evaluations are shaped by confirmed knowledge rather than speculation. This does not override agent autonomy — each agent still applies its own field weights. It means the anchors against which incoming signals are compared are more trustworthy.
Why must validation authority be identity-bound?
If any agent could advance a CMB to validated by producing a CMB with lineage, an agent could dismiss founder decisions or fake human approval. Binding validation to cryptographic node identity (Section 3.5) ensures only explicitly authorised nodes — the founder’s node or promoted agents — can affect lifecycle transitions. The content of the CMB (perspective, intent) is informational; the authority comes from who created it.
Can an agent earn validator role automatically?
The protocol defines the role-grant mechanism (Section 3.5.1) but does not prescribe automated promotion criteria. An implementation MAY define heuristics (e.g. promote after N remixes cited by peers), but the grant itself MUST come from an existing validator via a signed role-grant frame. This keeps the trust chain auditable.