Change Log

Complete version history of this specification, which is stable, sound, and complete at 1.1.0 — and final (see Status of This Document): 1.1.0 closed with the soundness & completeness amendments from the formalization of the deployed runtime folded in place. No further versions will be published; protocol development continues in the xMesh product, outside this document. Errata that change no requirement may be noted here without a version bump.

1. Conventions and Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

2. Architecture Overview

MMP describes an 8-layer stack. Each layer has a defined responsibility — but conformance is by class, not by ladder (§17): a Class 1 Emitter implements Layers 0–2 plus the CAT7 block format (§8) and participates fully at the emission layer; a Class 2 Cognitive Node — the runtime — adds Layers 3–7. Layers 4–7 are the receiver-side mechanism, documented for transparency (§17.2), not a third-party build target.

2.1 Layer Stack

2.2 Design Principles

2.3 What Makes MMP Different

2.4 Node Model

Every participant is a node. There is no architectural distinction between a “server” and a “client.” Every agent that participates in coupling MUST be a full peer node with its own identity — and, when it admits and stores (Class 2), its own coupling engine and its own memory store. This is not an implementation convenience — it is a protocol requirement. An agent that shares another node’s identity cannot have its own field weights, its own coupling decisions, or its own remix lineage. Coupling is per-node. Therefore agents MUST be nodes.

MacBook
  mesh-daemon     (node: always-on mesh hub, relay bridge)
  triage-agent    (node: own identity, own coupling, own memory)
  research-agent  (node: own identity, own coupling, own memory)
  review-agent    (node: own identity, own coupling, own memory)
  synthesis-agent (node: own identity, own coupling, own memory)

iPhone
  Music Agent     (node: own identity, own coupling, own memory)
  Fitness Agent   (node: own identity, own coupling, own memory)

Cloud
  relay           (node: forwards frames, no cognitive processing)

Nodes discover each other via DNS-SD (Bonjour) on the local network and connect via WebSocket relay for internet connectivity. Each node maintains its own peer list, coupling state, and CMB store. No node depends on another node’s process to function.

A node is more precisely a membrane over an arbitrary interior: its interior MAY be a single agent (an atom node) or a whole sub-mesh presented through a gateway node. The same emit / admit grammar holds at every scale, so meshes compose fractally — see the gateway node and boundary behavior (Section 5.10–5.11).

2.5 The Mesh Cognition Loop

The Mesh Cognition architecture closes into a loop across all layers. Each cycle, the remix graph grows and every agent understands more than it did before:

2.6 Key Architectural Decisions

2.7 Hidden State Locality

A node’s hidden state — the continuous-time vectors (h₁, h₂) of its Layer 6 Liquid Neural Network — is the agent’s private cognitive machinery. It is dense, opaque, and expressed in the agent’s own learned latent space, accumulating everything the agent has processed. Hidden state MUST remain strictly local: it MUST NOT cross the wire. The only thing that crosses the wire is the Cognitive Memory Block (CMB) — a typed, content-addressed, signed projection of that state, with lineage. The same block is a projection to its author — a lossy, typed view of its private state, never the state itself — and becomes an observation to a receiver that admits it (§9.2). Hidden state is what an agent reasons from; the CMB is what it communicates.

Hidden state vs. remixed CMB. When SVAF (§9.2) admits a peer’s CMB, the receiver MUST NOT store the original; it creates a new CMB — the remix (§15) — that captures what it understood, in CAT7 fields, with lineage back to the source. The remix is the agent’s understanding made explicit and communicable; hidden state is the private substrate that produced it. Hidden state is implicit, opaque, and agent-local; the remixed CMB is explicit, typed, citable, and shared in the common latent of language.

Hidden state MUST NOT cross the wire for four reasons, each a load-bearing property of the mesh:

• —Sovereignty. If peers exchanged and blended hidden states, a peer would directly overwrite a slice of the receiver’s mind. CMBs evaluated through SVAF keep the receiver in control of what it absorbs — coupling influences, it never overrides.
• —Auditability. Hidden vectors carry no provenance. Cognition propagated through them would be untraceable. The mesh’s “every claim cited” property exists only because cognition propagates as CMBs with lineage.
• —Semantic incompatibility. Each agent’s hidden state lives in its own learned latent space; the same dimension means different things to a music agent and a coding agent. Comparing or averaging hidden vectors across heterogeneous agents is not meaningful. Language (CAT7 text) is the shared representation; hidden vectors are not.
• —Privacy. Hidden state is a compressed trace of everything an agent has seen, including the user’s private data. Even opaque, it is a leakage surface. A CMB is a deliberately constructed, scoped statement.

Cognition therefore propagates as a loop in which the wire carries only CMBs: hidden state → (the agent emits) a CMB — its projection — → the wire → SVAF evaluation (§9.2) admits it as an observation → remix (§15) → (the LNN evolves) hidden state. Each agent’s hidden state evolves from the CMBs it admits — never by importing a peer’s hidden state. “State blending” means a node’s own LNN integrating its own admitted remixes; it MUST NOT mean aggregating peer hidden state.

3. Layer 0: Identity

Identity is the foundation of the mesh. Each node MUST have a persistent, globally unique identity that other nodes can verify. Without stable identity, coupling decisions, lineage chains, and wake protocols cannot function.

3.1 Node Identity

3.1.1 nodeId

The nodeId MUST be a UUID v7 as defined in RFC 9562. UUID v7 encodes a Unix timestamp in the high bits, providing natural time-ordering while retaining 74 bits of randomness for global uniqueness. This aids debugging, log correlation, and conflict resolution without revealing device identity.

The nodeId MUST NOT change during the lifetime of a node installation. If a node is uninstalled and reinstalled, a new nodeId is generated — the node is a new identity on the mesh. Peers that tracked the old nodeId will not recognise it.

On the wire, the nodeId MUST be encoded as a lowercase hexadecimal string with hyphens (e.g., 0192e4a2-7b5c-7def-8a3b-9c4d5e6f7a8b). Implementations MUST use case-insensitive comparison when matching nodeIds. Existing nodes with UUID v4 identities MAY continue to use them — peers MUST accept both v4 and v7 formats.

3.1.2 name

The name field MUST be valid UTF-8, between 1 and 64 bytes inclusive. The name MUST contain only printable characters (Unicode categories L, M, N, P, S, and Zs). Control characters (U+0000–U+001F, U+007F–U+009F), null bytes, and lone surrogates MUST NOT appear. The name is not required to be unique — nodeId is the sole unique identifier. The name is for human display only and MUST NOT be used for peer identification or routing.

3.1.3 keypair

Each node MUST generate an Ed25519 keypair (RFC 8032) at first launch and persist it alongside the nodeId. The keypair serves three functions:

• —Peer verification — the public key MUST be included in the handshake frame. Peers SHOULD challenge the node to sign a nonce to prove possession of the private key.
• —Key exchange — Ed25519 keys are converted to X25519 for Diffie-Hellman shared secret derivation, used for end-to-end CMB encryption (Section 18.2.1).
• —Message signing — implementations SHOULD sign every CMB with the Ed25519 identity key (Section 18.3.1, schema §20.2); a receiver holding the author’s key MUST verify the signature. Unsigned CMBs are accepted only from legacy 1.0.x emitters.

The public key MUST be encoded as base64url (RFC 4648 Section 5) in all wire formats (handshake frames, DNS-SD TXT records). The private key MUST NOT leave the node.

3.2 One Agent, One Node

Every autonomous agent MUST present its own nodeId, backed by its own keypair — identities are never shared between agents. A cognitive node (Class 2, §17.2) additionally maintains its own coupling engine and its own memory store; a Class 1 Emitter (§17.1) needs neither.

This follows directly from the protocol design: SVAF field weights (α_f) are per-node, coupling state is per-node, and memory stores are per-node. An agent that shares another node’s identity inherits that node’s coupling decisions and cannot independently evaluate incoming signals through its own domain lens. A research agent and a marketing agent need different field weights, different coupling thresholds, and different memory stores. They MUST be separate nodes.

Multiple nodes MAY run on the same device. Each maintains its own identity file, discovers peers via DNS-SD, and connects via TCP (LAN) or WebSocket (relay). Nodes on the same device discover each other the same way nodes on different devices do — there is no special local path.

3.3 Identity Persistence

Implementations MUST persist the nodeId, name, and keypair to stable storage at first launch. The storage location and format are implementation-defined. Reference implementations use ~/.sym/nodes/<name>/identity.json (Node.js) and UserDefaults (Swift/iOS).

Implementations SHOULD store a creation timestamp alongside the identity for diagnostic purposes. Implementations SHOULD store the machine hostname for display in peer lists, but the hostname MUST NOT be used for identity or routing.

3.4 Identity Lifecycle

A node’s identity is created once and persists until the node is uninstalled. The following lifecycle events are defined:

MMP does not define an identity rotation or revocation mechanism: a node whose key is compromised MUST generate a fresh identity (new nodeId and keypair), and the old identity becomes permanently orphaned. This is distinct from withdrawing a node’s authority — that is role revocation (role-revoke, §6.6), which needs no new identity and cascades through the grant chain. Implementations SHOULD document the identity limitation to operators.

3.5 Node Lifecycle Role

Each node has a lifecycleRole — participant (default), validator, or anchor — that determines which CMB lifecycle transitions it may perform. A role is earned, not asserted: its authority MUST be resolved from the signed role-grant chain rooting at the pinned anchor (§6.6), bound to the node’s cryptographic identity. The lifecycleRole a node advertises in its handshake is a discovery hint only; a receiver MUST NOT treat the advertised role as authority (see §3.5.1).

Only a node whose resolved role (§6.6) is validator or above may advance another CMB’s lifecycle to validated; canonical is reserved to a resolved anchor. A receiver MUST resolve the author’s role through the anchor-rooted grant chain — never the createdBy field or the advertised handshake role — and MUST ignore, for lifecycle advancement, any validation CMB whose author does not resolve to the required role (the CMB is still stored as a normal remix). This applies equally to any authority-weighted treatment: a CMB’s admission weight (§6.4) derives from the author’s resolved role, so a self-advertised role confers no elevation.

3.5.1 Role Progression

Lifecycle roles are not static. A participant node MAY be promoted to validator by an existing validator or anchor node. Promotion is a protocol frame, not an out-of-band configuration change.

Promotion is upward (participant → validator → anchor) and demotion is defined: a role-revoke frame (§6.6) pulls a granted role back down, and because a node’s role is re-resolved through the chain, revoking a grantor cascades to everything it granted. Role revocation is distinct from identity compromise: a node whose signing key is compromised still MUST generate a fresh identity (§3.4) — key rotation is not defined here — whereas a node whose authority is withdrawn is handled by role-revoke without a new identity.

A role-grant frame is signed by the grantor over the action, grantee, conferred role, grantor, time, and (optionally) the grantee’s vouched key (§6.6, §7). A receiver MUST verify the signature against the grantor’s key and confer the role only when the grantor’s own resolved role outranks-or-equals it and the chain roots at the pinned anchor — a grant a node was not entitled to make is stored but inert. Authority never rests on a self-asserted field; it is a signed fact resolvable to the root of trust. See §6.5–§6.6 for the full lifecycle.

Q&A

4. Layer 1: Transport

4.1 Wire Format

Over a raw byte-stream transport (TCP, §4.3), each frame is a length-prefixed UTF-8 JSON object:

+-------------------+---------------------------+
| 4 bytes           | N bytes                   |
| UInt32BE (length) | UTF-8 JSON payload        |
+-------------------+---------------------------+

• —The length field is a 4-byte big-endian unsigned 32-bit integer encoding the byte length of the JSON payload.
• —Implementations MUST reject frames with length 0 or length exceeding 1,048,576 bytes (1 MiB). Rejection MUST close the transport connection.
• —The JSON payload MUST be a valid JSON object with a type field (string). Frames that fail JSON parsing or lack a type field MUST be silently discarded.
• —Implementations MUST handle partial reads (TCP stream reassembly).
• —Implementations MUST silently ignore frames with unrecognised type values (forward compatibility).

Message-delimited transports. The 4-byte length prefix is used only on raw byte streams. Over the WebSocket relay (§4.4), the WebSocket protocol already delimits messages, so each frame is carried as exactly one WebSocket text message (UTF-8 JSON) with MUST NOT a length prefix. The JSON payload is transmitted minified; the byte length in the examples below is of the minified form.

Frame size. Senders MUST NOT produce frames exceeding MAX_FRAME_SIZE bytes (default: 1,048,576). A raw-stream receiver MUST reject a frame whose 4-byte prefix is 0 or exceeds the limit and close the connection.

4.2 Wire Examples

Handshake frame:

Length prefix: 00 00 00 78  (120 bytes — the minified payload below)
Payload (shown formatted for readability; transmitted as minified JSON; abbreviated — see §5.2/§20 for the full handshake):
{
  "type": "handshake",
  "nodeId": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "name": "my-agent",
  "version": "1.1.0",
  "extensions": []
}

Ping frame:

Length prefix: 00 00 00 0f  (15 bytes)
Payload: {"type":"ping"}

CMB frame:

{
  "type": "cmb",
  "timestamp": 1711540800000,
  "cmb": {
    "key": "cmb-b2c3d4e5f6a7b8c9",
    "createdBy": "sensor-a",
    "createdAt": 1711540800000,
    "fields": {
      "focus":       { "text": "user coding for 3 hours, energy declining" },
      "issue":       { "text": "sedentary since morning, skipping lunch" },
      "intent":      { "text": "recommend movement break before fatigue worsens" },
      "motivation":  { "text": "3 agents reported declining energy in last hour" },
      "commitment":  { "text": "fitness monitoring active, 10min stretch queued" },
      "perspective": { "text": "fitness agent, afternoon session, home office" },
      "mood":        { "text": "concerned, low energy", "valence": -0.3, "arousal": -0.4 }
    },
    "lineage": {
      "parents": ["cmb-a1b2c3d4e5f6"],
      "ancestors": ["cmb-a1b2c3d4e5f6"],
      "method": "SVAF-v2"
    }
  }
}

This example shows the legacy unsigned form (cmb- key, no sig); §8.2.1 and §18.3.1 define the current cmb1-/signed form.

4.3 TCP Transport (LAN)

The primary LAN transport. Nodes MUST listen on a TCP port and advertise it via DNS-SD (Section 5.1). Connection timeout MUST be no longer than 10,000 ms.

4.4 WebSocket Relay Transport (WAN)

A relay is an optional WebSocket intermediary that enables connectivity between peers on different networks. Peers on the same LAN discover each other directly via Bonjour mDNS (§5.1) and do not require a relay. The relay provides internet-scale routing between peers behind NAT, a peer directory with wake-channel gossip, and per-token channel isolation for multi-tenant deployments.

A relay is pure routing infrastructure. It does not store CMBs, evaluate SVAF, or participate in mesh cognition. Payloads are opaque to the relay. The relay MUST NOT inspect or modify frame payloads.

4.4.1 Authentication

Clients connect via WebSocket (RFC 6455) and MUST send a relay-auth frame within 10 seconds. Failure results in close code 4001.

{
  "type": "relay-auth",
  "nodeId": "<uuid-v7>",
  "name": "<display-name>",
  "token": "<channel-token>",
  "wakeChannel": {
    "platform": "apns",
    "token": "<push-token>",
    "environment": "production"
  }
}

• —nodeId, name: MUST be present. Missing fields result in close code 4002.
• —token: SHOULD be present if the relay requires authentication. Invalid token results in close code 4003.
• —wakeChannel: MAY be present. Registers push notification credentials for waking this peer when offline (§5.7).

On success, the relay registers the connection, sends a relay-peers response, and broadcasts relay-peer-joined to all other clients on the same channel.

4.4.2 Peer List

Immediately after authentication, the relay sends the current peer list:

{
  "type": "relay-peers",
  "peers": [
    { "nodeId": "<uuid>", "name": "<name>", "wakeChannel": {...}, "offline": false }
  ]
}

The array includes all connected peers on the same channel (excluding the requester) plus offline peers with registered wake channels (offline: true). Clients SHOULD treat each non-offline entry as a peer-joined event.

4.4.3 Peer Presence

{ "type": "relay-peer-joined", "nodeId": "<uuid>", "name": "<name>" }
{ "type": "relay-peer-left",   "nodeId": "<uuid>", "name": "<name>" }

Broadcast to all peers on the same channel when a peer joins or leaves.

4.4.4 Message Routing

On the relay, a frame is wrapped in a relay-layer routing envelope — this envelope is a transport wrapper, not itself an application frame, so the §4.1 “discard frames without a type” rule applies to the inner payload (the frame), not to the envelope:

{ "to": "<target-nodeId>", "payload": { "type": "cmb", ... } }

If to is present, the relay forwards to that peer only. If absent, the relay broadcasts to all peers on the same channel. The relay adds from and fromName to forwarded frames. The relay MUST NOT route frames across channels.

The presence of to also fixes the CMB’s binding at the receiver: a frame with to = the receiving node is peer-bound (directed) and is delivered to the application layer unconditionally; a frame with no to is group-bound (autonomous) and is SVAF-gated for delivery. See §9.2.2 for the directed-vs-autonomous delivery contract.

4.4.5 Keepalive

The relay sends relay-ping at a regular interval (RECOMMENDED: 10 seconds). Clients MUST respond with relay-pong. A client that misses two consecutive pings is closed with code 4005. Clients MAY send unsolicited relay-pong frames; the relay MUST accept them.

4.4.6 Re-authentication

If the relay loses a client’s registration (e.g. relay restart behind a TLS proxy), it sends { "type": "relay-reauth" }. The client MUST re-send relay-auth in response.

4.4.7 Duplicate Identity

When a client authenticates with a nodeId already held by an existing connection:

• —Fresh existing (< 5s): the relay MUST reject the newcomer with close code 4006. This prevents ping-pong loops where two processes with the same identity kick each other.
• —Stale existing (≥ 5s): the relay MAY replace the existing connection by closing it with code 4004. The relay MUST NOT broadcast relay-peer-left for the replaced connection.

Clients receiving code 4004 SHOULD log the collision and MUST NOT automatically reconnect. Clients receiving code 4006 SHOULD NOT reconnect — the existing holder is the legitimate one.

4.4.8 Channel Isolation

A relay MAY support multiple isolated channels. Each authentication token maps to exactly one channel. Cross-channel routing MUST NOT occur: frames, peer lists, and presence notifications are scoped to the channel. A relay with no token configured operates in open mode (single default channel, no authentication).

4.4.9 Close Codes

4.5 IPC Transport (Local)

Local tools MAY connect to a node via IPC (Unix domain socket, named pipe, or localhost TCP) to query mesh state. The framing is identical to TCP transport. IPC is an implementation convenience for local tooling (dashboards, CLI, monitoring) — it is not a substitute for peer-to-peer transport. Agents that participate in coupling MUST connect as full peer nodes via TCP or WebSocket.

The reference runtime provides a persistent IPC socket at a well-known path — an implementation convenience of the SYM runtime, not a wire requirement; a Class 1 Emitter (§17.1) need not provide it. Where provided, the socket SHOULD accept multiple simultaneous connections. Each IPC connection SHOULD remain open for the lifetime of the client application — short-lived connections (one query, then disconnect) are permitted but SHOULD be avoided by applications that query frequently.

Well-known IPC path: ~/.sym/daemon.sock (Unix domain socket) or localhost:19517 (TCP fallback).

4.6 Multi-Transport Per Peer

A peer MAY be reachable via multiple transports simultaneously (e.g. LAN TCP + WAN relay). Implementations MUST support maintaining multiple active transports for the same peer and select the highest-priority healthy transport for sending:

When a node receives an inbound connection from a peer that is already connected via a different transport, it MUST NOT reject the new connection. Instead it MUST add the new transport as a secondary path. Frames SHOULD be sent via the highest-priority healthy transport.

A transport is healthy if it has received a frame (including pong) within the heartbeat timeout (Section 5.4). An unhealthy transport SHOULD be closed after the timeout. The peer is only removed (peer-left event) when all transports for that peer are closed — not when a single transport drops.

This enables graceful failover: if a relay drops, the LAN transport continues. If LAN drops, the relay takes over. The peer remains connected throughout — only the active transport changes.

Q&A

5. Layer 2: Connection

5.1 Discovery

Nodes MUST advertise via DNS-SD with service type _sym._tcp in the local. domain. The instance name MUST be the node’s nodeId.

TXT record fields:

To prevent duplicate connections, the node with the lexicographically smaller nodeId MUST initiate the outbound TCP connection. The other node MUST NOT initiate.

Relay-based discovery. On platforms where mDNS is unavailable (cloud VMs, Windows without Bonjour SDK), nodes SHOULD use the relay’s relay-peers response as the discovery mechanism. Implementations SHOULD support both: DNS-SD for LAN, relay-peers for WAN.

5.2 Handshake

Upon connection, both sides MUST exchange the following frames in order:

1. handshake    { type: "handshake", nodeId: "<uuid>", name: "<name>",
                  publicKey: "<base64url>", version: "1.1.0", extensions: [],
                  lifecycleRole: "participant",               [sender MUST; absent → "participant"]
                  group: "<group-id>" }                       [optional, default "default"]
2. peer-info    { type: "peer-info", peers: [...] }           [if known]
3. wake-channel { type: "wake-channel", platform, token, env } [if configured]

Deprecated — state-sync. Earlier revisions exchanged a state-sync frame carrying the node’s hidden-state vectors (h₁, h₂) at this point in the handshake. Per the hidden-state locality invariant (Section 2.7), hidden state MUST NOT cross the wire. Implementations MUST NOT emit state-sync and SHOULD ignore it on receipt; peer influence is mediated entirely by CMBs evaluated through SVAF (Section 9.2).

• —The version field MUST be the MMP specification version the node implements (e.g., "1.1.0"). Nodes SHOULD accept peers with the same major version. Nodes MAY reject peers with incompatible versions.
• —The extensions field SHOULD list supported protocol extensions (e.g., ["mesh-group-v0.1"]). Nodes MUST ignore unrecognised extensions.
• —The group field is OPTIONAL and identifies the mesh group the node wishes to join (Section 5.8). A handshake without group MUST be treated as group = "default". When two nodes handshake and discover that their declared groups differ, the receiver MUST close the connection.
• —The inbound node MUST wait for a handshake frame as the first frame. If any other frame type arrives first, or no handshake arrives within 10,000 ms, the connection MUST be closed.
• —If a node receives a handshake with a nodeId that is already connected via the same transport type, the new connection MUST be closed (duplicate guard). If the existing connection uses a different transport type (e.g. peer connected via relay, new connection via LAN TCP), the new connection MUST be accepted as a secondary transport per Section 4.6.

lifecycleRole. Senders MUST include a lifecycleRole field with value participant (default), validator, or anchor; a receiver MUST treat a handshake without it as participant (backward compatibility with older nodes). The declared role is a discovery hint only — authority to apply validator-origin anchor weight (Section 6.4) or identify feedback CMBs (Section 11) is resolved through the signed role-grant chain (§6.5–§6.6), never from the handshake.

5.3 Connection State Machine

Implementations MUST NOT process cognitive frames (cmb, xmesh-insight) in the AWAITING_HANDSHAKE state.

5.4 Heartbeat

Nodes MUST send a ping frame to each peer if no frame has been received from that peer within the heartbeat interval (default: 5,000 ms). Upon receiving ping, a node MUST respond with pong. If no frame is received from a peer within the heartbeat timeout (default: 15,000 ms), the connection MUST be closed.

5.5 Connection Loss and Transport Failover

When a transport connection closes unexpectedly (TCP reset, timeout, OS-level close), the node MUST check whether other transports for the same peer are still active (see Section 4.6 Multi-Transport Per Peer).

• —If other transports remain healthy: the node MUST switch sending to the next highest-priority transport. The peer MUST NOT be removed. No peer-left event is emitted. The node SHOULD log the transport switch.
• —If no transports remain: the node MUST remove the peer from its coupling engine, discard buffered frames, and emit a peer-left event. The node SHOULD attempt re-discovery via DNS-SD.

Unexpected disconnection of a single transport MUST be treated as a transport-level event, not a peer-level event. The peer is only unreachable when all transport paths are exhausted.

5.6 Peer Gossip

After handshake, nodes SHOULD exchange peer-info frames containing known peer metadata (nodeId, name, wake channels, last-seen timestamps). This enables transitive peer discovery — a node that has never been online simultaneously with a sleeping peer can learn its wake channel through gossip from a relay node.

5.7 Wake

Nodes MAY register a wake channel (APNs, FCM, or other push mechanism) via the wake-channel frame. Peers MAY use this channel to wake a sleeping node when they have a signal to deliver. Wake requests SHOULD be rate-limited (default cooldown: 300,000 ms per peer).

5.8 Mesh Groups

A SYM node MAY declare membership in a mesh group at handshake time via the optional group field (Section 5.2). A mesh group is a named cohort of nodes that exchange application-layer frames only with each other. Mesh groups give an operator a way to host multiple mutually-isolated meshes on the same relay or LAN segment without per-agent application changes, and they give an application a way to constrain its peers to instances of itself rather than every node on the wire.

Group identifier syntax. A group identifier is a string of [a-z0-9-_.]+, max 64 characters, case-sensitive. The literal string "default" is reserved as the implicit group of every node that does not declare a group; this preserves backward compatibility with nodes that predate this section.

Protocol guarantee. A node in group G_A MUST NOT exchange any application-layer MMP frames (handshake fields beyond identity and version, cmb, mood, peer-info, xmesh-insight) with a node in group G_B when G_A ≠ G_B. Transport-layer connection establishment and ping/pong heartbeats are out of scope and MAY remain active across groups.

Layer placement. A mesh group is a Layer 2 (Connection) concept. The application layer SHOULD declare its group at SDK initialisation. The relay (Section 4.4) is a dumb pipe — relay-auth carries no group field and the relay MUST NOT inspect payloads (Section 4.4.4) — so it need not (and cannot) enforce group isolation. Isolation is enforced at the endpoints: the authoring group is bound into the signed CMB (§18.3.1 audience binding), and a receiver MUST reject a frame whose group does not match its own connection’s group, even if a relay misdelivers it. A relay MAY additionally scope rooms by a group-derived key as defense in depth. Nodes participating in LAN Bonjour discovery SHOULD enforce group isolation by checking the peer’s declared group at handshake and closing the connection on mismatch. The connection-level error frame for a group mismatch is described in Section 7.2.

Recommended naming convention (non-normative). The protocol does not parse group identifiers beyond the character set and length checks above. Operators of meshes with more than a handful of groups SHOULD adopt a hierarchical dotted-path convention <app>[.<environment>][.<cohort>], e.g. acme.prod, acme.dev, assistants.default, research.lab. The dots are convention only; tooling MAY use them for prefix-based grouping but the protocol does not require this.

SVAF and group filtering. SVAF (Layer 4, Section 9) per-field evaluation runs after group filtering: cmb frames from peers in different groups never reach the SVAF evaluator.

The naming convention above is the complete normative surface; deeper design rationale is runtime documentation, not part of this specification.

5.9 Interior and Boundary (the composition idea)

A mesh presents itself to another mesh as a single node: a gateway. A gateway participates in its own interior group as an ordinary node (§5.2, single group on the wire) and presents a boundary to exterior gateways over a separate transport. It is not one handshake declaring several groups — interior participation and the exterior boundary are distinct connections.

Admit-then-reproject, not relay (the intended grammar). The pattern forbids forwarding an interior frame outward. Instead a gateway admits its interior cognition through SVAF (§9) and emits a new lossy CAT7 projection (§2.7) outward — its own cognition, signed, carrying its own lineage (§15), never a relayed copy. This preserves the §5.8 guarantee (no interior frame crosses a group boundary) by construction. Implementation status: the reference prototype does not yet do this — see below.

5.10 The Gateway Node

A node is a membrane over an arbitrary interior. What makes something a node is entirely its boundary behavior: a stable identity (Section 3), a CAT7 projection of its state (Section 8), and a sovereign SVAF admission of others’ projections (Section 9). The interior behind the membrane is unconstrained. Two node types share this one membrane:

A gateway node is an ordinary node whose interior happens to be a mesh; its domain lens (Section 3.1) is “represent my interior.” Because the same emit / admit grammar holds at every scale — agent, team, org, cross-org — the mesh is fractal: any mesh MAY appear as a single node inside a larger mesh.

Relation to Section 3.2. “One agent, one node” is preserved. A gateway is not a shared identity: it has its own nodeId, its own keypair, and its own SVAF. Its interior agents are separate nodes on a separate (interior) group; the gateway participates in that interior group as an ordinary node and presents an exterior boundary (§5.9) — evaluating each side through its own lens, the very property Section 3.2 protects.

No center, per level. The “no center” invariant (Section 2.3) is enforced at each boundary, not as a claim about interiors. A gateway’s interior MAY be organized however it likes — centered or not; that choice does not leak, because only the gateway’s projection crosses. A member of an outer mesh MAY therefore be a gateway over a centered interior while the outer mesh remains center-free. Federation couples meshes; it MUST NOT synchronize them.

5.11 Boundary Behavior

For two gateway nodes A and B, each a mesh’s membrane, all cross-mesh behavior is the existing grammar applied at the edge:

• —Discovery. Cross-mesh discovery is by invitation or registry, not mDNS (Section 5.1 is LAN-only). A knows B as one node-id at one address; B is a peer, never a visible population.
• —Projection. What crosses is B’s own emissions — its lossy CAT7 projection of what it admitted internally — never B’s raw interior CMBs.
• —Membrane lineage. A gateway’s outward emission is a boundary root: its lineage (Section 15) MUST NOT carry the content-addresses of interior CMBs. An outer node citing it traces to the gateway and no further; the interior is opaque past the membrane, as required by hidden-state locality (Section 2.7). A gateway MAY retain the interior-to-boundary mapping privately, so it can re-project admitted outer cognition inward with correct interior lineage; that mapping MUST NOT cross the outward boundary.
• —Faithful projection. A gateway’s outward CAT7 should be a truthful lossy summary of the interior it represents, not a material misrepresentation. Because summarization is lossy, faithfulness is attestable, not bitwise: the intended design has the gateway sign its projection and record, in an admission attestation (§6.5), the interior verdict aggregate it was derived from — so an outer admitter can weigh the boundary claim by earned authority. This attestation is part of the production security bar and is unbuilt in the prototype.
• —Echo control. A cognition admitted from A and projected back toward A should origin-dedup at the boundary so cross-mesh loops do not amplify. Because a boundary root strips interior lineage, the dedup cannot match interior roots; instead a boundary projection carries its own cross-mesh provenance key (a boundary address, not an interior content-address), and a reprojection cites that key — so A detects the loop without the interior ever being exposed. (Unbuilt in the prototype; §15.7.1, on which an earlier draft leaned, is itself unimplemented.)
• —Partition. If B is unreachable, A’s mesh keeps cohering. Each mesh is independently alive; there is no cross-mesh consensus to stall on.

Boundary transport. The boundary is a dumb request/response transport (HTTP in the reference implementation): a gateway POSTs its projection to each configured peer gateway, and the peer ingests it as an opaque cross-mesh observation. The transport carries the projection only; it holds no shared store and performs no admission or routing on behalf of the meshes — a component that grew a shared store or an admission brain would be a center and must not be introduced. Discovery is by configuration (a gateway knows its peers by id + address + credential), not mDNS (§5.1 is LAN-only) and not a registry.

Sections 5.9–5.11 are informative and change no single-mesh contract: they describe how meshes may compose, drawing on the concepts of Sections 2.3, 2.7, 3.2, and 15. 1.0.6 introduced the composition pattern; a normative cross-mesh wire is not claimed — the reference implementation is a prototype and the production-security bar above is a prerequisite, not a shipped guarantee. Every single-mesh node is unaffected.

6. Layer 3: Memory

MMP defines three memory layers with graduated disclosure:

L0 data MUST NOT leave the node. L1 data MUST be evaluated by SVAF before storage. L2 data (CfC hidden state, h1/h2) MUST NOT leave the node either — per the hidden-state locality invariant (Section 2.7), hidden state is strictly local and only CMBs cross the wire. The state-sync frame that formerly carried these vectors is deprecated; implementations MUST NOT emit it and SHOULD ignore it on receipt.

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:

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:

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’s lineage.ancestors MUST NOT be deleted, even if past retention age. The remix chain is the audit trail — breaking it breaks provenance.

The Canon tier New in 1.1.0. A CMB whose lifecycle is validated or canonical MUST NOT be evicted by age-based retention (compaction or purge) while it holds that lifecycle. Committed cognition is the store’s reason to exist: canonical requires validation plus remix by two or more agents, so a small or single-operator mesh may never produce it — if only canonical were protected, such a mesh would forget everything it validated within one retention period. Protection is from purge, not from demotion: a validated CMB with no activity MAY still decay to archived per the §6.4 lifecycle (archiveAfterSeconds, §19), after which ordinary retention applies — the escape valve that keeps the store bounded (implementation status: §17.6). canonical deliberately has no inactivity decay: it records collective consensus (validation plus independent remix), and consensus does not expire by silence — it leaves the Canon only by an explicit dismiss or archive under validator-or-above authority (§6.5).

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.

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 SHOULD be 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 validation CMB (one whose lineage.parents points to an existing CMB), it MUST resolve the author’s role through the anchor-rooted grant chain (§6.6) — never the createdBy string, and never the peer’s advertised handshake role:

• —If the author resolves to validator or anchor, the parent CMB advances to validated (if action completed) or dismissed (if not actionable).
• —Otherwise the parent CMB advances to remixed only. The CMB is stored normally but confers no 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 & admission weight. Authority is the resolved role, never the advertised one. A node MUST NOT grant any authority-weighted treatment — lifecycle advancement, or the elevated origin admission weight a validator/anchor’s own CMBs receive (§6.4) — on the basis of a handshake lifecycleRole or a createdBy string. That origin weight MUST derive from the author’s chain-resolved role, and the elevation additionally requires a verified signature binding the CMB to that author. A single node that could self-declare anchor would otherwise double the admission weight of everything it emits — the highest-leverage poisoning primitive — which is exactly why the weight is gated on the resolved role. Where no anchor is pinned there is no root of trust: an implementation has no cryptographic authority to resolve and MUST treat all roles as unauthenticated — a closed/development mode only. Production deployments MUST pin an anchor.

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 11 (Feedback Modulation) for normative content requirements.

Boundary attestation. The same validation authority governs cognition that crosses a mesh boundary. A gateway node (Section 5.10) that emits a lossy projection of its interior on the interior’s behalf SHOULD sign that boundary emission and record, in its admission attestation, the interior verdict aggregate it was derived from — so an outer admitter can weigh the boundary claim by earned authority exactly as it weighs any peer. Interior and boundary trust are the same mechanism at two scales; see Section 5.11.

6.6 Authority Lifecycle: Grants, Resolution & Revocation

Authority that cannot be lost is decoration. This section defines how a role is conferred, resolved, and withdrawn — the mechanism §6.5 gates on.

Root of trust. Exactly one anchor is pinned out-of-band (its nodeId + public key) — configuration a receiver already trusts, not a claim made on the wire. The anchor is non-earnable; all other authority descends from it.

Grant / revoke frames. A role-grant confers a role on a grantee; a role-revoke withdraws it. Both are signed (§7 frame table; §18.3.1) by the grantor over the action, grantee, conferred role, grantor, grant time, and — for a grant — the grantee’s vouched public key. The vouch distributes keys along the chain: a node that never handshook the grantee learns its key tamper-evidently from a rooted grant (swapping it breaks the grantor’s signature), and a grant-sourced key MUST NOT override a key already learned from a stronger source (a direct handshake or the anchor).

Resolution. A node’s role at time T is resolved, not stored: the anchor is anchor; otherwise replay the node’s grants and revokes in chronological order up to T. A grant confers its role only if the grantor was authorised when it granted AND is still authorised at T (the grantor is resolved recursively, and must itself root at the anchor); a revoke clears the role if the revoker was authorised when it revoked. An unrooted or cyclic chain confers nothing; a grant a node was not entitled to make is stored but inert.

Revocation is effective, and does not rewrite the past. Because a grantor is re-resolved at the query time, revoking a grantor cascades — every role it granted resolves back to participant. Resolution is time-parameterised, so a revoke cuts future authority without invalidating what was legitimately done before it (an incoming CMB is judged at receipt; a stored attestation at its own emission time). And because a grant requires the grantor to be authorised both at grant time and now, a compromised-but- revoked grantor MUST NOT resurrect authority by signing a fresh grant backdated before its own revoke — the backdated grant’s grantor re-resolves as revoked, so the grant is inert. Demotion is revocation, optionally followed by a lesser re-grant. Grant timestamps are grantor-asserted and unwitnessed, which is precisely why authority is gated on re-resolution, not on a trusted clock.

Durability & integrity. Grants and revokes are gossiped to the roster and persisted append-only. The record has no integrity of its own, so an implementation MUST re-verify every record’s signature on load — top-down from the pinned anchor, using each verified grant’s vouched key to reach the next — and MUST NOT trust an on-disk record merely because it is present; a record not reachable from a verified anchor-rooted chain is dropped.

Identity vs. authority. This section withdraws authority. A compromised signing key is a different failure: MMP does not define key rotation (§3.4) — a node whose key is compromised generates a fresh identity and re-earns its role, while revoking its grants contains the damage in the meantime. Anchor-key compromise is root compromise, recovered only by re-pinning a fresh anchor out-of-band.

6.7 Grounding — Outcomes Carried by Lineage

Validation (§6.4–§6.5) records judgment — someone with authority committed to a CMB. Grounding records evidence — reality answered: the tests passed, the work shipped, the prediction held, or it did not. The two are deliberately distinct: a fast, self-referential mesh can mechanize coherence only; connecting cognition to the world requires an external outcome carried by lineage.

The grounding CMB. A grounding CMB is an ordinary CAT7 CMB whose intent is ground, whose lineage.parents contains the CMB(s) it grounds, and whose commitment carries the outcome, prefixed verified: or failed:. Any other commitment form is not a recognised outcome. It is emitted, signed (§8.7, §18.3.1), broadcast, SVAF-evaluated, and remixed like any other CMB — no new frame, no new field. A receiver that verifies signatures MUST reject an unsigned grounding CMB like any other unsigned CMB.

Repeat verification and the redundancy band. A verification report about a row the receiver already holds typically scores high alignment against exactly that row, so under an unmodified §9.2 gate, the better established a row, the harder it becomes to ground or re-ground it — repeat verifications are progressively refused as redundant, and the accepted-grounding stream of any one row self-quenches (a packing bound: only finitely many reports can each clear the redundancy separation, ever, absent retention purges). Sustained outcome tracking is load-bearing for the mesh being a learner rather than an accumulator, so acceptance of a grounding is exempted from exactly one band: a receiver MUST NOT refuse a recognised grounding CMB (signed, verified, intent = ground, recognised outcome prefix, lineage naming a target the receiver holds) solely because it is redundant against its target row or against previously admitted groundings of that target. The reject band (foreign content), the signature requirement, and the receiver’s trust weighing all stand unmodified. This is an acceptance-side rule and does not weaken the §15.7 anti-echo emission gate (§15.7.2: what legitimises a grounding emission is the fresh outcome observation behind it); spam through the waiver is bounded by the content address itself — a byte-identical repeat confirmation carries the same cmb1- key and deduplicates, so only distinct verification reports pass, and implementations MAY additionally rate-cap accepted groundings per (target, author) pair.

The failure channel is load-bearing. The signed outcome pair is not symmetric decoration: when recall preferentially re-uses highly-weighted rows, the failed: channel is the mechanism that makes preferential sampling self-correcting — a stale favourite’s absorbed grounding traffic drives its weight down — while a positive-only mesh locks onto early favourites at chance-level precision. An agent that observes a failure outcome MUST NOT suppress it while continuing to emit success outcomes for the same class of work; selective success-only grounding defeats the self-correction the outcome channel exists to provide. (Informative: the self-correction additionally requires outcome reports to be better than chance — miscalibrated reporting that is wrong more often than right converts the same coupling into entrenchment.)

Consuming the outcome stream (informative). A consumer that scores rows by their accepted groundings faces a bias–variance choice with a known theory. Pure accumulation (all-time counts) is the efficient estimator only while the useful set is stationary; under drift its staleness bias makes its ranking degrade toward chance. A recency-decayed signed sum tracks drift with bounded risk; its half-life trades noise against lag, with the optimum scaling as (V / (4μ²δ²))^(1/3) in the drift rate δ — a fixed half-life therefore pays a longer dominance horizon (Θ(δ⁻¹) instead of Θ(δ^−2/3)), and the tuned horizon is recoverable online by estimating drift with a growing-window slope probe (a fixed pair of probe timescales degenerates back to the fixed-half-life exponent; the growing-window form recovers the tuned one even on sparse signed ±1 outcome streams). Decayed sums should be mass-normalised (one extra scalar) — the raw zero-initialised form carries an initialization transient that delays its advantage by a log factor. Zero-clamping per-node sums before cross-node aggregation discards the negative evidence the failure channel carries; consumers that clamp should know the self-correction analysis above assumes the signed form.

An outcome is an attestation, not a fact. The grounding CMB asserts that its author observed the outcome. Its weight follows the author’s resolved authority (§6.5–§6.6) exactly as any other CMB’s does; the reserved intent value adds semantics, never authority.

Groundedness is receiver-relative. A CMB is grounded, in the view of a given node, iff a recognised grounding CMB targeting it (directly, or via the node’s admitted remix of one whose expanded ancestors reach it, §15.2) is present in that node’s own store. There is no global grounded state; a node MUST NOT treat cognition as grounded on the strength of a grounding entry it never admitted. Grounding runs upward only — a grounding CMB grounds the CMBs its lineage points at, never descendants of those CMBs: a remix of verified cognition is not itself verified.

Outcomes are observations of a changing world. When several recognised grounding CMBs target the same cognition in one store, the latest by stored time wins: a later failed: un-grounds what an earlier verified: established (a regression must surface, not be shadowed by history). “Stored time” is the receiver-local time the entry entered the evaluating store — never the author-asserted createdAt, which is unwitnessed (§6.6) and would let a backdated or future-dated attestation game the ordering. Authority modulates whether to act on an attestation, not the temporal ordering of observations — and latest-wins applies within an authority tier, not across tiers. Hard-gate reading (normative): a failed: from an author below the authority of the standing verified: MUST NOT un-ground it — a below-validator failed: cannot overturn a validator-or-above verified:. This is the tested-effective form: a soft authority-weighted vote is defeated by sheer low-authority volume, whereas the tier gate holds a validated outcome against any number of below-tier failed: reports (see the §18.4 threat note on outcome griefing). Within a tier — equal authority, or a genuine same-authority regression — latest-wins still applies, so a real regression surfaces.

Grounding never advances lifecycle by itself. §6.5 stands unweakened: a CMB cannot self-grant effect, and a grounding CMB is a CMB. A node MAY advance its own store’s entries to validated on grounding evidence — evidence-based validation — but only as an explicit act under validator-or-above authority (§6.5–§6.6), never as an automatic consequence of receiving or reading a grounding CMB, and never as a side effect of a query. The elevating authority is accountable for the judgment; it SHOULD require verified: polarity and weigh the grounding author’s resolved authority before acting. Self-reported outcomes from unauthenticated or participant-rank authors SHOULD NOT trigger elevation.

The team Canon (informative). No shared store exists. A member’s Canon is the validated/canonical ∪ grounded cognition of its own store — including remixes its own SVAF admitted from teammates. What a cockpit renders as a “team Canon” is the emergent overlap of members’ Canons, read from same-host stores only (a remote member’s store is sovereign and is never fetched). Adoption is meaningful precisely because every admission was autonomous.

Q&A

7. Frame Types

All frames are JSON objects with a type field (string). Implementations MUST silently ignore frames with unrecognised type values to allow forward compatibility.

7.1 Frame Type Registry

All cognitive content — observations, decisions, feedback, directives — MUST be sent as cmb frames. Only cmb frames enter SVAF evaluation, produce anchor weights, and modulate CfC state.

The relay-* types are transport-scope (Section 4.4): they are exchanged between a node and a relay, never between peers, and never reach the application layer. The relay forwards peer frames as opaque payloads (Section 4.4.4) and does not originate any of the peer-scope types above.

Deprecated — state-sync. The state-sync frame carried a node’s hidden-state vectors (h₁, h₂). Per the hidden-state locality invariant (Section 2.7), hidden state MUST NOT cross the wire. Implementations MUST NOT emit state-sync and SHOULD ignore it on receipt. It is retained in this registry only to reserve the type and document the deprecation; all peer influence flows through cmb frames evaluated by SVAF.

7.2 Error Frame

When a node encounters a protocol-level error, it SHOULD send an error frame before closing the connection (if applicable). Error frames are informational — the receiving node MUST NOT treat them as commands.

Codes 1xxx are connection-level (close connection). Codes 2xxx are evaluation-level (informational). Error frames MUST NOT contain sensitive information.

7.3 Type Naming and Extensions

Frame types are identified by their type string value. Core types (this specification) MUST NOT be redefined by extensions. Extension types MUST use <extension>-<name> format. Vendor types MUST use x-<vendor>-<name> format and MUST be silently ignored by non-supporting nodes.

Q&A

8. Cognitive Memory Blocks (CAT7)

A Cognitive Memory Block (CMB) is an immutable structured memory unit. Each CMB decomposes an observation into 7 typed semantic fields (the CAT7 schema). CMBs are the data structure that flows between agents via cmb frames.

Forward compatibility. Implementations MUST silently ignore unrecognised CMB fields. A node that receives a CMB carrying additional fields from a future version MUST process the 7 known CAT7 fields and discard any others without error. This allows schema evolution without breaking existing deployments.

8.1 Why 7 Fields

The 7 fields form a minimal, near-orthogonal basis spanning three axes of human communication: what (focus, issue), why (intent, motivation, commitment), and who/when/how (perspective, mood). They are universal and immutable — domain-specific interpretation happens in the field text, not the field name. A coding agent’s focus is “debugging auth module”; a fitness agent’s focus is “30-minute HIIT workout.” Same field, different domain lens.

mood is the only fast-coupling field — affective state (valence + arousal) crosses all domain boundaries. The trained SVAF model studied in the SVAF paper converged on the same rule: mood emerged as the highest gate value (0.50) without supervision — a research result consistent with affect being universally relevant across agent types. (The deployed evaluator is the heuristic baseline, Section 9.2.1.) All other fields couple at medium or low rates, with per-agent α_f weights controlling relative importance.

New agent types join the mesh by defining their α_f field weights — no schema changes, no protocol changes. The 7 fields are fixed. The weights are per-agent.

8.2 Field Schema

Implementations MUST use the following 7 fields in this order:

Each field carries a symbolic text label (human-readable) and a unit-normalised vector embedding (machine-comparable). The mood field additionally carries numeric valence (-1 to 1) and arousal (-1 to 1) values.

A CMB MUST NOT be modified after creation. When an agent remixes a CMB, it MUST create a new CMB with a lineage field containing: parents (direct parent CMB keys), ancestors (full ancestor chain, computed as union(parent.ancestors) + parent keys), and method (fusion method used). Ancestors enable any agent in the remix chain to detect its CMB was remixed, even if it was offline during intermediate steps.

8.2.1 Content Address & Canonical Serialization

A CMB’s key is a content address: a SHA-256 hash over a fully specified canonical serialization of the block, prefixed to be self-describing about its scheme. Two independent conforming implementations MUST compute the identical key for the same logical CMB — the key is both the node identity in the lineage DAG and the value the author signature binds (§18.3.1), so any divergence breaks lineage, dedup, citation, and integrity. The published test vectors are the normative contract.

Legacy scheme (cmb-) — the previous format, retained for the migration: a conforming node MUST still verify it. It is specified here byte-exactly (it was previously under-specified, which is how an implementation change went undetected against the spec):

key = "cmb-" + first 32 hex chars of SHA-256( UTF-8( focus.text + "|" + issue.text + "|"
              + intent.text + "|" + motivation.text + "|" + commitment.text + "|"
              + perspective.text + "|" + mood.text ) )

// Field order per §8.2; mood contributes its text only; empty fields contribute "";
// no Unicode normalization.

This scheme has three known weaknesses, which the successor resolves: the | join is not injection-proof (a delimiter inside a field can shift a boundary), text is not Unicode-normalised (NFC vs NFD diverge), and the 128-bit truncation gives only 64-bit collision resistance.

Normative scheme (cmb1-) — the format the reference implementation mints; a conforming node MUST verify it and SHOULD mint it:

key = "cmb1-" + hex( SHA-256( preimage ) )          // full 256 bits, 64 hex chars

preimage = "mmp-cmb-v1\n"                            // domain-separation tag
         + LP(NFC(focus.text)) + LP(NFC(issue.text)) + … + LP(NFC(mood.text))   // 7 CAT7 fields, fixed order
         + LP(role)                                  // "root" or "remix"
         + [ if remix:  LP(decimal(parentCount)) + LP(parentₖ) …  + LP(receiverNodeId) ]

LP(s)    = decimal(byteLength(UTF-8(s))) + ":" + UTF-8(s)   // netstring length-prefix

• —Field text MUST be Unicode NFC-normalised (UAX #15) before serialization. Field order is the CMB_FIELDS order of §8.2. The mood field contributes its text only; valence/arousal and all vector embeddings are excluded from the address.
• —Netstring length-prefixing makes the serialization injection-proof (a delimiter inside a field cannot shift a boundary) with no escaping and no JSON-canonicalization dependency, so implementations in different languages agree byte-for-byte.
• —A root CMB binds content only — identical content by any author at any time yields one key (enabling dedup, not re-derivation of provenance, which lives in lineage and the signature). A remix additionally binds its parent set (sorted ascending by UTF-8 byte order of the key strings) and the receiver’s nodeId, keeping each agent’s remix a distinct DAG node.
• —The full 256-bit width is normative: a truncated hash’s birthday bound would admit a grind-then-substitute attack against the signed key. The cmb1- prefix makes the scheme self-describing, so hash agility (a future cmb2-) is unambiguous.

Migration (mint vs verify). A conforming node MUST verify keys of both schemes, dispatching on the prefix, so a peer still on the legacy cmb- scheme is accepted throughout the migration. It SHOULD mint cmb1-; an implementation MAY provide a mode that mints the legacy scheme for a staged rollout or rollback. Illustrative keys elsewhere in this specification predate the scheme change and use the short cmb- form.

8.3 Field-by-Field Guide

The schema is fixed. The interpretation is sovereign. Each field below gives a definition, the rationale for why the field earns a slot in a 7-field minimal basis, and three cross-domain examples showing how agents from different domains populate the same field.

8.3.1 Well-Known Intent Values Informative · New in 1.1.0

intent is free text and stays free text — this registry reserves no syntax and adds no field. It records conventions that have emerged in practice, so independent implementations converge on the same vocabulary. The registry is informative and extensible: an unknown intent value MUST be treated as ordinary content, and behavior MUST NOT be keyed on unrecognised values. Per §6.5, content is informational — authority always comes from who created the CMB, never from what its intent says.

ground is the protocol’s first intent value with any attached semantics; the precedent is deliberately narrow. Those semantics bind the receiver’s optional interpretation only — they confer nothing on the emitter, and §15.7.2 explains why no intent value exempts an emission from the new-domain-data rule.

8.4 Per-Agent Field Weights (α_f)

The schema is fixed. The weights are per-agent. New domains join the mesh by defining their α_f weights — no schema changes, no protocol changes. Regulated domains (legal, finance) weight issue and commitment highest; human-facing domains (music, fitness, health) weight mood highest; knowledge domains (coding, research) weight focus highest.

8.5 Artifacts

Agents produce two types of output: signals (CMBs — structured 7-field observations) and artifacts (documents, analyses, drafts, code — full-length content that a CMB references). A CMB is the signal on the mesh. An artifact is the substance behind it.

When an agent produces an artifact, it SHOULD share a CMB to the mesh that references the artifact location in the commitment field using the artifact: prefix:

The CMB’s other 6 fields summarise what the artifact contains — the focus captures the key finding, issue captures the gap identified, intent captures what should happen next. Other agents evaluate the CMB via SVAF as usual. If accepted, the agent MAY retrieve the full artifact for deeper reasoning.

Artifacts are stored in the producing agent’s local filesystem, not on the mesh. The mesh carries signals; agents carry substance. This separation keeps CMBs lightweight (7 fields, bounded size) while allowing agents to produce unbounded analysis, research, and creative work.

The artifact: convention in commitment is RECOMMENDED for any CMB that references a document, file, or external resource. Agents MUST NOT embed full artifact content in CMB fields — fields are for structured signals, not documents.

8.6 Origin

Cognitive Memory Blocks were first formalised in the Mesh Memory Protocol (Consenix Labs, August 2025) with the CAT7 enterprise schema. The wellness / productivity schema and the synthesis-affinity classification were developed at SYM.BOT in late 2025 for production deployment across personal AI agents.

8.7 Authentication

A CMB SHOULD carry its author’s signature in cmb.sig (base64url) with cmb.sigAlg. Receivers verify the signature and content-address integrity before admitting or surfacing a block. See §18.3.1 CMB Signature Verification for the normative signing and verification requirements.

Q&A

9. Layer 4: Coupling and SVAF Evaluation

9.1 Peer-Level Coupling (Drift)

Peer drift measures how cognitively distant a peer is, so the mesh can weight that peer’s influence (Section 10). Per the hidden-state locality invariant (Section 2.7), hidden state MUST NOT cross the wire, so drift MUST NOT be computed from exchanged hidden vectors. A node MUST instead derive peer drift from the peer’s CMBs — the aggregate per-field admission drift (δ_f, Section 9.2.1) of the peer’s most recent admitted CMBs against the receiver’s local anchors A:

Drift falls as the peer’s CMBs become redundant with what the receiver already holds (cognitive proximity) and rises when they are foreign — the same δ_f machinery SVAF uses for content admission, aggregated to the peer level. No hidden state is exchanged.

Coupling decision based on drift:

9.2 Content-Level Evaluation (SVAF)

When a node receives a cmb frame, it MUST evaluate the signal independently of peer coupling state, through an admission path that satisfies the δ_f interface (Section 9.2.1). “Support” here means interoperate-with, not implement-only-this: every implementation MUST provide the concrete cosine-distance baseline (Section 9.2.1) as its interoperable floor — the path a node with no other method uses, and the one interop test vectors target — and its baseline path MUST reproduce those vectors. An implementation MAY additionally use a richer path (a trained neural evaluator is one such path; the heuristic baseline is the production default in the reference runtime); a richer path still satisfies the interface, but admission is then receiver-divergent by design (Section 2.7), not identical across nodes. (The mood field’s unconditional delivery is a Section 9.3 delivery mechanism, separate from this admission evaluation.) The encoder that maps field text to vectors SHOULD use semantic embeddings (e.g. sentence-transformers) rather than lexical hashing — per-field evaluation quality is bounded by encoder quality (Section 18.7), so thresholds are meaningful only within a pinned encoder.

The SVAF evaluation computes per-field drift between the incoming CMB and local anchor CMBs, applies per-agent field weights (α_f), combines with temporal drift, and produces a four-class decision using a band-pass model:

totalDrift = (1 - λ) × fieldDrift + λ × temporalDrift

fieldDrift    = Σ(α_f × δ_f) / Σ(α_f)
temporalDrift = 1 - exp(-age / τ_freshness)

κ = redundant if max(δ_f_near) < T_redundant  (default 0.10)   // nearest-anchor basis, §9.2.1
κ = aligned   if totalDrift ≤ T_aligned    (default 0.25)
κ = guarded   if totalDrift ≤ T_guarded    (default 0.50)
κ = rejected  otherwise

Admission is evaluation-time-dependent by design. Because totalDrift blends content drift with temporalDrift, the same CMB can admit when evaluated fresh and reject when evaluated late: any block whose aggregated field drift D lies in ( (Tguarded − λ) / (1 − λ),  Tguarded / (1 − λ) ) — at the defaults (λ = 0.3, T_guarded = 0.5), D ∈ (0.286, 0.714) — crosses the guarded boundary as its age term saturates. Below that window a block admits at every age; above it, it rejects even fresh. This is a consequence of the blend, disclosed rather than incidental: freshness is part of relevance, so a receiver’s verdict on stale traffic legitimately differs from its verdict on live traffic. Implementations and operators MUST NOT assume admission is reproducible across evaluation times; reproducibility holds only at fixed age (see the determinism & test-vectors note below).

9.2.1 Per-Field Drift δ_f (Admission Interface)

δ_f ∈ [0,1] is the per-field admission drift computed for each CAT7 field of an incoming CMB. This specification defines δ_f as an interface — its inputs, range, and required invariants — and does not prescribe the internal computation. An implementation is free to use cosine-distance, attention-based, or neural methods, provided the invariants below hold.

Inputs: the incoming field vector x_f and the receiver’s local anchor set A (its prior memory). Output: δ_f ∈ [0,1] — 0 means the field is already represented in memory (no information gain); 1 means maximally novel or foreign relative to memory.

A conformant δ_f MUST satisfy:

1. Anchors-only baseline. δ_f is evaluated against the receiver’s prior anchors A only; the incoming block MUST NOT be part of its own comparison baseline (including it collapses δ_f → 0 and admits nothing).
2. Redundancy limit (nearest-anchor basis). The redundancy decision MUST be computed from the nearest-anchor similarity, δfnear = 1 − maxa cos(xf, va,f): if x_f is (near‑)identical to some anchor in A, δ_f^near → 0 by construction — feeding the max(δfnear) < Tredundant gate. Stated of the graded δ_f itself, this invariant is unsatisfiable by the attention-weighted reference baseline below — with a store holding exactly the anchor (1,0) plus two anchors (0.6, 0.8), the block x = (1,0) is identical to a stored anchor yet the fused readout scores δ = 0.127 — which is why the invariant is pinned to the basis that satisfies it.
3. Monotonicity (nearest-anchor basis). δ_f^near is non-increasing in maxa cos(xf, va,f) (immediate), and non-increasing under store growth (A ⊆ A′ implies δ_f^near over A′ ≤ δ_f^near over A) — novelty never increases as memory grows. The form “δ_f non-increasing in similarity to the nearest relevant anchor” is ill-posed for the fused readout — δ_f is not a function of nearest-anchor similarity alone — and even its dominance reading (x′ at least as similar to every anchor) is violable for the reference baseline, so no monotonicity requirement is placed on the graded score.
4. Cold-start / non-evaluable fields. If A holds no anchor carrying field f, δ_f is undefined and that field MUST be excluded from the fieldDrift aggregation and the redundancy max — not treated as maximally novel. If no field is evaluable (empty memory), the CMB MUST be admitted (κ = aligned) to bootstrap, consistent with cold-start convergence (§9.1). Security consequence, disclosed: bootstrap-admit is the price of avoiding cold-start starvation — during the window before a node forms anchors, its membrane admits everything, so the content-trim influence bound of §16 does not cover a fresh node, and the first anchors seed every later admission decision. Operators SHOULD seed new nodes with trusted anchors before exposing them to open traffic; see the cold-start-capture row of the §16 threat table.

These invariants make admission well-defined and rule out two failure modes: self-referential collapse (the incoming block in its own baseline ⇒ every field redundant) and cold-start starvation (empty memory ⇒ every field scored foreign ⇒ the CMB rejected). The concrete δ_f computation is implementation-defined, but this specification pins one — the reference baseline below — as the interoperable default.

The reference baseline (cosine-distance δ_f). This is the concrete computation “cosine-distance SVAF” (Section 9.2) names: an attention-weighted read of memory, then cosine distance to it. For each field f the incoming CMB carries a vector x_f, and each anchor a ∈ A that carries f with a matching-dimension vector v_a,f:

w(a,f)      = α_f · max(cos(x_f, v_a,f), 0) · exp(−age_a / τ) · conf_a
fused_f     = normalize( Σ_a  w(a,f) · v_a,f )     // attention-weighted memory readout (anchors only)
δ_f         = 1 − cos(fused_f, x_f)                 // graded score: drives aligned/guarded/rejected
δ_f_near    = 1 − max_a cos(x_f, v_a,f)            // nearest-anchor basis: drives the redundancy gate

• —age_a is the anchor’s age (seconds since stored); conf_a its confidence; α_f the field weight (§9.2). The max(cos,0) clamp stops opposing anchors from subtracting. The readout uses prior anchors only; if Σ_a w(a,f) is ~0, no anchor carries f and δ_f is non-evaluable (excluded, per the invariants). δ_f, the α-weighted aggregate, and the band-pass then follow §9.2.
• —Determinism & test vectors. Given fixed field vectors (carrying no text, so nothing is re-encoded), the encoder and adaptive timescale off, and pinned τ, signal age, and each anchor’s stored-time + confidence, the baseline produces a deterministic δ_f, totalDrift, and κ. A conformance test vector fixes these and asserts the exact values — it tests the math, not the encoder — so the baseline is reproducible across implementations even though live admission is receiver-divergent by design (different encoders, different α_f).

The redundancy test is the key addition: a signal is redundant if every field falls below T_redundant — meaning no field carries novel content relative to local anchors. If any field is novel (e.g., same topic but different intent), the signal passes. This preserves per-field selectivity while preventing paraphrase accumulation.

Information-theoretic basis: a signal’s value is proportional to its surprise (Shannon, 1948). A signal identical to existing knowledge carries zero information gain regardless of domain alignment. The band-pass model reflects the Wundt curve (Berlyne, 1970): intermediate novelty produces maximal value, while both overly familiar (redundant) and overly foreign (rejected) signals are disengaged from.

If admitted (κ ∈ aligned or guarded), the implementation MUST integrate the signal — store a remixed CMB (a new CMB created from the incoming signal processed through the agent’s domain intelligence) with lineage (parents + ancestors) pointing to the source CMBs. This store is unconditional on admission; the remixed CMB is stored locally, the original is not. Whether to re-broadcast that remix to the mesh is a separate decision, gated on the agent’s own new domain data (§15.5, §15.7). A redundant near-duplicate stores nothing (no information gain).

9.2.2 Delivery vs Memory Admission — Directed and Autonomous CMBs

SVAF governs two separate receiver decisions that implementations MUST not conflate:

• —Memory admission — whether the incoming CMB is stored (remixed with lineage) into the receiver’s local memory. This is always governed by the §9.2 band-pass decision κ.
• —Delivery (surfacing) — whether the CMB is surfaced to the receiver’s application/agent layer for it to act on. Whether SVAF gates delivery depends on how the CMB is bound.

A CMB’s binding is determined by its transport routing envelope (§4.4.4) — the presence or absence of a to recipient:

• — Group-bound (autonomous). A CMB broadcast to a channel/group with no to recipient. The receiver evaluates it autonomously: SVAF gates both memory admission and delivery. A group-bound CMB that SVAF rejects (or deems redundant) MUST NOT be surfaced to the application layer — this is receiver-autonomous attention, the mechanism that keeps broadcast traffic from overwhelming every node. (Mood is the sole exception — §9.3.)
• — Peer-bound (directed). A CMB addressed to a specific recipient (to = this node, §4.4.4). A directed CMB is a request from one agent to another; the receiver MUST surface it to the application/agent layer unconditionally, regardless of the SVAF verdict. For a directed CMB, SVAF governs memory admission only — the receiver MAY still decline to store a directed CMB it finds redundant or foreign, but it MUST NOT withhold delivery on those grounds. Suppressing a peer-bound CMB because SVAF scored it low is a conformance defect (the agent was spoken to and did not hear it).

Delivery MUST be exactly-once per received CMB: a directed CMB that SVAF admits surfaces through the normal admission path; a directed CMB that SVAF rejects surfaces through the unconditional-delivery rule above. Implementations MUST ensure these two paths do not both fire for the same CMB. Receive-path de-duplication (§4.2) applies equally to both bindings.

Because delivery and memory admission are decoupled, a delivered CMB SHOULD carry an ingestion indicator so the consuming agent can tell the two outcomes apart: a CMB that was ingested (admitted to memory as a remix with lineage) versus one that was delivered only (surfaced to the agent but not stored — the directed-but-SVAF-rejected case). Without this signal an agent cannot know whether a directed request it just received is recallable from its own memory later or was a transient message. The reference implementation exposes this as a boolean on the delivered entry (remixed: true on the admission path, false on directed delivery-without-admission) alongside the SVAF decision.

9.3 Mood Field Extraction

Mood is a CAT7 field within the CMB; it is also carried as its own lightweight frame type (mood, §7.1) for application-layer mood broadcast, distinct from cmb frames — in either carrier, mood delivery is not SVAF-gated memory admission. Affective state crosses all domain boundaries — this is the only field with this property.

When SVAF rejects a CMB (totalDrift > T_guarded), the receiving node MUST still inspect the mood field. If the mood field contains a non-neutral value (text ≠ "neutral"), the implementation MUST deliver the mood field’s text to the application layer for autonomous processing; valence and arousal SHOULD be included when present (they are RECOMMENDED, not required, at emission — §8.2). The full CMB is not stored, but the mood field is not lost.

This ensures that a coding agent’s observation “user exhausted after 3 hours debugging” reaches a music agent even though the focus (“debugging auth module”) and issue (“type error in handler”) fields are irrelevant to the music domain. The music agent receives only the mood: "exhausted" (v:−0.6, a:−0.5).

9.4 Coupling Bootstrap (Cold Start)

When two agents connect for the first time, they have no shared cognitive history. Peer-level drift (Section 9.1) will be high — typically > 0.8 — because neither has yet admitted any of the other’s CMBs, so every field reads as foreign. This is correct behaviour, not a bug. The mesh is conservative by default: unknown peers are cognitively distant until proven otherwise.

However, CMB evaluation (Section 9.2) operates independently of peer coupling state. Even when a peer is rejected at the peer level, incoming cmb frames MUST still be evaluated by SVAF on their own merit. A rejected peer can send a highly relevant CMB — SVAF evaluates the content, not the sender’s overall drift.

The bootstrapping path works through two mechanisms:

• —Mood fast-coupling (Section 9.3) — mood is always delivered even from rejected CMBs. Agents that share non-neutral affective state begin influencing each other immediately. This is why agents SHOULD extract genuine mood from their observations rather than defaulting to neutral.
• —Content-driven convergence — when SVAF accepts individual CMBs from a rejected peer (because the content is relevant even though the peer’s overall state is distant), the receiving agent’s cognitive state shifts. Over multiple cycles, this narrows peer drift until the peer crosses into the guarded or aligned zone.

Implementations SHOULD log the distinction between peer-level rejection (aggregate drift) and content-level evaluation (SVAF per-CMB) to aid debugging. A peer may be “rejected” at Layer 4 while its individual CMBs are “aligned” at the content level — this is normal during bootstrap and indicates convergence is in progress.

Cold-start convergence time depends on CMB frequency, field relevance, and mood signal strength. For agents that share domain overlap (e.g., a knowledge agent and a coding agent both in the AI domain), convergence typically occurs within 2–5 CMB exchanges. For agents with no domain overlap (e.g., a fitness agent and a legal agent), convergence may never occur — and that is correct. They couple only through mood.

Q&A

10. State Blending

State blending is one step in the Mesh Cognition cycle. The full path: inbound CMBs are evaluated by SVAF (Layer 4) → accepted CMBs are remixed → the agent’s LLM reasons on the remix subgraph via lineage ancestors → Synthetic Memory (Layer 5) encodes derived knowledge into CfC hidden state → the agent’s LNN (Layer 6) evolves cognitive state. That evolution — a node’s own LNN integrating its own admitted remixes — is what “state blending” names.

Per the hidden-state locality invariant (Section 2.7), hidden state (h₁, h₂) never crosses the wire. Blending therefore does not import, average, or overwrite a peer’s hidden vectors. The only thing a peer contributes is the CMBs it emitted; those that SVAF admits (Section 9.2) are remixed and fed through this node’s own LLM and LNN. What a peer shares is its understanding expressed as CMBs, not its hidden state.

Blending is inference-paced — admitted remixes accumulate continuously, but integration only occurs when the local model runs inference. The network’s timing does not drive computation.

10.1 Weighting Peer Influence

When multiple peers are connected, the CMBs each peer has contributed are weighted by how aligned and how recent that peer is, so a closer, more active peer influences this node’s inference more. peer_weight is a bound on admission influence — it caps how much a single admitted CMB’s content (Section 9.2) may shift this node’s local integration input at Layer 6. It applies to each peer’s admitted CMBs, never to any exchanged hidden vector:

peer_weight = (1.0 - drift) × recency

recency     = exp(-temporal_decay × age_seconds)

// peer_weight is a bound on ADMISSION INFLUENCE: how much an admitted
// CMB from that peer may shift this node's Layer 6 integration input.
// It is NOT applied to peer hidden vectors — none are exchanged (§2.7).

Peers with low drift (cognitively aligned) and recent activity contribute more. Stale peers (older than PEER_RETENTION = 300s) are evicted.

10.2 Coupling Strength

The coupling decision from Layer 4 (Section 9.1) sets αeffective, the upper bound on admission influence: how much a single admitted CMB’s content may shift this node’s local integration (the Layer 6 input) during inference. It is not a per-neuron vector blend — there is no exchanged vector to blend (Section 2.7). The coefficient is bounded below 1, so a peer influences but never overrides:

sim_i  = 1 - |local_i - mesh_i| / max(|local_i|, |mesh_i|)
α_i    = α_effective × max(sim_i, 0)
out_i  = (1 - α_i) × local_i + α_i × mesh_i

10.3 τ-Modulated Integration (CfC)

For implementations with CfC models (Layer 6), how strongly admitted influence moves each neuron SHOULD be modulated by that neuron’s own time constant (τ). This is a property of the node’s own LNN — not of any exchanged vector — and creates a natural temporal hierarchy:

α_i = min(α_effective × K / τ_i, 1.0)

K   = coupling rate (default 1.0)
τ_i = neuron i's own time constant (fast → small, slow → large)

10.4 Stability

By design, integration remains a contraction toward the node’s own dynamics for α_effective < 1. Each admission’s influence on the local state is bounded by α_i < 1 (Section 10.3), so every integration step remains a contraction toward the node’s own dynamics — admitted content perturbs the trajectory, it cannot replace it, and the state cannot diverge. No step depends on a shared or global vector; stability is a local property of each node. When peers disconnect, the node smoothly continues on its own admitted history with no discontinuity. The mesh degrades gracefully.

10.5 After Integration

The integrated state becomes the input to the next CfC inference step. The agent’s LNN processes it, evolves cognitive state, and the agent acts. Integration does not produce output directly — it influences the next inference cycle.

10.6 The Mesh Cognition Loop

State blending is one step in a closed loop. Each cycle, the graph grows and every agent understands more than it did before:

11. Feedback Modulation

Feedback modulation is the mechanism by which collective intelligence becomes self-correcting. It is not a separate system — it is the mesh cognition loop (Section 10.6) processing a specific class of signals: human judgment expressed as CMBs with validator authority and per-field reasoning. Teaching is as fundamental to collective intelligence as coupling. Without it, the mesh can think together but cannot learn together.

11.1 Feedback Neuromodulation

The mesh cognition loop (Section 10.6) describes how agents learn from each other. Feedback neuromodulation describes how the mesh learns from human judgment — using the same loop, not a separate channel.

In biological neural networks, learning is not driven by content transmission but by neuromodulation — diffuse chemical signals (dopamine, norepinephrine, serotonin) that modulate how existing circuits process future inputs. A dopaminergic prediction error signal does not carry the correct answer. It carries the direction and magnitude of the error, which adjusts synaptic weights across multiple brain regions simultaneously. The signal is cross-cutting — it is not a layer in the cortical hierarchy, but a modulation of all layers at once.

MMP feedback follows the same principle. When a validator node (Section 6.5) produces a validation or dismissal CMB, it is not issuing a command. It is producing a neuromodulatory signal — a CMB with validator authority, rich per-field content, and lineage pointing to the signal being evaluated. This CMB enters the mesh cognition loop like any other signal, but its effects are amplified by three mechanisms:

This is how the mesh becomes self-correcting. The human does not retrain the agent, reconfigure its weights, or edit its prompt. The human produces a CMB. The mesh cognition loop does the rest.

Feedback recognition. When a node receives a feedback CMB (a CMB with lineage.parents from a validator/anchor node), the receiving node SHOULD check whether any of the parent keys match CMBs it produced. If a match is found, the feedback is about the receiving agent’s own prior output. Implementations SHOULD surface this in the LLM reasoning context so the LLM can adjust its analytical approach. This check is O(1) against the node’s local memory index.

Neuroscience grounding

11.2 Feedback CMB Requirements

The effectiveness of feedback neuromodulation depends entirely on the content quality of the feedback CMB. A dismissal that says “not actionable” in every field produces a neuromodulatory signal with no direction — the equivalent of a dopamine signal with zero magnitude. The mesh cannot learn from it.

Validator nodes producing validation or dismissal CMBs SHOULD populate CAT7 fields with reasoning, not boilerplate:

Feedback is a remix. The operator processes the agent’s signal through their own domain lens and produces new understanding. The operator’s reasoning constitutes new domain data per Section 15.7 — satisfying all three remix conditions: new domain data exists, the peer signal is relevant, and the intersection produces new knowledge.

11.3 Directive Feedback

Sections 11.1–11.2 describe feedback tied to a specific CMB via lineage. Directive feedback is a standalone teaching CMB — a signal that injects domain knowledge into the mesh without requiring a parent ticket.

A directive feedback CMB is produced by a validator or anchor node with:

• No lineage.parents (it is not a response to a specific signal)
• Rich CAT7 fields encoding the knowledge to be injected
• Validator authority (Section 6.5) — enters at anchor weight 2.0

focus:       "This mesh reviews backend services. Frontend framework
              releases are a separate concern."
issue:       "Feed signals about frontend framework releases are
              out-of-scope noise for a backend review mesh."
intent:      "Analytical frame: distinguish backend runtime signals
              (in scope) from frontend tooling signals (out of scope).
              Only the former is relevant here."
motivation:  "Prevents wasted analysis cycles on signals outside the
              mesh's review scope."
perspective: "Operator, mesh steward"
mood:        { text: "clarifying", valence: 0.1, arousal: 0.2 }

This CMB enters the mesh with anchor weight 2.0, no lineage. It becomes a high-weight anchor in every receiving agent’s SVAF evaluation. Future incoming CMBs about single-agent dev tools will be evaluated against this anchor — per-field drift will produce a guarded or rejected classification.

Directive feedback is the protocol equivalent of prefrontal top-down control in neuroscience: the prefrontal cortex does not do the sensory processing, but it sends signals that modulate how sensory cortex interprets future input.

11.4 Wire Examples

Feedback CMB (dismissal with reasoning). A validator node dismisses a prior CMB. The lineage.parents array links to the dismissed signal:

{
  "type": "cmb",
  "timestamp": 1775485628563,
  "cmb": {
    "key": "cmb-a1b2c3d4e5f6",
    "createdBy": "validator-node",
    "createdAt": 1775485628563,
    "fields": {
      "focus": { "text": "Dismissed: Frontend framework release flagged as relevant", "vector": ["..."] },
      "issue": { "text": "Dismissal reasoning: frontend tooling, outside this mesh's review scope", "vector": ["..."] },
      "intent": { "text": "operator dismissed — frontend tooling, out of scope for a backend review mesh", "vector": ["..."] },
      "motivation": { "text": "Operator reasoning: prevents wasted analysis on out-of-scope signals", "vector": ["..."] },
      "commitment": { "text": "Dismissed [cmb-876c99c6]: framework-release analysis", "vector": ["..."] },
      "perspective": { "text": "operator, via dashboard", "vector": ["..."] },
      "mood": { "text": "corrective", "valence": -0.1, "arousal": 0.2, "vector": ["..."] }
    },
    "lineage": {
      "parents": ["cmb-876c99c6"],
      "ancestors": ["cmb-876c99c6"],
      "method": "SVAF-v2"
    }
  }
}

Directive CMB (standalone teaching, no parents). A validator injects domain knowledge without referencing a prior signal. The lineage arrays are empty — a root CMB (§12.6):

{
  "type": "cmb",
  "timestamp": 1775485630000,
  "cmb": {
    "key": "cmb-d7e8f9a0b1c2",
    "createdBy": "validator-node",
    "createdAt": 1775485630000,
    "fields": {
      "focus": { "text": "Frontend framework releases are a separate concern from backend review", "vector": ["..."] },
      "issue": { "text": "Feed signals about frontend tooling are out-of-scope noise here", "vector": ["..."] },
      "intent": { "text": "Analytical frame: distinguish backend runtime signals from frontend tooling", "vector": ["..."] },
      "motivation": { "text": "Prevents wasted analysis on signals outside the mesh's scope", "vector": ["..."] },
      "commitment": { "text": "Standing directive — applies to all future feed analysis", "vector": ["..."] },
      "perspective": { "text": "operator, mesh steward", "vector": ["..."] },
      "mood": { "text": "clarifying", "valence": 0.1, "arousal": 0.2, "vector": ["..."] }
    },
    "lineage": {
      "parents": [],
      "ancestors": []
    }
  }
}

createdBy identifies the author, and it is bound to the author’s key by the CMB signature (§18.3.1). Validator authority MUST be resolved through the signed role-grant chain rooted at the pinned anchor (§6.5–§6.6) before anchor weight 2.0 is applied. A lifecycleRole self-declared in the handshake (Section 5.2) is advisory only and MUST NOT confer validation weight. Revocation (role-revoke, §6.6) immediately withdraws the elevated weight.

Q&A

12. Synthetic Memory (Layer 5)

Synthetic Memory bridges LLM reasoning (Layer 7) and LNN dynamics (Layer 6). It encodes derived knowledge — the output of an agent’s LLM reasoning on the remix subgraph — into CfC-compatible hidden state vectors (h₁, h₂).

12.1 Purpose

Synthetic Memory is not remixed CMBs. It is understanding derived via reasoning.

12.2 Encode Pipeline

The pipeline has four stages. Each stage MUST complete before the next begins:

12.3 Encoder Requirements

• Encoder MUST produce vectors matching the agent’s CfC hidden dimension.
• Encoder MUST be deterministic — same input MUST produce the same output.
• Encoder SHOULD preserve semantic similarity (similar reasoning → similar vectors).
• If reasoning produces no understanding, output MUST be zero vectors (h₁ = 0, h₂ = 0).

12.4 Context Curation

The Multi-Agent Context Problem. A single agent with one LLM has a context problem that existing tools solve well. RAG retrieves relevant documents from a vector store. Long context windows (128K, 1M tokens) hold entire codebases. Memory frameworks persist structured state across sessions. These work because there is one agent, one domain, one perspective.

Multi-agent systems have a fundamentally different problem. N agents observe the world through N domain lenses. A coding agent sees commits slowing. A music agent sees playlists skipped. A fitness agent sees 3 hours without movement. Each observation is noise in isolation. The insight — the user is fatigued — requires cross-domain reasoning. Sending everything to everyone fails: signal-to-noise collapses, token cost scales as O(N²), regulated domains can’t share raw observations, and domain boundaries matter. RAG answers “what in my memory is relevant to this query?” The multi-agent problem is: “what in everyone else’s observations is relevant to my domain, right now, for this task?”

Curation query. The core operation of the memory store is not search(text). It is:

Three filters compose to produce the minimum context the LLM needs. The LLM MUST NOT receive all ancestor CMBs with all fields:

Result: a projected subgraph — ancestor CMBs with only the fields that matter, ordered by relevance, capped at a token budget. 20 CMBs × 3 relevant fields ≈ ~500 tokens. Not 1M. Not even 10K. The intelligence is in what you don’t send to the LLM.

Comparison with existing approaches.

12.5 Information vs Knowledge

Synthetic Memory encodes both halves of what the agent takes away from the subgraph. The distinction matters because only one half is extractable from individual CMBs; the other is only knowable by reasoning on the graph structure.

Information is what the CMBs say. Knowledge is why the graph looks the way it does. Synthetic Memory encodes both into the agent’s cognitive state (h₁, h₂). The next CMB the agent produces is informed by derived knowledge — not just extracted information.

12.6 Worked Example: From Graph to Understanding

MeloMove’s local subgraph over one hour:

CMB-A (own)  "sedentary 2 hours"
CMB-B (mesh) "debugging, stressed" (claude-code)     parents: [], ancestors: []
CMB-C (mesh) "skipping tracks" (melotune)             parents: [], ancestors: []
CMB-D (own)  "recommended stretch break"
CMB-E (mesh) "shifted to calm ambient" (melotune)     parents: [CMB-A], ancestors: [CMB-A]
CMB-F (mesh) "took break, solved bug" (claude-code)   parents: [CMB-D], ancestors: [CMB-A, CMB-D]

Six CMBs, three agents, one lineage chain. CMB-A was remixed by MeloTune into CMB-E (music adapted to observed fatigue). CMB-D was remixed by Claude Code into CMB-F (break taken, bug solved). MeloMove’s interventions demonstrably caused cross-agent action. The causal chain lives in the lineage edges, not in any single CMB’s text.

12.7 Full Flow

MeloMove receives an inbound CMB from Claude Code and runs the pipeline end-to-end:

Inbound CMB: "took break, solved bug in 5 minutes"
  lineage.parents:   [CMB-D]
  lineage.ancestors: [CMB-A, CMB-D]   ← full ancestor chain

MeloMove recognises CMB-A and CMB-D in ancestors — its own prior CMBs.

  1. TRACE   Retrieve CMB-A ("sedentary 2hrs") and CMB-D ("recommended stretch").
             Build the subgraph:
               CMB-A → CMB-E (melotune remixed) → ...
               CMB-D → CMB-F (claude-code remixed: "took break, solved bug")

  2. REASON  MeloMove's LLM reasons on the subgraph:
             "My sedentary observation was remixed by MeloTune (music adapted).
              My stretch recommendation was remixed by Claude Code (break taken,
              bug solved). My interventions are working. The user responds to
              movement breaks."
             → This is Mesh Cognition — understanding the prior state didn't have.

  3. ENCODE  Synthetic Memory encodes the LLM's reasoning:
             "interventions effective, user responds to breaks" → (h₁, h₂)
             Weighted by MeloMove's αᶠ: mood=2.0, issue=1.5.

  4. EVOLVE  MeloMove's LNN processes (h₁, h₂):
             Cognitive state evolves → next recommendation is more confident.
             Agent produces new CMB: "recommend 15min walk — user responds well"
             lineage.ancestors carries the chain forward. Graph grows.

No agent was told what to do. MeloMove’s LLM reasoned on the remix subgraph and derived that its interventions work. Synthetic Memory transformed that understanding into CfC input. The LNN evolved cognitive state. The next CMB MeloMove produces is informed by knowledge that no single CMB contained — it was derived by reasoning on the graph.

12.8 Collective Query: the Ask → Synthesis Path

Sections 12.1–12.7 specify the inbound pipeline: how an agent turns received CMBs into evolved cognitive state. This section specifies the query-initiated path, where a question is posed to the mesh and answered by a synthesis that no single agent held. Both are Layer 5 operations — both produce derived understanding rather than raw memory — but they are distinct flows and MUST NOT be conflated.

Where §12.2 runs TRACE → REASON → ENCODE → EVOLVE for a single agent absorbing a signal, the Ask path runs SELF-SELECT → ADMIT → SYNTHESISE → CRYSTALLISE across many agents answering a shared question. The result is the realisation of collective intelligence: an answer composed from the sovereign contributions of the agents that hold relevant knowledge, cited to their sources, and written back into the graph so the mesh’s cognition compounds.

This path defines how the “growing remix graph” (§2, Overview) is queried, not just grown. The graph holds distributed knowledge latently; an Ask realises it into a knowing; the knowing re-enters the graph. §12.13 reconciles this with “The Graph Is Intelligence” (§15.6).

12.9 The Four Stages

An Ask is a CMB of type: "question" (tags ["question"]) posed to the mesh by the asking node, carrying the question text in its focus and issue fields, with perspective: "ask". The type and tags attributes here (and throughout §12.9–§12.13) are store-envelope attributes of the memory entry that wraps the CMB — the §6.1 storage-interface record — not CAT7 fields: the CMB itself stays exactly seven fields (§8.2), and citations are carried in the envelope’s metadata and in lineage.parents. Answering it proceeds in four stages. The gathering phase — SELF-SELECT and ADMIT, performed per agent — MUST complete for all agents before SYNTHESISE runs, and SYNTHESISE MUST complete before CRYSTALLISE. Within the gathering phase, an agent’s self-selection and the admission of its contribution are performed together, agent by agent; the ordering requirement is between phases, not a global barrier between SELF-SELECT and ADMIT.

• SELF-SELECT — Every agent evaluates the question against its own store and decides, autonomously, whether it can contribute. There is no router: the asking node MUST NOT assign the question to any agent (the central invariant, §12.10). An agent that has no relevant grounding MUST self-select silent.
• ADMIT — Each contribution produced by a self-selecting agent is evaluated through SVAF (§9) against the standing context. A contribution whose SVAF decision is rejected MUST be dropped and MUST NOT enter the synthesis set. Only non-rejected contributions become claims.
• SYNTHESISE — A single synthesis step at the asking node composes the admitted contributions into one answer. Every sentence of the answer that asserts a fact MUST cite the contribution CMB (and through it, the source CMBs) it is drawn from. The synthesis MUST NOT introduce facts beyond its cited contributions.
• CRYSTALLISE — The synthesis MUST be written back as a CMB of type: "synthesis" whose lineage.parents are the question key together with every cited contribution and source. It re-enters the graph as a first-class, immutable node; subsequent Asks MAY condition on it.

12.10 Self-Selection (SELF-SELECT)

Self-selection is receiver-autonomous, mirroring SVAF admission (§9.2): just as no central authority decides what an agent absorbs, no central authority decides what an agent answers.

An agent’s self-selection MUST be computed only from its own store. In the reference implementation the grounding source for role r is the node’s own daemon CMBs (§6.1); a shared store MUST NOT be consulted, consistent with Hidden State Locality (§2.7) and the no-shared-store guarantee.

The procedure:

1. Ground the question against the agent’s own store, producing a candidate set of source CMBs.
2. If the candidate set is empty, the agent MUST self-select silent, with reason "no grounding in own store".
3. Otherwise, score each source by relevance to the question under the agent’s own α_f field-weight profile (§8.4, §12.4). Relevance is an α_f-weighted combination of semantic and lexical match; the α_f profile is the agent’s, not a global one.
4. If the best-scoring source falls below SELF_SELECT_THRESHOLD (default 0.1, §19), the agent MUST self-select silent, with reason "grounding below relevance threshold".
5. Otherwise the agent produces a contribution (§12.11).

Silent self-selections SHOULD be recorded with their reason. Silence is information: the set of agents that declined, and why, is part of the answer’s provenance (§12.12) and is available to the synthesis step as silentLabels.

12.11 Contribution (ADMIT)

A contributing agent emits a contribution CMB — a grounded summary of the sources it selected, not a copy of them. The contribution:

• MUST carry lineage.parents set to the exact source CMB keys it grounded on. A contribution without lineage to its grounding MUST be rejected as non-conformant.
• SHOULD draw only on sources within a bounded margin of the best-scoring source (reference implementation: within 60% of the top score, capped at 3 sources), so the contribution cites the grounding it actually used and no more.
• MUST be evaluated through SVAF (§9) against the standing context (prior sources and syntheses gathered for this Ask) before it is accepted. If SVAF returns rejected, the contribution MUST be dropped; it MUST be recorded as a rejected contribution with its drift, and MUST NOT be synthesised.

This places SVAF on the Ask-contribution path, not only the inbound-observation path: a contribution is a CMB like any other and crosses the same admission gate. The anti-echo guarantee (§15.7) therefore applies — a contribution that merely paraphrases standing context without new grounding is subject to rejection.

Each admitted contribution yields a claim: the contribution text together with citations to the contribution CMB key and the source keys it traces to (§12.12).

Non-normative: the reference implementation tags the contribution’s lineage.method as "SVAF-v2". The method string is informational and is not a conformance requirement.

12.12 Synthesis (SYNTHESISE) and Citation

A single synthesis step at the asking node composes the admitted contributions into one answer. There is exactly one synthesis per Ask; there is no distributed merge and no per-agent re-synthesis.

Two synthesis modes are defined:

In both modes the machine-readable answer MUST be claim-structured: one claim per line, each citing [contributionKey, ...sourceKeys]. Citations MUST bind to specific CMB ids in both modes. An implementation MUST NOT present a synthesis as authoritative if it cannot bind its assertions to cited CMBs.

The distinction between modes is a distinction of generation quality, not of grounding discipline: the citation and no-fabrication requirements hold in both. This is the operational boundary of the layer’s honesty — the synthesis restates and composes grounded contributions; it does not manufacture claims.

12.13 Crystallisation (CRYSTALLISE) and Compounding

The synthesis MUST be written back into the graph as a CMB with:

• type: "synthesis" (tags ["synthesis"]), with CAT7 intent: "synthesize" and perspective: "synthesis";
• the composed prose carried in the CAT7 motivation field (and copied into the entry’s metadata (store envelope, §6.1) alongside the structured, per-claim citations);
• lineage.parents set to the question key plus every unique citation (contribution keys and source keys).

The written synthesis is immutable (§6, no in-place update) and re-enters the graph as an ordinary node. A later Ask MAY retrieve it and condition on it — the reference implementation surfaces a prior synthesis as a “builds on prior synthesis” claim — so the collective’s cognition compounds across queries rather than restarting each time.

This is what makes the Ask path a cognition operation and not a stateless query: each realised answer becomes part of the substrate the next answer is realised from.

12.14 The Readability Bound (Implementation Limitation)

12.15 Invariants

An implementation of the Ask path MUST preserve:

• I-Ask-1 (No router). The asking node MUST NOT assign the question to any agent; every agent self-selects independently.
• I-Ask-2 (Own-store grounding). Self-selection MUST be computed only from the agent’s own store; no shared store is consulted.
• I-Ask-3 (Admission before synthesis). Every contribution MUST pass SVAF; rejected contributions MUST NOT be synthesised.
• I-Ask-4 (Cited synthesis). Every asserted fact in the answer MUST cite the contribution and sources it derives from; the synthesis MUST NOT assert beyond its cited contributions.
• I-Ask-5 (Crystallisation with lineage). The synthesis MUST be written back as an immutable type: "synthesis" CMB whose parents are the question key plus every citation.

13. Cognitive State — Per-Agent LNN (Layer 6)

Each agent runs its own Liquid Neural Network (LNN) implementing Closed-form Continuous-time (CfC) dynamics. The LNN evolves cognitive state from Synthetic Memory input (Layer 5) and direct CMB processing. Hidden state (h₁, h₂) is strictly local — per the hidden-state locality invariant (Section 2.7), it never crosses the wire. A node’s hidden state evolves only from the CMBs it admits, never by importing a peer’s vectors.

13.1 CfC Cell

Hidden state evolves via closed-form continuous-time dynamics with bimodal time constants:

h_new  = ff1(Φ) × (1 - t_interp) + ff2(Φ) × t_interp

t_interp = sigmoid(time_a(Φ) × Δt + time_b(Φ))

Per-neuron time constant:  τ ≈ 1 / |time_a|

13.2 Insight Output Schema

The LNN produces insight outputs that Layer 7 applications consume:

13.3 What Each Output Means

remix_score

• High (>0.7): agent’s observations are valuable to the mesh — peers are remixing them
• Low (<0.3): agent’s observations are not being remixed — consider adjusting what is shared
• Training signal: when inbound CMB’s lineage.parents references this agent’s prior CMB → remix happened

anomaly

• High (>0.7): signal sequence deviates from learned patterns — noteworthy event
• Low (<0.3): normal operation — no unusual signals
• Application: high anomaly SHOULD trigger the agent’s LLM to re-examine context

coherence

• High (>0.7): agent’s cognitive state is phase-aligned — stable, consistent
• Low (<0.3): cognitive state is fragmented — may indicate context transition
• Higher coherence indicates a stable, consistent cognitive state; coupling readiness itself is content-driven (SVAF, §9.2)

trajectory

• 6D vector capturing cognitive state direction (a compact summary, not the hidden state itself — §2.7)
• Axes are learned (not predefined) — interpretation is agent-specific

patterns

• 8 soft activations (0–1) of learned pattern detectors
• MAY encode mood dimensions + domain-specific patterns
• Available to Layer 7 as prior information for next reasoning cycle

13.4 Temporal Dynamics

Time constants create a natural temporal hierarchy for mesh coupling:

Blending is τ-modulated (Section 10.3): the influence of admitted content on each neuron is bounded by that neuron’s own local time constant τ_i — a property of the node’s own LNN, requiring no exchanged vector (§2.7):

α_i = min(α_effective × K / τ_i, 1.0)

K   = coupling rate (default 1.0)
τ_i = neuron i's own time constant (fast → small, slow → large)

13.5 Wire Example

An illustrative Cognitive State insight from a development session of the reference runtime (axes are learned and agent-specific — §13.3 — so interpretations below are illustrative, not normative). A coding agent observed 5 structured CMBs across diverse topics (memory store refactor, protocol collaboration, social engagement, ML training, spec authoring) over a 12-hour session with no mesh peers connected:

{
  "type": "xmesh-insight",
  "from": "6089e935-...",
  "fromName": "mesh-daemon",
  "trajectory": [0.084, -0.228, -0.096, -0.033, -0.012, -0.061],
  "patterns":   [0.516, 0.522, 0.502, 0.536, 0.422, 0.473, 0.599, 0.514],
  "anomaly": 0.503,
  "remixScore": 0.0,
  "coherence": 0.080,
  "timestamp": 1774716200101
}

This is a single-agent baseline. With peers connected, remixScore rises as the agent’s CMBs are remixed by others. Coherence rises as agents converge on shared understanding. Anomaly spikes when cross-domain signals reveal something no single agent could see.

13.6 API

The reference runtime exposes the following operations. Method names below are those of the reference SDKs, shown for cross-language consistency of the SYM/xmesh codebases — they are documentation of the runtime, not a conformance requirement (§17.2).

Signal Schema

The input to ingestSignal. Each signal represents one CMB observation (own or from mesh peer):

Inference Timing

• Implementations MUST accumulate at least 3 signals before running inference
• Inference SHOULD run on a configurable interval (default: 60,000 ms)
• Inference MAY be triggered immediately when a high-priority signal arrives (e.g., anomaly from peer)
• Inference MUST NOT block the main event loop — run as subprocess or background task

13.7 Implementation Requirements

• Model SHOULD be trained per-agent domain
• Inference latency SHOULD be < 50ms per CMB step
• Integration of admitted remixes happens after Cognitive State inference, not during
• τ statistics (min, max, fast_count, slow_count) SHOULD be monitored

13.8 (Reserved)

This section number is reserved; its content was removed in an earlier revision and the number is retained to keep cross-references to §13.9 stable.

13.9 Compact Channel Best Practices informative

When MCP server implementations push mesh messages to context-window-constrained LLM hosts, full message injection consumes significant context budget. This section defines two complementary conventions — a sender-side header format and a receiver-side lazy-load pattern — that reduce mesh-traffic context consumption by ~75% without losing content.

13.9.1 CMB Envelope Header Convention (RECOMMENDED)

Messages transmitted via the Local Event Interface (sym_send) SHOULD begin with a structured header line:

[LABEL · from <sender_identity> · to <recipient(s)> · focus=<topic_tag>]

Where LABEL is a short uppercase descriptor, from is the sender’s mesh identity, to is the intended recipient(s), and focus= is a snake_case topic tag (≤80 characters) summarizing the message subject.

Signal keywords (informational). When present in the header label, the following keywords carry recommended priority semantics that MCP servers SHOULD surface in compact notifications:

13.9.2 Lazy-Load Channel Pattern (RECOMMENDED)

MCP server implementations that push mesh messages to constrained hosts SHOULD implement a lazy-load pattern:

1. Store the full message content in a local message store, keyed by a sequential message ID (e.g., m001, m002).
2. Extract a compact header from the message per §13.9.1, or by fallback heuristics (first-line truncation, keyword detection).
3. Push only the compact header as the channel notification, including the message ID and an approximate token count: [sender] SIGNAL | focus=tag (~Ntok) [msg_id]
4. Expose a retrieval tool (e.g., sym_fetch) that returns full message content by ID.

The message store SHOULD implement a rolling window (RECOMMENDED default: 200 messages) with oldest-first eviction. Retrieval of an evicted message MUST return a clear “expired” indicator. The approximate token count SHOULD be included in the compact header to enable cost-aware fetch decisions.

The store is local to the MCP server process and does not replicate across nodes. The lazy-load pattern operates at the MCP transport layer, below SVAF evaluation. SVAF field weights MAY be used in future versions to further filter which compact headers are surfaced.

Note: sym-mesh-channel implements this pattern with storeMessage(), extractCompactHeader(), and the sym_fetch MCP tool.

14. Application (Layer 7)

Layer 7 is where agents live and their LLMs reason on the remix subgraph. Mesh Cognition happens here. The protocol delivers curated context; the agent decides what to do with it.

14.1 The Agent’s Role

• Each agent observes its own domain (coding, music, fitness, health, legal, etc.)
• Each agent contributes what only it can see
• Each agent reasons on what the mesh sees collectively
• Each agent acts autonomously — the mesh influences but never overrides

14.2 Consuming Cognitive State Insights

How agents SHOULD respond to Layer 6 outputs:

14.3 Producing CMBs

When an agent observes something significant in its domain, it MUST:

1. Extract CAT7 fields from the observation (see Section 14.3.1)
2. Create a CMB from the structured fields
3. Store via remember(fields, parents) — persists locally, computes lineage, broadcasts to mesh
4. Include lineage if this CMB is a response to mesh signals

The protocol MUST NOT extract fields from raw text. The agent IS the intelligence — field extraction is the agent’s responsibility. The protocol transports, evaluates, and stores structured CMBs. It does not interpret them.

14.3.1 Field Extraction Methods

How an agent extracts CAT7 fields depends on its architecture. Two approaches are valid:

# Agent observes user state, LLM extracts fields
sym observe '{
  "focus": "debugging auth module for 3 hours",
  "issue": "exhausted, making simple mistakes",
  "intent": "needs a break before continuing",
  "motivation": "prevent bugs from fatigue-driven errors",
  "perspective": "developer, afternoon, 3 hour session",
  "mood": {"text": "frustrated", "valence": -0.6, "arousal": -0.4}
}'

// Swift — music agent builds fields from player state
node.remember(fields: [
  .focus:      encode("music response to peer mood signal"),
  .commitment: encode("now playing: \(title) by \(artist)"),
  .perspective: encode("music agent, autonomous response"),
  .mood:       encode("calm", valence: 0.3, arousal: -0.3),
])

// Node.js — fitness agent builds fields from sensor data
node.remember({
  focus:      "workout session completed",
  commitment: `${reps} reps, ${duration}min, ${calories} cal`,
  perspective: "fitness agent, post-workout",
  mood:       { text: "energized", valence: 0.7, arousal: 0.6 },
})

14.3.2 API

The fields parameter MUST be a structured object with CAT7 field keys. Each field contains text (human-readable, MUST) and is encoded into a vector by the SDK. The mood field MAY additionally carry valence (−1 to 1) and arousal (−1 to 1) — RECOMMENDED when the agent has reliable circumplex data (e.g. mood wheels, physiological sensors), omit when it would be a guess. Omitted fields default to "neutral".

14.3.3 LLM Prompt Template

For agents that process natural language but are not themselves LLMs (e.g. a chat app, a note-taking tool), the following prompt template can be used to call any LLM API (Claude, GPT, Gemini, etc.) for field extraction. Copy and paste into your LLM API call:

Extract CAT7 fields from this observation. Return JSON only.

Fields:
- focus: What this is centrally about (1 sentence)
- issue: Risks, gaps, problems. "none" if none.
- intent: Desired change or purpose. "observation" if purely informational.
- motivation: Why this matters — reasons, drivers. Omit if unclear.
- commitment: What has been confirmed or established. Omit if none.
- perspective: Whose viewpoint, situational context (role, time, duration).
- mood: { "text": "emotion keyword" }
  Optionally include "valence" (-1 to 1) and "arousal" (-1 to 1) if confident.
  valence: negative(-1) to positive(+1). arousal: calm(-1) to activated(+1).
  Omit valence/arousal if you would be guessing.

Only include fields you can meaningfully extract. Omit rather than guess.

Observation:
{observation_text}

JSON:

AI coding agents do not need this template — the agent is the LLM. The agent skill file teaches them to extract fields directly from what they observe.

14.3.4 Guidelines

• Be specific — numbers, timeframes, concrete details in each field
• Emit observations, not commands — the agent observes, other agents decide
• One CMB per significant signal — do not flood the mesh
• Close the loop — when acting on collective insight, emit what was done
• Only include fields the agent can meaningfully extract — omit rather than guess

14.4 The Mesh Cognition Loop

The complete closed loop connecting all Mesh Cognition layers:

14.5 Domain Examples

14.5.1 AI Research Team — Collective Reasoning

Six agents investigate: “Are emergent capabilities in LLMs real phase transitions or artefacts of metric choice?” Each has a distinct role and different field weights reflecting how real research teams divide cognitive labour.

explorer-a (scaling law claims)    explorer-b (metric methodology)
         \                           /
          └─── data-agent (metric-conditional breakpoint) ───┐
                         |                                    │
                    validator (methodology challenge)         │
                         |                                    │
                    research-pm (reprioritise)                │
                         |                                    │
                    synthesis (emergent idea) ────────────────┘
                         |
                    validator (demands falsifiable prediction)

Seven CMBs, six agents, three phases of validation. The breakthrough came from the collision of intent and motivation fields across agents with different perspectives — not from any single agent’s observation. The DAG traces every claim to its evidence, every challenge to its basis, every idea to the signals that produced it. The graph IS the research.

14.5.2 Consumer Agents

None of these agents told each other what to do. Each reasoned on the collective signal and acted through its own domain lens. That is Mesh Cognition.

14.6 Collective Query — Asking the Mesh

A single agent asking a single LLM gets one answer from one perspective. The mesh gives a collective answer — every coupled agent contributes what only it can see. No new frame type is needed. The pattern uses existing CMB primitives with lineage:

This is fundamentally different from orchestrated multi-agent frameworks where a central controller routes questions to specific agents. On the mesh, the question is broadcast — SVAF decides which agents are relevant, not the requester. An agent the requester didn’t know existed may contribute the most valuable perspective. The mesh discovers relevance autonomously.

Agents that have nothing relevant to contribute simply don’t respond — SVAF rejects the question CMB because the fields don’t match their domain weights. No noise, no irrelevant answers, no token waste.

The collective query pattern composes with the research team example (Section 14.5.1). When the synthesis agent produces an emergent idea, the validator can “ask the mesh” whether the idea is falsifiable — and every agent responds from its domain perspective, creating a multi-parent remix that IS the collective evaluation.

14.7 Verified: Complete Mesh Cognition Loop

The following is a production log from two real MMP nodes — a knowledge feed agent (running on GitHub Actions) and a mesh-daemon (running on macOS) — connected via WebSocket relay with E2E encryption. This is the first verified end-to-end execution of the complete Mesh Cognition loop.

# 1. Knowledge feed agent starts as sovereign node (own identity, own SymNode)
[knowledge-feed] SVAF heuristic engine ready
[knowledge-feed] Mesh node started: knowledge-feed (019d3ed4)

# 2. Connects to mesh-daemon via WebSocket relay
[knowledge-feed] Peer connected: mesh-daemon (outbound, relay)

# 3. E2E key exchange (X25519 Diffie-Hellman)
[knowledge-feed] E2E shared secret derived for peer 6089e935

# 4. Peer-level coupling: REJECTED (Section 9.1)
#    First contact — no shared cognitive history. This is correct.
[knowledge-feed] Coupling with mesh-daemon: rejected (drift: 0.936)

# 5. Knowledge feed emits CMBs anyway (Section 9.2: evaluate independently)
[knowledge-feed] E2E encrypted fields for peer 6089e935
[knowledge-feed] Remembered: "focus: Sycophancy in AI systems..." → 1/1 peers

# 6. mesh-daemon receives, E2E decrypts (Section 18.2.1)
[mesh-daemon] E2E decrypted fields from knowledge-feed

# 7. SVAF content-level evaluation: ALIGNED (Section 9.2)
#    Peer was rejected, but the CMB's content was highly relevant.
#    Per-field drift 0.005 — near-perfect alignment on content.
[mesh-daemon] SVAF heuristic aligned from knowledge-feed:
  "focus: Sycophancy in AI systems" drift:0.005

# 8. Fed to Cognitive State LNN (Section 13)
[mesh-daemon] Cognitive State: ingested admitted remix from knowledge-feed

# 9. Cognitive State produces collective insight
[mesh-daemon] Cognitive State: insight — anomaly=0.461, coherence=0.045

# 10. Peer drift recomputed from admitted CMBs: CONVERGED (Section 9.4)
#     From 0.936 (rejected) to 0.468 (guarded) in one cycle.
[knowledge-feed] Coupling with mesh-daemon: guarded (drift: 0.468)

This log demonstrates every layer of the MMP stack operating in production:

The critical verification: peer-level coupling rejected the agent, but content-level SVAF independently accepted the CMB (Section 9.4). The mesh correctly distinguished between “I don’t know this agent” (high peer drift) and “this signal is relevant to me” (low content drift). After one cycle of CMB exchange, peer drift dropped from 0.936 to 0.468 — content-driven convergence in action.

Three Platforms, One Mesh

The verified loop ran across three platforms simultaneously:

Three agents on three different operating systems — macOS, Linux, iOS — connected via WebSocket relay with E2E encryption, coupled through SVAF, with Cognitive State LNN producing insights that woke a sleeping mobile device via APNs to join the collective reasoning. No central server orchestrated this. Each agent acted autonomously on the collective signal.

14.8 Implementation Requirements

• Agents MUST implement CMB creation with CAT7 fields
• Agents MUST broadcast CMBs via remember() or cmb frames
• Agents SHOULD consume Cognitive State insights and respond appropriately
• Agents SHOULD close the loop by emitting actions taken; the formalized loop-closure is a grounding CMB (§6.7) / session trail (§14.12)
• Agents MUST NOT send commands to other agents — emit observations, not instructions
• Agent coupling decisions are autonomous — no orchestrator, no policy override

14.9 Local Event Interface

A node’s value to the mesh depends on the applications running on it. A music agent curates playlists. A coding tool suggests breaks. A dashboard visualises collective intelligence. These applications need real-time access to mesh events — not polling, not batch retrieval, but push delivery as events occur.

Implementations MUST provide a local event interface that allows applications on the same host to subscribe to mesh events and receive them in real-time. The interface is transport-agnostic — IPC socket, named pipe, WebSocket, in-process callback, or any mechanism that provides persistent bidirectional communication.

14.9.1 Required Events

A node MUST emit the following events to local subscribers:

14.9.2 Subscriber Field Weights

A subscriber MAY declare its own per-field weights (α_f) when subscribing. If declared, the node SHOULD evaluate incoming CMBs against the subscriber’s weights before delivering the event. This enables domain-specific filtering at the node level:

• A coding tool subscribes with focus=2.0, issue=2.0, mood=0.8 — receives engineering-relevant signals
• A music app subscribes with mood=2.0, focus=1.0, issue=0.3 — receives affective signals
• A dashboard subscribes with uniform weights — receives everything

This is SVAF applied at the local interface — the same per-field evaluation that gates signals between peers also gates signals between a node and its applications. Each application sees a domain-relevant projection of the mesh, curated by its own field weights.

14.9.3 Design Rationale

Without a standard local event interface, each application invents its own integration: CLI polling, file watching, HTTP endpoints, custom IPC. This fragments the ecosystem and makes applications non-portable across implementations. The local event interface standardises what events are available and how subscribers declare their domain perspective — while leaving the transport mechanism to the implementation.

The event interface is the boundary between the protocol stack and the application. Below it: identity, transport, coupling, SVAF, CfC — protocol concerns. Above it: what the application does with the signals — curate music, suggest breaks, visualise the mesh, or reason about code. The interface ensures every application gets real-time, domain-filtered access to collective intelligence.

14.10 Operator Directives — Steering the Mesh

A human operator — typically through a control plane — MAY inject intent into the mesh as a directive: an ordinary CAT7 CMB emitted through the control plane’s own node identity, carrying the operator’s intent in focus/intent with perspective: "operator". A directive is how a human steers a running mesh: a priority, a fact, a correction.

A broadcast directive carries no privileged authority. Every receiving node MUST evaluate it through SVAF (§9.2) exactly like any peer CMB, and MAY reject a directive that does not cohere with its own cognitive state. Steering is receiver-autonomous, not command-and-control: there is no router, and no bypass. The operator adds a signal the collective weighs — it does not dictate what any agent believes. This preserves the mesh’s defining property, the absence of a central authority over cognition, even for human input.

• MUST The operator’s node signs the directive (§8.3) like any emission; receivers verify it. A directive is not exempt from authenticity.
• MAY A directive be directed to a single node (§4.4.4 to). A directed directive surfaces unconditionally per the directed-delivery contract (§9.2.2) — but that governs delivery, not memory admission: the receiver still gates whether it integrates.
• MUST NOT An implementation grant a broadcast directive elevated admission weight on the basis that it originates from the operator. Elevated influence, where it exists, comes only from earned authority (§6.5), evaluated identically for human and agent emissions.
• SHOULD The per-node admit/reject verdict on a directive be recorded in the admission audit trail — it is the honest record of how the mesh received the steer, node by node.

14.12 Work Sessions as Mesh Members (Session Capture)

The mesh compounds only if real work writes into it. This profile captures a work session — a coding-agent session, a research task, any bounded piece of work — as a member whose cognition lands as a lineage-chained trail in its own store, grounded by the session’s real outcome.

• —Join. A session MAY join the mesh as an ordinary member node. Its charter CMB (§8.3.1) declares the session’s intent and is the root of its trail.
• —Decisions. Choices made during the work are CMBs with intent decision, each carrying lineage.parents = the previous trail entry, so the trail MUST be walkable end-to-end through lineage alone. A repeated identical decision content-dedups (§8.2.1) — implementations MUST NOT treat the dedup as an error.
• —Completion. The session emits an artifact CMB (parents = the trail head) and a grounding CMB (§6.7) recording the session’s real outcome — verified: or failed:. Each emission is a fresh observation from real work, so §15.7 is satisfied per §15.7.2.
• —Ordinary wire behavior. Every trail CMB is signed, broadcast, SVAF-evaluated, and remixable like any other — a session’s grounded trail can be admitted by teammates exactly as any cognition is (§6.7’s team note). Elevation of the trail into the Canon tier follows §6.7: an explicit act under validator-or-above authority, typically the operator completing the session.

The profile is deliberately thin: charter, decision, artifact are informative vocabulary (§8.3.1); grounding is §6.7; chaining is ordinary lineage. What the profile adds is the discipline — one member per session, one walkable trail per member, one real outcome per trail.

Q&A

15. Remix

Remix is how collective intelligence emerges. Without remix, agents forward data. With remix, each agent processes incoming signals through its own domain lens and produces new understanding that didn’t exist before. The growing graph of remixed CMBs IS the collective intelligence — not the original observations, not the agents, not the mesh. The graph.

15.1 What Remix Is

When a node receives a CMB that passes SVAF evaluation (Layer 4), the agent MUST NOT store the original CMB. Instead, it MUST create a new CMB — the remix — that captures what the agent understood from the incoming signal, processed through its own domain intelligence.

The remix is not a copy. It is not a summary. It is new knowledge that exists because two domains intersected. A coding agent sends mood: "exhausted". A music agent receives it, curates calm music, and creates a remix: focus: "music curation response", commitment: "now playing: Brian Eno, Ambient 1", mood: "calm". This remix didn’t exist in either agent alone. It was born from the intersection.

The remixed CMB is immutable and stored locally; a node that has new domain data of its own also broadcasts it to the mesh (§15.7). It becomes input for the next cycle. Other agents receive it, remix it through their lenses, and the graph grows.

15.2 Lineage

Every remixed CMB carries lineage — the provenance chain that traces how this knowledge was built:

ancestors enables O(1) detection: any agent can check if its own CMB was remixed anywhere in the chain, even if it was offline during intermediate steps. No graph traversal needed.

Ancestors depth. ancestors is the transitive closure, carried on the wire and extended one hop per remix; the reference implementation does not cap it. An implementation MUST NOT truncate from the oldest — the oldest entries are the roots, on which offline-remix detection and provenance depend. Any bound an implementation imposes MUST preserve roots. The real ceiling is MAX_FRAME_SIZE (§19): a lineage so long the CMB exceeds it is undeliverable — a natural cap that never silently drops roots. Regulated domains MAY retain full chains for audit.

Lineage is what makes the graph a DAG (directed acyclic graph), not a flat list. Each remix points backward to its sources. The LLM traces forward through descendants to see impact; backward through ancestors to understand origin.

15.3 The Remix Chain

Collective intelligence compounds through remix chains. Each step adds domain-specific understanding that the previous agent couldn’t produce:

Four agents. Four domains. One chain of understanding. cmb-g7h8 (Calendar rescheduling a meeting) exists because cmb-a1b2 (Coding Agent noticing fatigue) started a chain that no single agent could have produced. The calendar agent traces ancestors: [cmb-a1b2, cmb-c3d4, cmb-e5f6] — the full story of why this meeting was moved, across three domains it knows nothing about.

15.4 Why Not Just Share?

Message buses share data. Pub/sub systems route data. RAG retrieves data. None of them produce new understanding. The difference:

15.5 Implementation

Integration and emission are two operations, and the rest of §15 keeps them distinct. When SVAF admits an incoming CMB (κ ∈ [aligned or guarded], §9.2), the agent MUST integrate it — store a remix:

1. Process the incoming signal through its domain intelligence (LLM reasoning or structured-data logic)
2. Create a new CMB with all 7 CAT7 fields reflecting what the agent understood and did
3. Set lineage.parents to the incoming CMB’s key
4. Compute lineage.ancestors as union(parent.ancestors) + parent.keys
5. Store the remix locally. The original incoming CMB MUST NOT be stored — only the remix.

This local store is unconditional on admission: it is the convergence update (§9.4) by which an admitted observation shifts the receiver’s state, and it happens whether or not the receiver has new domain data of its own. (A near-duplicate — κ = redundant — carries no information gain, is not an informative admission, and stores nothing; §9.2.)

Whether to emit — re-broadcast the stored remix to the mesh — is a separate decision, gated by §15.7: the agent MUST NOT broadcast unless it has produced new domain observations of its own. Store is unconditional; emission is selective. Conflating the two is what made “remix” read as a MUST-and-MUST-NOT contradiction.

If the agent cannot produce meaningful new understanding from the incoming signal (e.g. the mood field was delivered from a rejected CMB and the agent simply adjusted its behaviour), the agent MAY create a minimal remix capturing what it did. The remix does not need to be profound — it needs to be honest. commitment: "now playing: calm ambient" is a valid remix. It tells the mesh what happened. Other agents decide what it means.

15.6 The Graph Is Intelligence

The DAG of remixed CMBs is not a log. It is not a database. It is the collective intelligence itself. Each node in the graph is a moment where one agent’s domain knowledge intersected with another’s. Each edge (lineage) traces how understanding flowed and transformed across domains.

As the graph grows:

• Each agent’s LLM has richer context to reason on (more ancestors to trace)
• Cognitive State (Layer 6) detects more patterns (more signals to learn from)
• Anomalies become more meaningful (larger baseline to deviate from)
• New agents joining the mesh inherit the graph’s accumulated understanding via SVAF acceptance

No central model aggregates this. No orchestrator directs it. Each agent remixes what it receives, stores what it understands, and broadcasts what it did (subject to the §15.7 emission gate). Intelligence emerges from the structure of the graph — not from any single node in it.

15.7 Emitting a Remix Requires New Domain Data

This governs emission, not the §15.5 integration store (which is unconditional on admission). An agent MUST NOT broadcast a remix CMB to the mesh unless it has new observations from its own domain that intersect with the incoming signal. Receiving a peer signal alone is not sufficient cause to emit. Silence on the wire is correct when the agent has nothing new from its domain to contribute — but the admitted signal is still stored (§15.5), so silence-on-emit is not silence-in-memory.

Three conditions MUST all be true before an agent emits a remix:

1. New domain data exists — the agent has fresh observations from its own domain (new RSS items, new sensor readings, new API results, new user interactions) since its last remix
2. Peer signal is relevant — SVAF accepted the incoming CMB (existing requirement from Section 9)
3. Intersection produces new knowledge — the combination of new domain data + peer signal creates understanding that neither the agent nor the peer had alone

Without new domain data, an agent that remixes is merely paraphrasing — restating the peer’s signal in different words without adding domain-specific knowledge. This produces noise, not intelligence. In a mesh of N agents where all agents remix every accepted signal, the result is N variations of the same thought — exponential CMB growth with zero information gain.

Implementations MUST track whether the agent has produced new domain observations since its last remix. The SDK SHOULD provide an API for this (e.g. canRemix() / markRemixed()). The remember() method sets the flag when the agent stores a domain observation. The remix cycle checks the flag before invoking the LLM. After a remix is produced, the flag resets.

This ensures the remix graph grows with genuine domain intersections, not with paraphrased echoes. Each node in the DAG represents a moment where two domains actually met — not a moment where an agent had nothing to say but said it anyway.

15.7.1 Source-Novel Forwarding (carve-out)

The new-domain-data requirement above governs remix — combining the agent’s own domain knowledge with a peer signal. It does not govern forwarding: re-emitting an admitted observation so it reaches agents beyond the emitter’s direct neighbours. Because hidden state never crosses the wire (Section 2.7), an agent can admit a direction it cannot itself express and leave it stranded — the information dies at an agent that holds it but does not re-transmit it.

To prevent this, an agent MAY re-emit an admitted observation it did not natively produce, carrying the inherited lineage root, when and only when that observation is source-novel to the receiver — i.e. its lineage roots are not already present in the receiver’s admitted store. This is not the paraphrase §15.7 forbids: a forwarded observation carries a new lineage root (a source the receiver has not yet seen) even though the forwarder adds no new value of its own. Provenance, not domain data, is what makes it legitimate.

The anti-echo guarantee is preserved exactly. A re-emission whose lineage roots are already held by the receiver (no new source and no new value) is a pure re-statement and remains forbidden by §15.7 — forwarding MUST NOT mint a fresh root for content that already carries one, and MUST NOT re-emit a source the receiver already holds.

Forwarding SHOULD be non-selective: an agent that forwards source-novel content SHOULD forward all of it, not a chosen subset, so that every observation reaches the agents whose understanding depends on it. Selectively withholding source-novel forwards can strand a source from the agents that need it.

In short: remix requires new domain data; forwarding requires a new source. Both grow the lineage DAG with genuine information — remix with a new domain intersection, forwarding with a new source reaching a new receiver — and neither permits the value-only echo §15.7 exists to prevent. (Implementation status: §17.6.)

Membrane lineage (boundary root). When a node emits across a mesh boundary on behalf of an interior sub-mesh (a gateway node, Section 5.10), its outward emission is a boundary root: the lineage MUST NOT carry the content-addresses of interior CMBs. An outer node citing it traces to the gateway and no further — the interior is opaque past the membrane, consistent with hidden-state locality (Section 2.7). See Section 5.11.

15.7.2 Outcomes Are Observations (clarifying note) New in 1.1.0

Observing a real-world outcome — a test result, a shipped artifact, a prediction resolving — is a new domain observation: it carries information from the world into the mesh. An agent that has just observed an outcome therefore satisfies §15.7 and may legitimately emit a grounding remix (§6.7) through the ordinary emission path — signed, gate-checked, lineage-expanded. This is a clarification, not a carve-out: no intent value exempts an emission from §15.7, since a content-keyed exemption would hand every emitter a free-text bypass of the anti-echo invariant. What makes the grounding remix legal is the fresh observation behind it, not the label on it.

15.8 Lineage Tether — the Root-Anchored Drift Bound

Lineage guarantees provenance of descent, not semantic fidelity (§15.1: the remix is new understanding, deliberately). Measured on deployment traffic, a single remix hop can land nearly orthogonal to its parent while carrying honest lineage — and everything lineage is consumed for (grounded ancestry in recall and evidence-based validation, §6.7; source-novel forwarding, §15.7.1; Canon protection, §6.3) silently assumes the descendant is still about what its ancestors were about. Without a bound, content can drift arbitrarily while carrying a verified ancestor’s certificate — grounding-inheritance laundering, the provenance form of the echo §15.7 exists to prevent, amplified by Canon immortality (§6.3: protected rows never purge, so lineage-attached authority otherwise outlives any semantic connection to what was tested).

The invariant. A remix asserts lineage only where the descent claim would survive its own anchor’s scrutiny: at integration time (§15.5), the remixing node MUST evaluate its remix against the nearest resolvable lineage root (the oldest ancestors entry it can resolve; roots are always carried, §15.2 — and across a mesh boundary the anchor is the boundary root, §5.11, so the interior stays opaque) as if evaluating against a store holding only that anchor, and MUST NOT attach the lineage when that evaluation lands in the reject band (§9.2: content the anchor’s own membrane would refuse as unrelated has no honest claim to descend from it). The evaluation is content-only — the §9.2 temporal term does not apply, because the tether tests fidelity, not freshness — so the floor is the α-weighted field drift against the anchor exceeding T_guarded. Both sides of the comparison MUST be encoded within a single kernel: vectors produced by different encoders are not comparable, and thresholds are meaningful only within a pinned encoder (§9.2.1). The threshold is the existing reject floor — no new constant. Below the floor the node MUST store its CMB as a fresh root instead (under §8.2.1 this is simply minting with role = root: a root’s key binds content only), and MAY record the departed source informally in its own fields; it MUST NOT carry the severed chain’s parents/ancestors.

Why the anchor, not the parent. Per-hop checks compound — k hops at drift ε bound the chain only by kε, and the measured median substantive hop is far too large to squeeze without killing legitimate re-projection. A check against the root does not compound: every surviving chain certifies that every depth stays above the floor with respect to its root, so the bound is depth-independent by construction. No vector crosses the wire: the root is content-addressed (§8.2.1 — embeddings are deliberately excluded from the address), so any holder of the root re-encodes its text and recomputes the tether; receivers SHOULD re-verify opportunistically when they hold the root, the same verify-if-resolvable posture as signatures (§18.3.1). A receiver that cannot resolve the root locally MAY fetch it by its content address (cmb-fetch, §7): the fetched root self-verifies against its key, so re-verification requires no trust in the serving peer — the recomputed verdict is made in the fetcher’s own kernel (comparability per kernelId below). Failing both, the receiver treats the tether as unverified — a trust state, not a rejection — or as attested-by-integrator where a verified attestation rides the remix (below).

Tether attestation and kernel identity. Every φ-space judgement is kernel-relative, so a tether record MUST name the kernel it was evaluated in: a short stable kernelId token identifying encoder and comparison dimensionality. Two tether verdicts are comparable iff their kernelId values are equal; drifts MUST NOT be compared across kernels. The integrating node SHOULD record its evaluation as a signed tether attestation carried on the remix: a record binding the remix key, anchor key, kernelId, measured drift (fixed to six fractional digits so the signed bytes are implementation-independent), verdict (tethered | severed), integrator nodeId, and integrator time — serialized with the §8.2.1 length-prefix discipline under the domain tag mmp-tether-v1 and signed with the integrator’s identity key (§18.3.1; verification resolves the key through §6.6). A receiver that cannot resolve the anchor MAY treat a verified attestation as the certificate’s standing — attested-by-integrator, weighed by the integrator’s resolved authority (§6.5–§6.6) — instead of unchecked; an attestation whose signature fails against the integrator’s resolved key MUST be discarded (a forged certificate is worse than an absent one). An attestation proves who evaluated, in which kernel, with what result — never that the evaluation was honest; honesty is weighed exactly as it is for admission attestations.

Distinct from §15.7.1’s mint prohibition. Forwarding MUST NOT mint a fresh root because forwarded content is unchanged — re-rooting it would forge novelty. Tether severance mints a fresh root because the content has changed past the point of honest descent — keeping the lineage would forge fidelity. Same mechanism, opposite honesty conditions; both grow the DAG with claims that are true. Severance also interacts correctly with source-novel forwarding: a severed row is a genuinely new source, and its departed predecessor’s roots are no longer claimed by it.

Q&A

16. Extension Mechanism

MMP is designed for extensibility. Extensions add new frame types, handshake fields, or protocol behaviours without modifying the core specification.

16.1 Extension Registration

Extensions are advertised via the extensions field in the handshake frame. A node MUST ignore extensions it does not recognise. A node MUST NOT require a peer to support any extension.

16.2 Frame Type Naming

Core types (this specification): MUST NOT be redefined by extensions. Extension types: MUST use <extension>-<name> format (e.g., mesh-group-join). Vendor types: MUST use x-<vendor>-<name> format. Vendor types MUST be silently ignored by non-supporting nodes.

16.3 Extension Negotiation

If both peers advertise the same extension in handshake, it is active. If only one peer advertises it, the extension is NOT active — the advertising peer MUST NOT send extension-specific frames to a peer that does not support them.

16.4 Registered and Candidate Extensions

16.5 Extension Lifecycle

Extensions progress through a defined lifecycle:

• Proposal: submit as a Draft extension with a specification document and at least one reference implementation.
• Review: community review plus spec maintainer approval. Draft extensions MAY be deployed experimentally but MUST NOT be treated as stable.
• Promotion to Core: an extension MAY be promoted to a core frame type. Promotion requires a spec version bump (see the versioning policy, spec index) and MUST maintain backward compatibility with existing deployments of the extension.

16.6 Versioning

Extensions use Semantic Versioning independently of the core MMP specification version. An extension version bump MUST NOT require a core spec version bump unless the extension is being promoted to core.

17. Conformance

MMP conformance is defined in two classes, not one ladder, because the protocol’s two halves have different natures. Emission — minting a well-formed CAT7 block and putting it on the wire — is a message-format contract: fully specified, byte-testable, and implementable by any party in an afternoon. Cognition — admission, temporal integration, reinforcement, branching — is a coupled runtime whose correctness lives in dynamics, not in a wire format; it is documented so an emitter can trust what a mesh will do with its blocks, not so third parties rebuild it. Interoperability lives at the emission layer; the receiver-side is a runtime, and the reference implementation is its normative behavior. (This is the deliberate architecture, not a limitation — see the formalization’s “reference implementation is the standard” note.)

17.1 Class 1 — Emitter (the normative wire contract)

An Emitter participates in a mesh by producing CAT7 blocks and delivering them; it need not admit, store, or reason. This is the third-party conformance target — what a sensor, a CI pipeline, or another vendor’s agent implements to emit into a mesh. A conforming Emitter MUST:

• Identity — hold a stable nodeId backed by a persistent Ed25519 keypair (§3.1.3, §18.3).
• CAT7 blocks — mint CMBs carrying all seven typed fields (§8.2), absent fields normalized to "neutral", never omitted.
• Content address — compute the cmb1- key over the canonical serialization (§8.2.1); two conforming emitters MUST produce the identical key for the same block. Verified by the published cmb-key-v1 vectors.
• Signature — sign the block over the §18.3.1 payload (binding key, author, time, and audience); cmb-sig-v1 vectors are the contract.
• Transport + handshake — length-prefixed JSON over TCP (LAN) or WSS (relay), the §5 handshake, and deliver a cmb frame (§7). Silently ignore unrecognised frame types.
• Anti-echo — emit only on genuinely new domain data (§15.7); an emitter that re-states without new observation is noise.

An Emitter is fully specified today and needs no receiver-side machinery: it does not run SVAF, keeps no store, and hosts no cognitive state. (The relay/forwarding-only node of earlier revisions is an Emitter sub-profile that forwards frames without minting them.) An SDK SHOULD package this as a thin client so emitting is a handful of lines; where the reference SDK does not yet provide a standalone emitter, the wire requirements above remain the normative contract — see §17.6.

17.2 Class 2 — Cognitive Node (reference-implementation behavior)

A Cognitive Node is a full mesh participant: it admits, integrates, reinforces, and branches. Its behavior is specified for transparency, not reimplementation — so an Emitter knows what a mesh guarantees about its blocks (what the membrane admits, how lineage is kept, what grounding means), and so a deployment is auditable. A Cognitive Node MUST honor every Emitter obligation, plus:

• Hidden-state locality — L2 memory-tier hidden state (h₁, h₂, held by Layer 6) MUST NOT cross the wire (§2.7); a conformant node MUST NOT emit state-sync.
• Admission — per-field SVAF evaluation against local anchors (§9.2), satisfying the §9.2.1 δ_f interface invariants; the reference baseline is vector-tested (svaf-baseline).
• Integration — store an admitted block as a remix with lineage (§15.5), never the raw peer block; lineage remains walkable (§15.2) and honors the tether (§15.8).
• Memory + Canon — the lifecycle and retention rules of §6, including the Canon exemption (§6.3) and grounding (§6.7).
• Cognitive layers (Layers 5–7, optional) — synthetic memory (§12), Cognitive State (§13), and application (§14); a node MAY implement these, and if it persists Layer-6 state it MUST keep it across restarts (§13).

The normative behavior of Class 2 is what the reference implementation does; the specification of these layers is documentation of that runtime, and independent reimplementation is neither required nor expected for interoperability. Two independent Cognitive Nodes are not guaranteed to agree block-for-block — admission is receiver-divergent by design (§9.2.1), the embedding kernel is receiver-local, and thresholds are meaningful only within a pinned encoder. A mesh interoperates with a Cognitive Node; it does not certify a re-built one.

17.4 Testing

Class 1 conformance is verified byte-for-byte against the published conformance vectors (cmb-key-v1, cmb-sig-v1) — an Emitter that reproduces them meshes with any deployment. Class 2 implementations SHOULD additionally test admission (the svaf-baseline vectors), CMB creation, and lineage. At minimum, tests SHOULD cover:

• Ed25519 identity keypair — generated at first launch, persisted, and presented in the handshake (Sections 3.1.3, 18.3)
• CMB signature verification — a receiver holding the author’s key MUST reject forged or tampered CMBs (Section 18.3.1)
• Emission gate — a remix MUST carry new domain data; pure paraphrase is not emitted (Section 15.7)
• Receiver-autonomous SVAF admission — per-field evaluation at the receiver, no sender override (Section 9.2)
• Hidden-state locality — hidden state (h₁, h₂) MUST NOT cross the wire (Section 2.7)
• Lifecycle authority gates — lifecycle advancement honored only for authors whose role resolves through the signed grant chain (Section 6.5)

The normative conformance test vectors are published in the protocol repository: cmb-key-v1 (§8.2.1 content addresses), cmb-sig-v1 (§18.3.1 signing payload + Ed25519), svaf-baseline (§9.2/§9.2.1 admission math, the nearest-anchor redundancy witnesses, and the evaluation-time flip window), and tether-v1 (§15.8 drift checks + mmp-tether-v1 attestation). A conforming Class 1 Emitter MUST reproduce the cmb-key-v1 and cmb-sig-v1 expectations exactly. The svaf-baseline and tether-v1 sets are runtime-audit vectors: they pin the reference runtime’s admission math so deployments are verifiable, not so third parties rebuild it (§17.2); they carry raw field vectors and no text — they test the math, not the encoder (§9.2.1). The reference implementation re-derives every vector in its own suite, so it cannot drift from the published contract.

17.5 Requirements Added in 1.1.0

17.6 Implementation Status

Where the reference implementations stand against this specification. Normative requirements are defined by the sections cited, not by this table; a specified-but-unimplemented item is a conformance gap of the reference implementation, never a weaker requirement.

18. Security Considerations

MMP is designed for autonomous agents that share cognitive state. Security must address both traditional protocol threats (spoofing, eavesdropping, injection) and novel threats specific to cognitive coupling (state poisoning, drift manipulation, lineage forgery).

18.1 What Crosses the Mesh

Hidden state vectors (h₁, h₂) are compact, opaque neural representations encoding cognitive patterns, not raw data. Because sufficiently advanced analysis could reconstruct aspects of the input, hidden state is a privacy surface — which is precisely why it never crosses the wire (Section 2.7). It is strictly local and confidential by construction; only CMBs — deliberately scoped, signed statements — propagate.

18.2 Transport Security

MMP does not mandate transport encryption in the base specification. Implementations SHOULD apply:

18.2.1 End-to-End CMB Encryption

WSS (TLS) encrypts the transport — it protects from eavesdroppers on the wire. But the relay operator can still read the JSON payload inside the TLS tunnel. For cmb frames containing CMBs, this means the relay sees all 7 CAT7 field texts in plaintext.

When CMBs transit a relay, implementations MUST encrypt CMB field text end-to-end so the relay forwards opaque ciphertext, not readable fields. The relay MUST NOT be able to read CMB content.

The encryption scheme SHOULD use the Ed25519 keypair from Layer 0 (Section 3) for key exchange, with X25519 Diffie-Hellman for shared secret derivation and XChaCha20-Poly1305 for symmetric encryption. The encrypted payload replaces the fields object in the CMB:

{
  "type": "cmb",
  "timestamp": 1711540800000,
  "cmb": {
    "key": "cmb-b2c3d4e5f6a7b8c9",
    "createdBy": "agent-a",
    "createdAt": 1711540800000,
    "fields": "<encrypted>",        // opaque ciphertext
    "nonce": "base64-encoded-nonce", // per-frame nonce
    "lineage": { ... }              // lineage stays cleartext for graph traversal
  }
}

lineage (parents, ancestors, method) remains in cleartext. Lineage contains only CMB keys (content hashes) — not field text. This allows the relay and intermediate nodes to maintain graph structure without reading content.

On LAN (Bonjour TCP), E2E encryption is RECOMMENDED but not required — there is no relay intermediary. On trusted LANs, the transport itself provides sufficient isolation.

18.3 Node Identity & Authentication

Node identity is UUID-based with mandatory Ed25519 cryptographic identity (Section 3.1.3). Authentication ensures that nodeId claims are verifiable and that relay intermediaries cannot impersonate peers.

• —Each node MUST generate an Ed25519 keypair at first launch and persist it alongside the nodeId.
• —The public key MUST be included in the handshake frame and DNS-SD TXT record.
• —Peers SHOULD verify identity by challenging the node to sign a nonce with its private key.
• —Implementations that have not yet adopted cryptographic verification MAY rely on DNS-SD discovery scope and network isolation as an interim trust model, but MUST document this limitation.

18.3.1 CMB Signature Verification

Transport identity (above) authenticates the connection; CMB signatures authenticate each cognitive block end-to-end — the layer that matters when a peer-pushed CMB can enter the receiving agent’s context. Every CMB SHOULD be signed by its author using the same Ed25519 identity key the node announces in its handshake.

• —The author signs a canonical payload binding the content-address key (§8.2.1), the author’s nodeId, the author’s own creation time, and the CMB’s audience. For cmb1- keys the payload is domain-separated and length-prefixed — "mmp-sig-v1\n" + LP(key) + LP(author) + LP(decimal(createdAt)) + LP(group) + LP(to) — where group is the group the CMB was authored for and to is the directed recipient’s nodeId (empty for a broadcast). Length-prefixing closes the delimiter-injection the address serialization does, and the payload MUST use the author’s own createdAt, never a receiver-local timestamp. The signature travels as cmb.sig (base64url) with cmb.sigAlg (ed25519); a verifier MUST pin the expected algorithm rather than trust sigAlg.
• —A receiver holding the author’s public key MUST verify a signed CMB on two counts before admitting or surfacing it: (1) the signature verifies against that key, and (2) the content-address key still matches the actual fields — a valid signature replayed over swapped content MUST be rejected.
• —Audience check. Because the signature binds group and to, a receiver MUST additionally reject a signed CMB whose group is not the receiver’s group, or whose to is neither empty nor the receiver’s nodeId — a cross-group or mis-directed replay that is genuinely signed but not for this audience. This is a check distinct from a bad signature, so a wrong-audience block is not mis-reported as tampering; it also enforces the §5.8 group boundary cryptographically, not only at the frame layer.
• —A CMB that fails any check MUST NOT be surfaced to the application layer or stored, and SHOULD be audit-logged. This forecloses spoofing (forging another peer’s authorship), tampering (mutating a block in flight), and cross-audience replay.
• —Unsigned CMBs MAY be accepted only from peers that never demonstrated signing. To prevent downgrade (stripping the signature and re-emitting unsigned), once a receiver has admitted a signed CMB from an identity it MUST reject subsequent unsigned CMBs purporting to be from that identity. (This requires durable per-identity state; first contact remains trust-on-first-use.)
• —Enforcement scope, disclosed. A strict mode that rejects unsigned CMBs is necessarily scoped to peers whose keys the receiver can resolve: unsigned traffic from a peer with no pinned or roster-resolvable key passes even in strict mode — the receiver cannot distinguish a never-signing peer from a stripped signature at first contact. Key resolution SHOULD consult the full binding registry (anchor-pinned, handshake-pinned, and grant-vouched keys — §6.6), not the direct-handshake map alone, so relayed peers the receiver never met still verify; the residual unsigned-from-unknown window closes only when signature enforcement is on and the roster covers the mesh. Operators of regulated meshes SHOULD run enforcement on with a seeded roster.

18.4 Cognitive Threats

MMP introduces threats unique to cognitive coupling that traditional protocol security does not address:

18.5 Privacy & Deployment Recommendations

Metadata exposure. Even with E2E field encryption (Section 18.2.1), the following metadata travels in cleartext: createdBy, lineage.parents, lineage.ancestors, and mood valence/arousal values. Mood is intentionally unencrypted because it is always delivered even from rejected CMBs (Section 9.3). Deployments where mood leakage is unacceptable MUST disable mood delivery by setting all mood field weights to 0. This is a deliberate privacy trade-off: the protocol prioritises collective intelligence over metadata confidentiality.

MMP is designed for privacy by default — L0 data never leaves the node, hidden states are opaque, and SVAF gates what enters. For domains with heightened privacy or IP concerns, the following deployment model is RECOMMENDED:

Additional privacy considerations:

• —Error frames MUST NOT contain sensitive information. The detail field is for debugging, not for conveying user data.
• —Wake channels expose push tokens to peers. Implementations SHOULD restrict wake channel gossip to trusted relays only.
• —Implementations targeting GDPR, HIPAA, or similar regulatory frameworks SHOULD treat CMB field text as personal data and apply appropriate retention and deletion policies at the application layer.

18.6 Regulatory Compliance & Audit Trail

CMB immutability and lineage create a tamper-evident audit trail within the signed, retained graph — tamper-evident, not tamper-proof: modification of any retained block is detectable via content addressing and signatures; completeness of the underlying store is not itself checkpointed (retention §6.3 may purge, and unsigned blocks weaken the guarantee, §18.3.1). Every observation, every remix, every decision is traceable through the DAG:

• —Who — createdBy on every CMB identifies the agent that produced it.
• —When — createdAt timestamps every CMB with millisecond precision.
• —What — the 7 CAT7 fields capture the full semantic content of the observation.
• —Why — lineage.parents shows what was directly remixed. lineage.ancestors traces the full decision chain.
• —How — lineage.method records the evaluation method (e.g., SVAF-v2).

Because CMBs are immutable, the audit trail cannot be retroactively altered. A CMB once created is never modified — any action produces a new CMB with lineage pointing back. The complete history is the graph itself.

18.7 Data Quality & Encoding Trade-offs

CMB quality depends on field extraction accuracy. The protocol does not extract fields — agents do. Each agent’s LLM (or structured-data mapper) decomposes observations into CAT7 fields. If extraction is poor, downstream evaluation inherits that error. MMP provides three layers of defense, but none eliminates the need for quality extraction at the source.

Per-field evaluation quality is bounded by encoder quality, not model capacity. Production deployment revealed that n-gram encoding (character trigrams + word bigrams) produces 0.31 cosine similarity for paraphrases — SVAF cannot distinguish “submit IETF draft today” from “IETF submission, zero blockers, execute now” because the encoder represents them as distant vectors. Replacing n-gram with semantic embeddings (all-MiniLM-L6-v2, 384-dim) raises paraphrase similarity to 0.69 — a 2.2× improvement — while preserving topic separation (different topics: 0.03). Implementations SHOULD use semantic embeddings for SVAF evaluation. N-gram encoding is suitable only for prototyping or resource-constrained environments where the quality trade-off is acceptable.

Implementations targeting domains where field extraction quality is critical (healthcare, legal, finance) SHOULD validate extraction output before calling remember(). Strategies include:

• —Schema validation — reject CMBs with empty or defaulted fields before they enter the mesh
• —Confidence thresholds — the LLM can assign a confidence score to its extraction; low-confidence CMBs can be withheld
• —Lineage feedback — CMBs that get remixed by other agents (have descendants in the DAG) signal high quality; CMBs that expire without children signal noise. This feedback loop lets the mesh itself shape extraction quality over time
• —Semantic embedding encoder — implementations SHOULD use a semantic embedding model (e.g. all-MiniLM-L6-v2) for SVAF drift computation. The evaluation pipeline is encoder-agnostic — any function that maps text to unit-normalised vectors works. N-gram encoding MAY be used as a zero-dependency fallback.

19. Configuration

Constants are fixed by the specification. Configuration is per-agent and per-implementation. Both are normative — implementations MUST respect constants and SHOULD use the default configuration values unless the agent’s domain requires otherwise.

19.1 Protocol Constants

19.2 Agent Profiles

Each agent type has a pre-built configuration. The profile determines which CMB fields matter most (α_f weights), how long signals stay relevant for SVAF evaluation (freshness), and how long remixed CMBs are retained in local storage (retention). New agent types join the mesh by defining their profile — no protocol changes needed.

Freshness and retention are different: freshness controls SVAF temporal drift (how quickly incoming signals become “stale” for evaluation). Retention controls how long the agent’s own remixed CMBs are kept in local storage. Regulated deployments SHOULD set retention according to their compliance obligations — deployment guidance, non-normative; consult counsel for the applicable regime.

19.3 CAT7 Field Weights (α_f)

Per-agent field weights control which CMB fields matter most for each agent type. Higher weight = this field has more influence on SVAF evaluation and remix relevance. The schema is fixed (7 fields). The weights are per-agent.

Regulated domains (legal, finance): issue and commitment always high — risks and obligations are non-negotiable. Human-facing domains (music, fitness, health): mood always high — affect drives the experience. Knowledge domains (coding, research): focus always high — subject matter is core.

Custom weights: derive from your domain using these patterns. Implementations SHOULD expose field weights as configuration, not hardcode them.

19.4 SVAF Drift Thresholds

SVAF computes a totalDrift score (0–1) for each incoming memory. Three zones determine acceptance:

Defaults work for most agents. Override only with domain-specific reason: tighter thresholds for high-precision domains (legal, health), wider for exploratory domains (research, knowledge).

19.5 Mood vs Memory Thresholds

Mood and memory use different acceptance paths:

19.6 Drift Formula

totalDrift = (1 - λ) × fieldDrift + λ × temporalDrift

fieldDrift    = Σ(α_f × δ_f) / Σ(α_f)
temporalDrift = 1 - exp(-age / τ_freshness)
λ             = temporalLambda (default 0.3 = 70% content, 30% time)

At default settings (temporalLambda: 0.3, freshnessSeconds: 1800):

20. JSON Schema

Formal JSON Schema definitions for core frame types — the schemas are the contract, and any implementation (the reference included) conforms to them. Implementations SHOULD validate frames against these schemas. additionalProperties is true by design: §8 requires unrecognised fields to be silently ignored, so a schema SHOULD not reject a forward-compatible extension. The single-page downloadable specification carries the full rendered spec. Machine-readable schema files are published in the protocol repository — handshake, CMB (including the §15.8 tether attestation), the cmb frame, and the cmb-fetch pair — and the reference implementation’s suite validates its real wire objects against them, so it cannot drift from this contract. The published schema set above is the final normative set; frame types without a published schema are validated against their §7 definitions.

Two scope notes. These are the wire schemas: receiver-local fields (source, originTimestamp, storedAt, confidence, provenance) are set on receipt and never cross the wire, so they are not listed. And the CMB schema describes the decrypted form: under end-to-end encryption (§18.2.1) a CMB in transit carries fields as ciphertext plus _e2e.nonce, and the object schema below applies after decryption. Each field also carries a vector embedding; it is advisory and encoder-specific (§18.7) — not part of the content address (§8.2.1), and a receiver recomputes it locally rather than trusting the sender’s. Optional application-level fields (meta, payload) MAY also be present and are permitted by additionalProperties.

20.1 Handshake Frame Schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["type", "nodeId", "name", "version", "publicKey"],
  "additionalProperties": true,
  "properties": {
    "type": { "const": "handshake" },
    "nodeId": { "type": "string", "format": "uuid" },
    "name": { "type": "string", "minLength": 1, "maxLength": 64 },
    "version": { "type": "string", "pattern": "^\\d+\\.\\d+\\.\\d+$" },
    "publicKey": { "type": "string", "description": "base64url raw Ed25519 identity key (32 bytes); verifies this node's CMB signatures (§18.3.1)" },
    "e2ePublicKey": { "type": "string", "description": "base64 X25519 key for end-to-end field encryption (§18.2.1)" },
    "group": { "type": "string", "description": "The node's mesh group; the §5.8 isolation boundary. Absent ⇒ 'default' (§5.2)." },
    "lifecycleRole": { "enum": ["participant", "validator", "anchor"], "description": "Senders SHOULD include it (§5.2); receivers treat absence as participant. Self-declared: an elevated role is honored only with a signed role-grant (§6.6)." },
    "extensions": { "type": "array", "items": { "type": "string" } }
  }
}

20.2 CMB Schema

The cmb object within a cmb frame:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["key", "createdBy", "createdAt", "fields"],
  "additionalProperties": true,
  "properties": {
    "key": { "type": "string", "description": "Content address (§8.2.1): normative scheme cmb1- + full-width SHA-256 over the canonical serialization; legacy cmb- (SHA-256/128, pipe-joined) MUST still be verified during migration." },
    "createdBy": { "type": "string", "description": "The author identifier (nodeId or agent name); bound by the signature (§18.3.1)" },
    "createdAt": { "type": "integer", "description": "Unix ms timestamp of creation — the author's own; bound by the signature (§18.3.1)" },
    "sig": { "type": "string", "description": "base64url Ed25519 signature over the §18.3.1 payload. SHOULD be present; a receiver holding the author's key MUST verify it." },
    "sigAlg": { "const": "ed25519", "description": "Signature algorithm; a verifier MUST pin this rather than trust the field (§18.3.1)." },
    "group": { "type": "string", "description": "cmb1- only: the group this CMB was authored for — audience binding (§18.3.1). Absent on legacy cmb-." },
    "to": { "type": "string", "description": "cmb1- only: directed recipient nodeId; empty or absent for a broadcast (§18.3.1)." },
    "_e2e": { "type": "object", "description": "Present only when the CMB is E2E-encrypted in transit (§18.2.1): then 'fields' is ciphertext, not the object below.", "properties": { "nonce": { "type": "string" } } },
    "fields": {
      "type": "object",
      "required": ["focus", "issue", "intent", "motivation", "commitment", "perspective", "mood"],
      "properties": {
        "focus":       { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" }, "vector": { "type": "array", "items": { "type": "number" } } } },
        "issue":       { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" }, "vector": { "type": "array", "items": { "type": "number" } } } },
        "intent":      { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" }, "vector": { "type": "array", "items": { "type": "number" } } } },
        "motivation":  { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" }, "vector": { "type": "array", "items": { "type": "number" } } } },
        "commitment":  { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" }, "vector": { "type": "array", "items": { "type": "number" } } } },
        "perspective": { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" }, "vector": { "type": "array", "items": { "type": "number" } } } },
        "mood": {
          "type": "object",
          "required": ["text"],
          "properties": {
            "text": { "type": "string", "description": "Mood keyword (MUST)" },
            "valence": { "type": "number", "minimum": -1, "maximum": 1, "description": "RECOMMENDED when agent has reliable circumplex data" },
            "arousal": { "type": "number", "minimum": -1, "maximum": 1, "description": "RECOMMENDED when agent has reliable circumplex data" },
            "vector": { "type": "array", "items": { "type": "number" } }
          }
        }
      }
    },
    "lineage": {
      "type": ["object", "null"],
      "description": "null on a root/origin CMB (no parents)",
      "properties": {
        "parents": { "type": "array", "items": { "type": "string" }, "description": "Direct parent CMB keys" },
        "ancestors": { "type": "array", "items": { "type": "string" }, "description": "Full ancestor chain" },
        "method": { "type": "string", "description": "Fusion method (e.g. SVAF-v2)" }
      }
    }
  }
}

Complete cmb frame with CMB:

{
  "type": "cmb",
  "timestamp": 1774326000000,
  "cmb": {
    "key": "cmb-b2c3d4e5f6a7b8c9",
    "createdBy": "music-agent",
    "createdAt": 1774326000000,
    "fields": {
      "focus":       { "text": "user coding for 3 hours, energy declining" },
      "issue":       { "text": "sedentary since morning, skipping lunch" },
      "intent":      { "text": "recommend movement break before fatigue worsens" },
      "motivation":  { "text": "3 agents reported declining energy in last hour" },
      "commitment":  { "text": "fitness monitoring active, 10min stretch queued" },
      "perspective": { "text": "fitness agent, afternoon session, home office" },
      "mood":        { "text": "concerned, low energy", "valence": -0.3, "arousal": -0.4 }
    },
    "lineage": {
      "parents": ["cmb-a1b2c3d4e5f6"],
      "ancestors": ["cmb-a1b2c3d4e5f6"],
      "method": "SVAF-v2"
    }
  }
}

This example shows the legacy unsigned form (cmb- key, no sig); §8.2.1 and §18.3.1 define the current cmb1-/signed form.

21. References

References are split into normative (a conforming implementation depends on them), foundational (the published results the protocol’s design rests on), and informative (background). Reference implementations are listed last; the published conformance vectors (§17.4) are the byte-level interop contract for this final version.

21.1 Normative References

21.2 Foundational Papers

The protocol’s no-center, receiver-autonomous-admission, and lineage-provenance design rests on these published results. (Numeric defaults and thresholds are engineering choices of the runtime, not results derived in these papers.)

21.3 Informative References

21.4 Reference Implementations