Change Log

Complete version history of this specification. Every published version has been verified in real systems — 1.0 and 1.1 ran across Windows, macOS and iOS applications, over LAN and over an internet relay. 2.0 re-derives the specification from the implementation as it now runs, after the record model advanced and the text did not follow. 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 category 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 categories, 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). A nodeId has that one spelling: a receiver compares nodeIds exactly, and a nodeId in any other spelling in a signed field (a record’s createdByNodeId or to, a handshake hello’s nodeId (§5.2), an authority statement’s subject) makes that record, statement or handshake malformed (§8.8.5, §5.2, §6.6.3), because the bytes signed are exactly those characters. A nodeId read from an unsigned local source, such as configuration or a Legacy Import store (§17.3), MAY be lowercased before it is compared. 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 Ed25519 public key MUST appear in the authenticated handshake offer. Both peers MUST sign the same transcript and verify the other signature before the connection becomes usable.
• —Key agreement — each node also generates an independent X25519 keypair for ephemeral Diffie–Hellman agreement. Implementations MUST NOT treat Ed25519-to-X25519 conversion as the Core Secure construction.
• —Record signing — every Core Secure record assertion MUST use the author’s Ed25519 identity key and the mmp-sig-v2.0 preimage (§8.8.4). Unsigned records belong only to an explicitly selected Legacy Import profile.

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 category 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 category 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 a revoke statement (§6.6.5), which needs no new identity and takes with it everything the removed grant authorised. Implementations SHOULD document the identity limitation to operators.

One key per nodeId, bound once. Because the key never rotates, a receiver binds each nodeId to exactly one Ed25519 identity key. A binding comes from one of: a confirmed handshake (§5.2), the pinned anchor (§6.6.1), an in-force grant that names the nodeId with its key (§6.6.9; such a binding lasts only while that grant is in force, and never covers the receiver’s own nodeId), or an out-of-band pin the operator accepted (an invitation or configured route that names the nodeId and its key). Discovery records, relay data and unproven hellos never bind (§18.3). A legacy claim — a key that a pre-0.14 implementation recorded for a nodeId from an unproven hello or from a grant — does not bind either: it is the key the receiver expects for that nodeId, so a session proving it binds it and a session proving a different key is an identity conflict, but by itself it verifies nothing and confers no authority (§6.6.11). A binding from any source MUST NOT be replaced by a different key from any other source — not by a later handshake, not by a grant, and not by a source ranked stronger. Sources differ in what they may create, never in what they may override.

Identity conflict. When a session proves, or an in-force grant names, a key for a nodeId that is already bound to a different key, the receiver MUST refuse it. It MUST close the session with error 1009 (IDENTITY_CONFLICT, §7.2), or, for a grant, leave the binding as it is; it MUST NOT create or change any per-peer state for the refused key — keys, session or E2E secrets, room admission, attribution, budgets; it MUST record the conflict (the nodeId, both keys, the source of each and the time); and it SHOULD report the conflict to its operator. An implementation MUST NOT resolve a conflict by itself — not by recency, not by source rank, not by how many peers agree. Only an operator act resolves one, and the act is explicit and recorded. Re-pinning a fresh anchor out of band (§6.6.1) is such an act: the configured anchor is configuration, not a learned binding.

A conflict changes bindings, never authority. Authority is resolved from the statement set alone, with each signer’s key taken from the grant that authorises it (§6.6.9), so every node resolves the same in-force set whatever keys it has bound. A grant whose key conflicts with a binding stays in force, and confers nothing at that receiver on the bound key: no record that verifies under the bound key is signed by the grant’s key.

The refusing side sends error 1009 and then closes. The refused side MUST NOT retry automatically: a retry presents the same key and meets the same refusal, and a retry loop is noise in the record the operator must read. It SHOULD report the refusal to its own operator, since either party may be the one whose key is wrong.

A conflict is recorded only once the different key has been proven: the receiver SHOULD complete the proofs of §5.2 before it refuses, so that what it records is a key someone holds and not a claim someone typed. A hello that merely names a different key MAY be dropped at once without a record, and it MUST NOT disturb an existing session for that nodeId.

The same key is the same node. A confirmed session that proves a nodeId’s bound key MUST NOT be refused as a duplicate, on any transport. Duplicate detection happens only after both proofs, and an unproven hello naming a connected nodeId is evidence of nothing. Two live processes holding one identity cannot be told apart by any proof; each of them is the node, which §3.2 forbids deployments to arrange. An implementation SHOULD report repeated supersession between concurrent sessions for one (nodeId, key) as a probable copied identity. The relay’s replacement of a connection (§4.4.7) is a routing decision about which WebSocket carries a nodeId’s frames; it decides nothing about identity at an endpoint, which applies this section to the sessions it confirms. Error 1005 is retained for Legacy Import, where nothing is proven; Core Secure does not send it.

3.5 Node Lifecycle Role

Each node has a lifecycleRole — participant (default), validator, admin, or the anchor — that determines which CMB lifecycle transitions it may perform. A role is earned, not asserted: its authority MUST be resolved from the in-force grants that name the node’s nodeId and key (§6.6), and the anchor is pinned, never granted (§6.6.1). 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 admin or the anchor, and a scoped grant confers either only on CMBs inside its scope (§6.6.2). An issuer admits nodes and confers no lifecycle authority. A receiver MUST resolve the author’s role against its in-force set (§6.6) — never the name 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 admin or the anchor. Promotion is a signed grant statement (§6.6.3), not an out-of-band configuration change.

Promotion is upward (participant → validator → admin) and demotion is defined: a revoke statement (§6.6.5) removes a grant, and everything the removed grant authorised is dead unless a signer above it endorses what should stand. 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 a revoke without a new identity.

A grant statement is signed by its grantor over its kind, the authority it is made under (authorisedBy: the grantor’s own grant, or the anchor), the subject’s nodeId and key, the role and a nonce, and over no time that resolution reads (§6.6.3). A receiver MUST verify it with the key of the grant it names (or the pinned anchor keys) and treat it as in force only as §6.6.4 resolves it; a grant its signer was not permitted to make is invalid and discarded. 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:

First Core Secure handshake payload (client-hello):
{
  "type": "client-hello",
  "protocolVersion": "2.0",
  "room": "conformance-room",
  "nodeId": "018f47a0-7b21-7abc-8def-111111111111",
  "name": "vector-client",
  "identityPublicKey": "0EqyMnQrtKs6E2i9RhXk5tAiSrcaAWuvhSCjMsl3hzc",
  "e2ePublicKey": "ew1H2TQn-DERYHgcfHM_2J-IlwrvSQ2KoO4ZpMuKGxQ",
  "nonce": "VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVU",
  "implementation": {
    "name": "mmp-vector",
    "version": "1.0.0"
  },
  "extensions": [
    "receipts-v1",
    "admission-attestation-v1"
  ]
}

The server-hello and client-finish frames complete transcript authentication and key confirmation.
See §5.2 and the full handshake-v2 vector.

Ping frame:

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

CMB frame:

{
  "type": "cmb",
  "protocolVersion": "2.0",
  "timestamp": 1711540800000,
  "cmb": {
    "categories": {
      "focus": {
        "text": "user coding for 3 hours, energy declining",
        "meta": {
          "key": "8b18a6a666984aa302c18b670b7c0f580ba9a13f72bcc1c80006b4ebc4eaa891",
          "parents": [
            "cmb-1010101010101010101010101010101010101010101010101010101010101010"
          ]
        }
      },
      "issue": {
        "text": "sedentary since morning, skipping lunch",
        "meta": {
          "key": "f7c2fb57884d9b68704b0381d38b6bba2574b10169b9002af019caa42942361d",
          "parents": [
            "cmb-1010101010101010101010101010101010101010101010101010101010101010"
          ]
        }
      },
      "intent": {
        "text": "recommend movement break before fatigue worsens",
        "meta": {
          "key": "6c7876aca1833fa873a673dcbfdffff0c340e2313d7aa741a10f0c9e4e685f7d",
          "parents": [
            "cmb-1010101010101010101010101010101010101010101010101010101010101010"
          ]
        }
      },
      "motivation": {
        "text": "three agents reported declining energy in the last hour",
        "meta": {
          "key": "4e65c95741b7be92674e62919599b09b60590885592993b916a82c03ac11c34d",
          "parents": [
            "cmb-1010101010101010101010101010101010101010101010101010101010101010"
          ]
        }
      },
      "commitment": {
        "text": "fitness monitoring active, ten-minute stretch queued",
        "meta": {
          "key": "112a9cd044c87587cfcc68044a128f9126fc1255f412a8d990b7b27a27ac483e",
          "parents": [
            "cmb-1010101010101010101010101010101010101010101010101010101010101010"
          ]
        }
      },
      "perspective": {
        "text": "fitness agent, afternoon session, home office",
        "meta": {
          "key": "f5dd4c3134cb72d9a153126889432fb5cd59bae7b70c311a2079597caa417f3a",
          "parents": [
            "cmb-1010101010101010101010101010101010101010101010101010101010101010"
          ]
        }
      },
      "mood": {
        "text": "concerned, low energy",
        "meta": {
          "key": "20504e25877d24384571595d4e99dec308d69e9b207e9ce7871554ce835a9c95",
          "parents": [
            "cmb-1010101010101010101010101010101010101010101010101010101010101010"
          ]
        },
        "valence": -0.3,
        "arousal": -0.4
      }
    },
    "metadata": {
      "key": "cmb-091003a832567f0c4ec11b6a5d5be4557f2f0dbf561ba182d251d87edcfcd7a7",
      "addressScheme": "mmp-cmb-merkle-v2",
      "signatureSuite": "mmp-sig-v2.0",
      "createdByNodeId": "018f47a0-7b21-7abc-8def-aaaaaaaaaaaa",
      "createdBy": "sensor-a",
      "createdTimestamp": 1711540800000,
      "room": "spec-examples",
      "to": null,
      "lineage": {
        "parents": [
          "cmb-1010101010101010101010101010101010101010101010101010101010101010"
        ],
        "method": "svaf-heuristic"
      },
      "application": null,
      "assertionId": "asrt-bb2003c7c34ceb1f4be7889342ff38dd34a1943e14e4724ddf257c466c1e76a8",
      "sigAlg": "ed25519",
      "sig": "ueE00X-6Q3E3X_fKmB048CGA0fcfpwX6MjcuNL7yH7eIG58SQOg0OS3W9JrdNNWnB1ULQhoq92DZIiPSsa_1CQ"
    }
  }
}

This example shows the legacy unsigned form (cmb- key, no sig); §8.2.1 and §18.3.1 define the current cmb-/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>",
  "room": "<room identifier>",
  "engine": "<implementation label>",
  "wakeChannel": {
    "platform": "apns",
    "token": "<push-token>",
    "environment": "production"
  }
}

• —nodeId, name: MUST be present; a missing one results in close code 4002. nodeId is the lowercase form of §3.1.1; a relay MUST refuse any other spelling with 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).
• —room: MAY be present: a room identifier (§5.8; absent means default). A relay that scopes routing, roster, presence and fan-out by room uses it to address the connection. It is addressing, never permission: the channel token stays the boundary, and the §5.8 checks at each endpoint still apply.
• —engine: MAY be present: an implementation label of at most 32 characters, for the relay operator’s logs. A relay MUST NOT forward it.

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 }
  ],
  "features": ["fanout"]
}

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.

features MAY be present. It lists the optional relay behaviours this relay implements; the one defined here is fanout (§4.4.4). A client MUST ignore a feature it does not recognise, and MUST NOT use a feature the relay did not list on that connection. An absent features lists none.

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. A sealed frame (§18.2.1) is sealed for one session, so a sender MUST send it with to or in a fan-out, never as a broadcast: a broadcast sealed frame reaches peers that cannot open it. to is a nodeId in the lowercase form of §3.1.1; an envelope whose to is anything else is malformed. A relay drops a malformed unicast envelope without delivering it, and MAY answer it with a relay-error. The relay adds from and fromName to forwarded frames. The relay MUST NOT route frames across channels.

Fan-out. A sender that holds a separate session with each recipient (§18.2.1) seals one frame per recipient, so a room broadcast to N peers is N frames. A relay that lists fanout in features (§4.4.2) also accepts a fan-out envelope, which carries them in one client message:

{ "fanout": [
    { "to": "<nodeId-1>", "payload": { "type": "cmb-encrypted", ... } },
    { "to": "<nodeId-2>", "payload": { "type": "cmb-encrypted", ... } }
] }

• —Shape. An envelope carries exactly one of: to with payload; payload alone; or fanout alone. fanout is a non-empty array of entries, each with exactly a to nodeId, in the lowercase form of §3.1.1, and a payload frame; a to that is not one makes the whole envelope malformed. In every form, payload is a JSON object (a frame). A sender MUST NOT name the same recipient twice in one envelope, or itself. A relay MUST refuse a malformed fan-out envelope as a whole and deliver none of it, answering with a relay-error whose kind is fanout and whose reason is one of malformed, too-many-entries, duplicate-recipient or self (§4.4.9).
• —Delivery. The relay delivers each entry exactly as it would deliver a { to, payload } envelope from the same sender: within the sender’s channel (and room, where the relay scopes by room, §5.8) only, as { from, fromName, payload }, with the payload delivered as the same JSON value it was sent as (a relay may serialise it again, but never changes it, and never past the delivered-size bound below). An entry whose recipient is not connected is dropped as a unicast would be; the other entries are still delivered. For each recipient the relay preserves the order of that sender’s frames, fan-out entries included.
• —Confidentiality of the recipient set. A recipient receives only its own entry, in the same form as a unicast; it MUST NOT be able to learn from the delivered bytes that a fan-out occurred or who else was addressed. Recipients that collude can still compare the timing of what they received. The relay learns the recipient set, as it would from N unicasts.
• —Limits. The whole envelope is one WebSocket message. A relay MUST accept a client message of at least MAX_FRAME_SIZE (§19.1), and each payload is also subject to MAX_FRAME_SIZE on its own. A relay that lists fanout MUST accept envelopes of at least RELAY_MIN_FANOUT (64) entries within that size. A relay adds from and fromName to what it delivers, so a delivered message can be larger than the one sent: a client MUST accept a delivered message of up to MAX_FRAME_SIZE plus RELAY_ENVELOPE_ALLOWANCE (4,096 bytes). A relay MUST NOT deliver a larger one. Re-serialising a payload can lengthen it (a JSON serialiser may write 1e21 as 1e+21), so a relay that re-serialises measures what it is about to deliver and drops a message over the bound, as it drops a unicast to an absent recipient; a relay that forwards the payload’s bytes as received meets the bound by construction. A sender splits a larger fan-out into several envelopes. Nesting depth is bounded for the whole envelope, not per payload: a relay MAY refuse a message whose arrays and objects nest more than 64 levels deep, counted from the envelope itself, and MUST NOT refuse one within 64 for depth alone. A unicast payload therefore has 63 levels of its own, and a fan-out payload 61 (the envelope, the fanout array and the entry take three). MMP frames need far fewer: a CMB’s categories sit four levels deep.
• —Rate. A relay MAY limit each client’s inbound message rate, and closes a client that exceeds its limit with 4008. A relay that limits the rate MUST allow at least RELAY_MIN_RATE (25) messages a second, sustained, with a burst of at least RELAY_MIN_BURST (300) (§19.1), and MUST count a fan-out envelope as one message toward that limit. It MAY separately limit the bytes or entries a client sends per second. These are floors, not advertised values; nothing on the wire states a relay’s own limits. A sender SHOULD keep headroom below them, counting every message it sends, relay-auth and relay-pong included, because messages paced at the sender can arrive bunched after a network stall. Without fanout, a sender SHOULD pace its per-recipient envelopes within the floors rather than burst them.

The fan-out envelope changes routing, never meaning: each payload is the frame its recipient would have received by unicast, sealed for that recipient’s session, and a record’s binding comes from its signed audience (§9.2.2), not from how many envelopes carried it.

The envelope’s to is routing only. It MUST NOT be used to decide a CMB’s binding at the receiver — whether the record is peer-bound (directed) or room-bound (autonomous). The binding is the record’s authenticated metadata.to (§9.2.2), which the author signs (§8.8.4) and a sealed frame binds into its associated data (§18.2.1). The envelope is not authenticated, the relay does not forward its to to the recipient, and a sender whose frames are sealed per peer session addresses every frame to one peer, room broadcasts included. 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

Before it closes a client, or when it refuses a message without closing, a relay SHOULD send a relay-error:

{ "type": "relay-error", "kind": "fanout", "reason": "duplicate-recipient",
  "message": "fan-out entry 3 names a recipient an earlier entry names" }

{ "type": "relay-error", "kind": "auth", "code": 4003, "message": "<why the token was refused>" }

• —message (MUST): text for the operator. It MUST NOT quote what the client sent.
• —kind (SHOULD): a token naming what was refused, such as auth, duplicate-identity or fanout.
• —code (MUST when a close follows): the close code below that the relay is about to use, so a client can act on the refusal even when the close reason is cut short.
• —reason (MAY): a token naming the specific cause within kind, such as a fan-out refusal (§4.4.4).

A client MUST ignore a kind or reason it does not recognise. It acts on the close code that follows, which is never cut short, and MAY act on code for a close that does not arrive. A relay-error is a transport-scope frame from the relay, never a peer frame.

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:

One service type for every room. Rooms are not mapped to DNS-SD service types: every node advertises _sym._tcp and carries its room only in the TXT room key, so every §5.8-valid identifier — dots, underscores and all 64 characters — is advertisable (a DNS-SD service name is at most 15 characters and admits neither, RFC 6335 §5.1; the advertised label prefixes it with _, RFC 6763 §4.1.2), and two identifiers can never collapse onto one advertised name. A TXT string is at most 255 bytes per key=value (RFC 6763 §6.1), which a 64-character room fits. A node SHOULD connect only to advertisements whose TXT room equals its own. The TXT room is a hint, never an admission: membership is decided by the authenticated handshake (§5.2, §5.8). It is also broadcast in cleartext to the whole segment: a room name is not a credential (§5.8.1) and MUST NOT be relied on as one, and an operator who treats a room name as sensitive SHOULD use an opaque identifier.

Profile marker. Legacy and Core Secure nodes advertise the same service type, so the TXT record is the only discovery-time signal that tells them apart. The value of mmp is a comma-separated list of the protocol versions the listener’s handshake speaks, with no spaces; this specification defines one, 2.0, so today the value is mmp=2.0. A node whose listener runs the Core Secure handshake (§5.2) MUST list 2.0, and a node MUST NOT list it on an advertisement whose listener does not. A record with no mmp key is a legacy advertisement. A node ignores versions in the list that it does not know, and MUST NOT dial a record as 2.0 unless the list contains 2.0. TXT keys are read as RFC 6763 §6.4 says: compared case-insensitively, and when a key occurs more than once, the first occurrence wins.

A Core Secure node SHOULD dial, as Core Secure, only records whose mmp lists 2.0. It MUST NOT dial a record without the marker under any other profile unless its operator has configured a Legacy Import route for that nodeId (§17.3): the absence of the marker never selects a profile. On the listening side, a Core Secure listener MUST close, without retained state, a connection whose first frame is the legacy one-frame handshake (§5.2.1), and SHOULD bound the work and the logging it spends on such closes per remote address, because pre-2.0 implementations that dial every _sym._tcp advertiser (migration note below) reach Core Secure listeners in default.

The marker is a hint like every TXT key, never authenticated (§18.3). Adding it to a legacy endpoint yields a Core Secure handshake that fails. Stripping it from a Core Secure advertisement hides that node from Core Secure peers on the segment, which an attacker on the segment can do anyway by suppressing the advertisement; it is a denial of discovery and never a downgrade, because no profile is chosen from a discovery record. The protocol version actually spoken is the protocolVersion bound into the handshake transcript.

Migration (non-normative, except as marked). An implementation that advertises a per-room service type MAY also advertise _sym._tcp with TXT room during a transition, and SHOULD drop the per-room type at its next major version. A 2.0 node SHOULD also browse the per-room service type that implementations derive from its room (for the SYM reference runtime, _<room>._tcp), where that is a valid RFC 6335 service name, for as long as it supports migration. The reason is 2.0 nodes that still advertise only a per-room type: they are otherwise undiscoverable, and the partition is silent. (A pre-2.0 peer is not dialled from discovery at all once §5.1’s mmp marker applies, so browsing does not reach it.) Some pre-2.0 implementations (the SYM reference runtime among them) dial every _sym._tcp advertiser in default without a TXT filter, and are refused at the handshake by every named-room advertiser. §5.8’s unconditional mismatch refusal, inbound and outbound, is what makes that safe: an implementation that has not verified it in both directions MUST NOT advertise _sym._tcp for a named room. While per-room service types are still advertised anywhere, the room sym maps to _sym._tcp and is indistinguishable there from default: it MUST NOT be owned and SHOULD NOT be used as a room name. Pre-2.0 advertisements, under either service type, carry no mmp marker, so a 2.0 node that finds one this way dials it only through a configured Legacy Import route (profile marker, above).

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

On a direct connection the TCP or WebSocket dialler is the client and the listener is the server. Over a relay, where both peers dial the relay and neither listens, the roles are assigned by nodeId (§5.2.2). They MUST complete this authenticated exchange in order:

client → server  client-hello  { protocolVersion: "2.0", room, nodeId, name,
                                        identityPublicKey, e2ePublicKey, nonce,
                                        implementation, extensions }
server → client  server-hello  { same server offer, clientNonce, selectedExtensions,
                                proof, keyConfirmation }
client → server  client-finish { transcriptHash, proof, keyConfirmation }

Only after client-finish verifies: CONNECTED

• —protocolVersion is exactly 2.0. Product/package versions belong in the transcript-bound implementation object.
• —room is explicit and NFC-normalized. The default room is the literal default; room mismatch closes the connection before peer admission.
• —Identity and X25519 public keys are raw 32-byte values encoded as unpadded base64url. Each side contributes a fresh 32-byte random nonce.
• —The signed transcript binds both nonces, nodeIds, names, identity keys, E2E keys, implementation identifiers, room, protocol version, both extension offers and the selected extension set.
• —Ed25519 proofs establish identity-key possession. HMAC-SHA256 confirmations under X25519/HKDF-derived finished keys establish E2E private-key possession.
• —No peer identity, key, role or room membership MUST be pinned before both required proofs validate. Failure closes the connection without retained peer state.
• —When both proofs validate, the peer’s nodeId is bound to its proven identity key (§3.4). If that nodeId is already bound to a different key, the handshake is an identity conflict: the connection MUST be closed with error 1009 and the conflict recorded; nothing else is retained. If it is bound to the same key, the session belongs to that peer and MUST NOT be refused as a duplicate.
• —The listener MUST require client-hello first and client-finish before any non-handshake frame. Timeout is 10,000 ms by default.

The byte-exact transcript, proof, HKDF and key-confirmation constructions are normative in the handshake vector. Any lifecycle role advertised by an extension is a hint only. Authority is resolved from the receiver’s in-force set of signed authority statements (§6.6), never self-declared handshake data.

5.2.1 Core Secure key schedule

The following construction is normative. lp(x) is the ASCII decimal byte length of x, then :, then the bytes of x. Every quoted label is an exact, case-sensitive UTF-8 byte string with no trailing NUL. HKDF is RFC 5869 HKDF-Extract followed by HKDF-Expand using SHA-256; the full transcript hash is the salt, not a zero or empty salt.

T  = handshakeTranscriptV2(clientOffer, serverOffer, selectedExtensions)
TH = SHA-256(T)                                      // exactly 32 bytes
sessionId = lowercaseHex(TH[0..15])                  // first 16 bytes
SS = X25519(localPrivateKey, peerPublicKey)          // exactly 32 bytes

HKDF32(info) = HKDF-SHA256(IKM=SS, salt=TH, info=UTF8(info), L=32)

clientFinishedKey = HKDF32("mmp-finished-v2 client")
serverFinishedKey = HKDF32("mmp-finished-v2 server")
clientToServerKey = HKDF32("mmp-aead-v2 client-to-server")
serverToClientKey = HKDF32("mmp-aead-v2 server-to-client")

proofPayload(role) = UTF8("mmp-handshake-proof-v2\n") ||
                     lp(role) || lp(lowercaseHex(TH))
proof(role) = Ed25519-Sign(identityPrivateKey(role), proofPayload(role))

confirmPayload(role) = UTF8("mmp-key-confirm-v2\n") ||
                       lp(role) || lp(lowercaseHex(TH))
keyConfirmation(role) = HMAC-SHA256(finishedKey(role), confirmPayload(role))

• —sessionId is derived directly from the transcript hash; it is not an HKDF output.
• —The X25519 shared secret and every finished or traffic key are raw 32-byte values. An invalid peer key or all-zero shared secret MUST abort authentication.
• —The server sends the server proof and server key confirmation in server-hello; the client sends the client proof and client key confirmation in client-finish.
• —Proofs are unpadded base64url Ed25519 signatures. Confirmations are unpadded base64url HMAC-SHA256 values and MUST be compared in constant time.
• —The two traffic keys feed only their named direction of the sealed envelopes, cmb-encrypted and control-encrypted (§18.2.1), which share that direction’s sequence. Reversing or reusing a direction key is non-conformant.

Deprecated. The one-frame handshake that pins its own unproven keys is a Legacy Import/migration protocol and MUST NOT be accepted by Core Secure. state-sync is also retired: hidden state never crosses the wire.

5.2.2 Handshake over a relay

Over a relay (§4.4) both peers are WebSocket diallers of the relay, so the dialler and listener roles of §5.2 do not exist, and a peer’s arrival, departure and restart are relay events rather than connection events. A relay session is the §5.2 exchange and the §5.2.1 key schedule, unchanged, carried in routing envelopes addressed to the peer (§4.4.4), with the following rules.

• —Roles. The node with the smaller nodeId is the client, comparing the lowercase wire forms (§3.1.1) bytewise — the order §5.1 uses on the LAN. The node with the larger nodeId MUST NOT send client-hello to that peer over the relay, and a node MUST ignore a relay client-hello from a peer whose nodeId is larger than its own. Both sides apply one order, so there is no simultaneous open to resolve.
• —Trigger. When relay-peers lists a peer that is not offline (§4.4.2), or relay-peer-joined announces one (§4.4.3), the client-role node SHOULD send client-hello to it if it holds no relay session with that nodeId. An announcement for a peer it does hold a session with is ambiguous: the peer may have restarted and replaced its own relay connection (§4.4.7), losing the session’s keys, or the relay may simply have announced it again. A node MUST NOT re-handshake on that announcement alone, which would supersede working sessions. It SHOULD instead probe: send a ping to that peer, at most once a second per peer. A live peer answers pong; a restarted one holds no session and answers UNKNOWN_SESSION (below), which tells the client to re-handshake.
• —Addressing. Every handshake frame and every sealed frame of a relay session MUST be sent in an envelope whose to is the peer’s nodeId; none is ever broadcast. A node MUST refuse a client-hello or server-hello whose nodeId differs from the envelope’s from, and MUST accept a session’s frames only from envelopes whose from is that session’s peer, arriving on the relay connection the session was established on.
• —Timeout. The server-role node MUST require client-hello first and client-finish before any non-handshake frame from that peer, exactly as a listener does. Either role MUST abandon, retaining no state, a handshake that has not confirmed within 10,000 ms of its first frame. The client SHOULD retry with exponential backoff (for example from 1 s, doubling, capped at 60 s) and MUST NOT have more than one handshake in flight per peer on one relay connection.
• —Supersession. A handshake that confirms for the same (nodeId, identity key) as an existing session on that relay connection supersedes it, once each side knows the other holds it. The server supersedes when it admits the new session (§5.8.1; in an ungated room, when client-finish verifies). The client cannot, since its client-finish may have been lost, so: the server MUST send a sealed frame on a relay session as soon as it admits it, and that frame is the mandatory cmb-anchors (§9.4). The client MUST NOT supersede its existing session until a sealed frame other than an error opens on the new session; if none opens within the handshake timeout, it MUST abandon the new session, retaining no state, and keep the old one. When a side supersedes, it discards the old session’s keys and counters and refuses frames sealed under the old sessionId from then on. Supersession itself sends nothing. This is how a peer restart recovers. A handshake that proves a different identity key for the nodeId never supersedes: a nodeId keeps one key (§3.4), the new handshake is refused, and the existing session is unaffected.
• —An unconfirmed hello changes nothing. A handshake in progress MUST NOT tear down, pause or alter a confirmed session. Only confirmation supersedes; a timeout, a failure or an abandoned handshake leaves the confirmed session exactly as it was, so a forged or replayed client-hello costs the peers nothing.
• —Teardown. A node MUST tear down every relay session with a nodeId when relay-peer-left names it, and every relay session on a relay connection when that connection closes; tearing down discards the session’s keys and counters. A node that closes a confirmed relay session for any other reason except supersession SHOULD first send, sealed in that session and addressed to the peer, an error with a Close action (§7.2): 1010 SESSION_CLOSED with the reason in message, unless another code names the reason. A sealed error with a Close action ends the session at its receiver too, and the client-role side then begins a new handshake, with backoff, except after 1009, which it does not retry automatically (§7.2). A node whose handshake fails or is refused MAY send 1006 or 1007 in clear; like every clear error it changes nothing at the receiver (§7.1). 1009 is found only after both proofs validate, so it is sent sealed on the session (§5.2).
• —Sequence. Sealed frames follow §18.2.1. A relay may drop frames and never retransmits them, so a gap is final: the receiver MUST close the session, and SHOULD first send a sealed 1010 SESSION_CLOSED, and the client re-handshakes; nobody waits for a missing sequence. A frame that fails authentication does not advance the receive sequence and does not close the session, and neither does a replayed one, since the relay can inject and replay frames. A sealed frame naming a sessionId the receiver does not hold is discarded and answered with UNKNOWN_SESSION (below).

Unknown session. A node that receives, from a relay from, a sealed frame (cmb-encrypted, or any other sealed envelope) naming a session it does not hold, or a ping from a from it holds no relay session with, SHOULD answer with error 1011 UNKNOWN_SESSION:

{ "type": "error", "code": 1011, "message": "unknown session",
  "detail": "session:<32 lowercase hex>" }

• —detail names the session as session: followed by its 32 lowercase hex characters when the triggering frame named one, and is absent when it did not (a ping). The error travels in clear, as a routing-envelope payload addressed to the sender: the node holds no session to seal it with.
• —A node MUST NOT send it more than once a second per relay from, and SHOULD also cap its replies across all senders (for example 2 a second, with a burst of 8), which bounds the replies a stream of stale or forged frames can draw.
• —The client-role receiver, if the peer is present on the relay, SHOULD begin a new handshake, but only when the error’s detail names the session it holds with that peer or it has a probe ping outstanding to that peer, and it is not already waiting for a newer session with that peer to supersede the one named, and no faster than its handshake retry backoff. It MUST keep its existing session until the new one supersedes it, so a peer’s restart produces no peer-left at the application. The server-role receiver ignores it: the client will re-handshake.
• —Like every error frame it is informational (§7.2). It MUST NOT tear down a session by itself. Anyone on the relay path can forge it, and the worst it can do is prompt a handshake that only a peer holding the right key can confirm.

Why the session, not the relay, decides. The relay’s view of a nodeId is weaker than a handshake (§4.4.1), so nothing a relay says can end a session both peers confirmed, except relay-peer-left and the loss of the relay connection, and those cost only a re-handshake. Everything that would let a third party end or replace a session — a hello, an error, a forged or replayed frame — either needs the peer’s keys to confirm or changes nothing.

5.3 Connection State Machine

Implementations MUST NOT process any non-handshake frame in the AUTHENTICATING state.

A relay session (§5.2.2) passes through the same states. It enters AUTHENTICATING when the client sends, or the server accepts, client-hello; it becomes CONNECTED on confirmation; and it returns to DISCONNECTED on timeout, failure, supersession by a newer confirmed session for the same (nodeId, key), relay-peer-left, the closing of the relay connection, a sequence gap, or a sealed error with a Close action (§7.2). An existing CONNECTED session stays CONNECTED while a newer handshake with the same peer is AUTHENTICATING.

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 (SYM reference default: 10,000 ms). Upon receiving ping, a node MUST respond with pong. If no frame is received from a peer within the heartbeat timeout (SYM reference default: 120,000 ms), the connection MUST be closed. These defaults are local policy, not interoperability constants.

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 Rooms

A node MUST declare membership in one mesh room at handshake time via the explicit room field (Section 5.2). A room is a named cohort of nodes that exchange application-layer frames only with each other. Rooms let an operator host multiple mutually isolated meshes on the same relay or LAN segment.

Room identifier syntax. A room identifier is a string of [a-z0-9-_.]+, max 64 characters, case-sensitive. The literal string default is explicit; absence is invalid in Core Secure.

Protocol guarantee. A node in room R_A MUST NOT exchange application-layer MMP frames with a node in room R_B when R_A ≠ R_B. Room is part of the authenticated handshake transcript and every signed record assertion. A mismatch fails authentication; application traffic never begins.

Layer placement. A mesh room is a Layer 2 (Connection) concept. The application layer SHOULD declare its room at SDK initialisation. A relay MAY scope routing by room as defense in depth, but endpoint authentication is authoritative: the room is signed in the handshake transcript and bound into each record signature. A receiver MUST reject a frame whose authenticated room differs from its own, even if a relay misdelivers it. LAN peers perform the same check during authentication and close on mismatch with ROOM_MISMATCH.

Recommended naming convention (non-normative). The protocol does not parse room identifiers beyond the character set and length checks above. Operators of meshes with more than a handful of rooms 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 grouping.

SVAF and room filtering. Authentication and room filtering run before SVAF. A record from a different room never reaches the evaluator. For an authenticated same-room record, category verdicts inform one whole-record admission result (§9.2).

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

5.8.1 Room Admission

Consent to hear is not consent to believe. Admission decides whether a node’s frames are exchanged at all. It says nothing about whether their content is true, and a receiver that treats membership as credibility has confused the two. Every admitted record is still evaluated by SVAF (§9.2), and admission gives it no standing there.

A room name is not a credential. §5.8 makes a room a named cohort, and every discovery path — LAN advertisement, same-host registry, relay routing — turns knowledge of that name into membership without asking anyone. A deployment that needs membership to be a right rather than a string MAY gate a room. A gated room has exactly one owner, identified by node identifier and Ed25519 public key together. A node that enforces a gated room MUST have the owner’s nodeId and key pinned out of band, for that room: it selects the owner by the room, never by anything a grant or a peer carries. The room identifier default MUST NOT be owned: it is the public mesh. Because rooms are carried verbatim and never mapped to a service type (§5.1), every §5.8-valid identifier denotes exactly one room and any of them other than default MAY be owned (but see the migration note in §5.1 on the room sym).

The room-join grant. A node joins a gated room by presenting a grant signed by that room’s owner. The grant MUST bind, under one signature, the room identifier, the grantee’s node identifier, the grantee’s public key, and an expiry. A grant that names a grantee but binds no key is a bearer token: anyone holding the bytes can present it, and the verifier MUST refuse it.

The key must be proven, not asserted. A handshake field stating a public key proves nothing — the key an impostor would have to state is printed inside the grant it is holding. A verifier MUST compare the grant’s bound key against a key the peer proved possession of during the handshake, and MUST refuse when no such proof is available. Failing closed here costs a deployment nothing it had; failing open hands the room to whoever copied a file.

Presenting the grant: the room-join frame. The handshake transcript has no field for a grant, and a grant carried in a hello would be presented before anything was proven. A grant is therefore presented inside the confirmed session, where the key it binds can be compared with the key the session proved. It travels as a sealed control frame (§7.1, §18.2.1):

{ "type": "room-join",
  "grant": { "type": "room-join", "room": "<room>",
             "grantee": "<grantee nodeId>", "granteeKey": "<43-char base64url>",
             "grantedBy": "<owner nodeId>", "grantedAt": 1786611600000,
             "expiresAt": 1786698000000, "sigAlg": "ed25519",
             "sig": "<unpadded base64url>" } }

signed payload = UTF8("mmp-room-join-v1
") || lp(room) || lp(grantee) ||
                 lp(granteeKey) || lp(grantedBy) ||
                 lp(decimal(grantedAt)) || lp(decimal(expiresAt))

• —The grant’s signature. grant.sig is the owner’s Ed25519 identity-key signature over the payload above, using the §8.8.4 lp encoding, and is verified by the one rule of §18.3.2. granteeKey is the grantee’s identity key as unpadded base64url, and grantedAt and expiresAt are integer milliseconds. The frame adds no signature of its own; the session protects it.
• —Sending. A node that holds a grant for its room MUST send room-join on every newly confirmed session, as its first control frame, after both proofs validate and its own key-registry check of the peer (§3.4) has passed. Both ends of a session between two grantees send one.
• —Pending admission. In a gated room, a receiver MUST hold each newly confirmed session as pending, and MUST NOT process any content-bearing frame on it until it is admitted (the per-frame door, below). It admits the owner at once, recognised by the session’s proven nodeId and identity key together matching the pinned owner. Any other session it admits only on a room-join that arrives within the handshake timeout (10,000 ms by default, §5.2), and it MUST close a session that presents none in time. It MUST decide admission on a room-join before it handles the session’s next frame, so no frame is judged against a decision still being made.
• —Verification. The receiver MUST first check the frame against room-join.schema.json, so the times are integers before any signature work, and then verify the grant against the pinned owner key for this room under §18.3.2. It MUST require all of the following: room is its own room; grantedBy is the pinned owner’s nodeId; grantee is the session’s proven nodeId; granteeKey is the session’s proven identity key; expiresAt is no more than 24 hours after grantedAt (the cap below); and, allowing 5 minutes of clock skew, the grant is already valid (grantedAt is no more than 5 minutes ahead of the receiver’s clock) and not expired (the clock is no more than 5 minutes past expiresAt). If every check passes it admits the session; if any fails it closes the session. A grant copied onto another key’s session therefore fails, whoever presents it.
• —Expiry closes the session. A session admitted on a grant stays admitted only while the grant lasts: the receiver MUST close it when its clock reaches the grant’s expiresAt. A grant admitted inside the 5-minute skew allowance after its expiresAt is therefore closed at once. The grantee presents a fresh grant on a new session.
• —Otherwise ignored. A room-join on a session already admitted, or in an ungated room, MUST be ignored.

Expiry is the revocation window. A grant MUST NOT be accepted with a lifetime exceeding 24 hours, and the cap MUST be enforced by the verifier, not only by the issuer: a cap only the issuer honoured is a suggestion, and a receiver that accepts a ten-year grant has no window at all. Revocation is live gossip with no catch-up replay, so a peer that is offline when a revocation publishes never learns of it. The grant’s own lifetime is therefore the true exposure, and this number is that exposure rather than a bound on it.

The door is consulted per frame, not once per greeting. Admission is decided from the handshake and the grant presented after it, but a receiver MUST record that decision and consult it on every frame that carries meaning. A receiver MUST NOT process a record, a message, or any other content-bearing frame from a peer it refused, nor from a peer for which no admission decision was ever made while the room is gated. This is not a restatement of §5.8: an implementation can satisfy the handshake rule and still dispatch content from a node that never greeted it, because frame handling is commonly attached to a transport before, or independently of, the handshake that would have judged it. Handshake frames MUST NOT be gated this way — a grant-holder could then never join. Liveness frames MAY be answered, since a keep-alive tells a refused peer nothing that a closed connection does not.

A door governs a room, not a node’s voice. Admission decides what is exchanged within a room; it does not make a node inaudible outside one. A receiver that also hears a band the room does not scope — a discovery advertisement, a broadcast channel, any transport it shares with non-members — MUST NOT ingest what arrives there as room content, because nothing on that band passed the door. This is not hypothetical: an independent implementation built against this specification was measured on 2026-09-16 emitting an adversarial node’s records to every peer on the local segment without ever joining the room, and its door counted nothing, correctly — the node never knocked. A door that is never approached refuses nothing, and a receiver MUST NOT read that silence as evidence of admission.

What the door cannot do. In an ungated room there is no admission to enforce: declaring the room at handshake is membership, by §5.8. A receiver in an ungated room therefore has no basis to refuse an unknown peer’s frames on admission grounds, and MUST NOT report the absence of grants there as evidence that nobody was admitted — nothing was required. An interface that reports a room’s gating MUST distinguish ungated from not determined; the two call for opposite responses and collapsing them into one false negative is the failure this clause exists to prevent.

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 room as an ordinary node (§5.2, single room on the wire) and presents a boundary to exterior gateways over a separate transport. It is not one handshake declaring several rooms — 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 room boundary) by construction. Implementation status: the reference prototype does not yet do this — see below.

Its own lineage means ONLY its own, and the reason is not tidiness. A projection emitted outward MUST NOT carry a lineage reference to the interior record it was admitted from, even though the exterior could never dereference one. By §8.2.1 a CMB’s key is a content address — a SHA-256 over the canonical serialization, which two conforming implementations compute identically for the same logical block. A reference to an interior record is therefore a hash of that record’s content, published outside the boundary. An exterior observer cannot open it, but can guess a candidate interior content, compute its address, and compare — confirming the interior’s contents without ever being admitted to it. Where the interior’s vocabulary is small or enumerable, that is not a narrow leak but a complete one. The determinism that makes a content address work for lineage, dedup and citation is the same property that makes it an oracle across a boundary, and “the reader cannot dereference it” is the argument for safety that gets this wrong: inability to dereference removes the audit value while leaving the confirmation intact.

The audit trail this appears to sacrifice is not lost, only relocated to where the entitlement is. A gateway SHOULD record, in its own store, which admitted interior observations a given outward projection derived from. That is readable by the gateway and by anyone with interior access — precisely the parties entitled to see both sides — and unlike a pointer the exterior cannot open, it can actually be followed. Where a gateway must later prove such a derivation to a third party, it MAY publish a salted commitment over the interior key rather than the key itself, revealing the salt when it chooses to prove the link; a commitment carries no oracle, because a correct guess cannot be confirmed without the salt.

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) room; the gateway participates in that interior room 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 reachable from any retained entry by recursively following verified metadata.lineage.parents 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-category 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 category 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 against its own in-force set (§6.6) at the moment it processes the CMB — never from the createdBy string, never from the peer’s advertised handshake role, and never from a time the CMB claims:

• —If the author resolves to validator or above (validator, admin or the 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.
• —A scoped grant (§6.6.2) confers this only on a parent CMB that is inside the grant’s scope, judged from that parent’s own signed fields. A receiver MUST NOT judge it from the validation CMB’s own fields or tags. When a validation CMB names several parents, each is judged on its own: a parent inside the scope advances, and one outside it does not. An issuer, which admits nodes, confers no validation anywhere.

The transition is the receiver’s own record, made once, against its in-force set at the moment it is made; a later revoke does not undo it in that store (§6.6.10). An outcome that several parties must agree on is not decided this way: the environment it belongs to decides it once and records it (§6.6.10).

This prevents agent-level spoofing of validation authority. An agent cannot self-promote to validator by including “founder” or “validator” in its CMB text categories. The authority is bound to the node’s cryptographic identity and key, through an in-force grant from the anchor or an admin (Sections 3.5.1 and 6.6).

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 the CMBs of a validator, an admin or the anchor receive (§6.4) — on the basis of a handshake lifecycleRole or a createdBy string. That origin weight MUST derive from the author’s role as resolved against the receiver’s in-force set (§6.6) when the weight is applied, 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 role or above. 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, how a node decides which authority is in force, and how authority is withdrawn — the mechanism §6.5 gates on.

Authority is a function of a set. A node’s view of authority is computed from the set of verified authority statements it holds, and from nothing else: not the order they arrived in, not the time on any clock, not the session that delivered them. Statements name one another by the hash of their signed bytes, so the graph they form is fixed when they are signed. Two nodes that hold the same statements under the same pinned anchor MUST resolve the same authority. No timestamp takes part in resolution: a statement MAY carry a time as information (issuedAt), and a node MUST NOT let that time, its own clock or the order of arrival affect what is in force.

Why (informative). The rule this section replaces resolved a node’s role at a time T by replaying grants and revokes in the order of times their signers chose. Any role holder could grant further down, grants were gossiped in any order, and revoking a grantor cascaded. Every node therefore had to rebuild one timeline from signer-chosen times, statements by many writers, and arbitrary arrival order, with nothing to order them. That is consensus without a consensus mechanism. An implementation of it diverged on arrival order, accepted backdated revokes, could be flooded until honest records were evicted, and resolved some revoke patterns in exponential time. Resolving a set removes the ordering problem instead of patching it.

6.6.1 The anchor

• —A pinned key set with a threshold. The anchor is configured out of band as a set of n distinct Ed25519 public keys, 1 ≤ n ≤ ANCHOR_MAX_KEYS (16, §19.1), and a threshold t, 1 ≤ t ≤ n. Each key MAY be pinned with the nodeId of the node that holds it. The pin is configuration a receiver already trusts, never a claim on the wire: a node MUST NOT learn, change or persist its pin from any frame.
• —The single anchor stays valid. A pin of one nodeId and its key, as earlier revisions defined it, is the set of one key with t = 1.
• —Anchor-level statements. A statement whose authorisedBy is "anchor" is valid only if it carries signatures over its payload (§6.6.3) by at least t distinct pinned keys, each verifying under §18.3.2. Each entry’s key is unique within the statement (§6.6.3, rule 1), so a copy that repeats a key is not well formed and none of its signatures is checked. Entries by keys that are not pinned, and signatures that do not verify, are not counted. A node stores and relays only the entries it counted. Each copy of a statement is judged on its own entries: a node MUST NOT combine entries from different copies, so that validity never depends on which copies a node happened to receive. The key holders collect their t signatures among themselves, out of band.
• —The anchor is not a granted role. No grant confers anchor. Under a threshold of 1 each pinned member alone is the anchor, whether the pin holds one key or several: its single signature makes an anchor-level statement valid, and a CMB it authors resolves as the anchor (§3.5) when its nodeId is pinned with its key. Under a higher threshold no single node is the anchor, and each key holder holds whatever roles in-force grants give it.
• —Re-pinning. Replacing the pin out of band is the last resort. It re-judges every anchor-level statement against the new pin: a statement that still carries t valid signatures from the new set stays valid, and the rest fall away with everything they authorised. Statements do not name the pin. A re-pin that keeps a threshold of the old keys, for example to drop one compromised key of three, therefore keeps what those keys signed. A re-pin to new keys starts authority again. After a re-pin a node re-verifies the copies it holds: a copy that no longer counts is replaced by any copy that does, which anti-entropy brings from a node that holds one. A node keeps the statements it holds independently of its pin, and judges them again under the current pin whenever the pin changes or it loads them. It MUST NOT delete a statement because it fails under the current pin, so a re-pin, or a mistyped pin, destroys nothing: what fails under one pin counts again under a pin it meets.
• —No pin. Where no anchor is pinned, nothing is in force (§6.5), and there is no authority root, since a root names a pin (§6.6.7). A node with no anchor pinned therefore sends no authority-digest, pulls nothing, answers no authority-fetch, and stores and relays no authority statement it receives; statements it already holds stay as they are, to be judged when a pin is configured. It MUST NOT rate-limit or penalise a session for authority statements it cannot judge.

6.6.2 Roles and delegation

• —Delegating roles are admin, validator and issuer: their holders may sign statements, and a bucket counts their grants against its delegate quota (§6.6.6). Lifecycle authority (§3.5) belongs to admin (canonical) and validator (validated) only. An issuer has none, so a service that admits seats need not hold validation authority over anything. Non-authority roles are participant and extension roles, named as §7.3 names extension types (<extension>-<name> or x-<vendor>-<name>, lowercase, at most 64 characters). A non-authority role confers no lifecycle authority, no admission weight above participant, and no right to sign any statement. MMP authority roles are therefore the anchor, admin, validator and issuer. An extension MAY give a non-authority role meaning in its own domain, such as a seat in a hosted world; it MUST NOT turn one into an authority role.
• —A node with no in-force grant is a participant. A participant grant adds only a vouched key and a signed record that someone above admitted the node.
• —Scope. A grant MAY carry a signed scope: an extension namespace and a path, such as xmesh-world:w1 or xmesh-world:w1/region-a, of at most AUTHORITY_SCOPE_MAX (256) characters (the grammar is in the schema). No scope is the whole mesh. A grant’s scope MUST equal or narrow its authorising grant’s: the same string, or that string followed by / and more segments. A grant under a scoped grant therefore MUST carry a scope, because leaving it out means the whole mesh, which would widen. An anchor-level grant may have any scope or none. A grant whose scope would widen its parent’s is invalid (§6.6.3, rule 4). Scope paths are opaque: they are compared exactly, byte for byte, and never normalised (no case folding, no percent-decoding, no resolution of . or ..). No segment may consist only of dots, so xmesh-world:w1/../w2 is not a scope at all, and nothing can look like a step up to a reader that would resolve it. Narrowing adds whole segments: xmesh-world:w10 does not narrow xmesh-world:w1. The lifecycle authority and the elevated admission weight of a scoped grant apply only to CMBs inside its scope. The extension that owns a namespace defines which CMBs are inside each of its scopes, for example by room or by world. A receiver that does not implement a namespace treats no CMB as inside its scopes, so a scoped grant gives it no lifecycle authority. A scope does not change who may revoke or endorse a grant, nor what its holder may sign beyond keeping its own grants inside it.
• —Depth. The anchor is at depth 0. An anchor-level statement is at depth 1, and a statement authorised by a grant at depth d is at depth d + 1. A statement deeper than MAX_DELEGATION_DEPTH (4, §19.1) is invalid. Admins may grant admins, so the role table alone does not bound depth; the cap does.
• —Why four. The deepest chain with a separately accountable party at every hop is anchor → deployment admin → world admin → seat issuer → seat. Those are: the anchor’s key holders; the operator of a hosting deployment; the operator of one world hosted there; the service that admits seats to that world, which holds the issuer role so that it admits seats without validation authority; and a seat. That is four grants. A fifth hop would add no new kind of boundary, because what it would express is expressed by granting wider, not deeper. Each extra hop is one more key whose compromise reaches everything below it, and one more link that every check walks. The cap also bounds every chain to four grants, so a revoke check walks at most three ancestors and a fetched chain is at most four statements. The issuer leaves the arithmetic of §6.6.6 as it is: it is a delegating grant in its world admin’s bucket, and its seats are non-authority grants in its own. The draft bound of 8 belonged to the time-replay rule, under which validators promoted validators.
• —What MMP authority governs (informative). Grants decide who may attach to a mesh and act in it: hosts, seats, publishers, validators. Roles inside a simulation or a game, such as a commander or a scout, are simulation data kept in that environment’s own records. They are not MMP grants. A world’s own laws, fines and verdicts are that world’s records too: they are not MMP validation, and MMP authority neither grants nor checks them. A seat grant is per admitted node: it names one nodeId and key, not a sitting, so a node that comes back keeps its seat until the grant is revoked. With the constants of §19.1 a world admin’s 16 issuers admit up to 16 × 256 = 4,096 nodes per grant it holds. Grants do not expire, and no expiry is intended: authority ends by revoke.

6.6.3 Statements

Three statements carry all authority. A grant confers a role on a subject, a nodeId together with its Ed25519 key, optionally within a scope (§6.6.2). A revoke names, by id, the grants it removes. An endorse names, by id, the grants and revokes to keep in force after a revoke has cut them off from the anchor (§6.6.5). Each names in authorisedBy the authority it is made under: "anchor" for an anchor-level statement, otherwise the id of the signer’s own grant. A signer that holds several grants names the one whose role permits the statement and, for a revoke or endorse, one that stands above its targets (§6.6.4). Every statement carries a nonce of 16 random bytes, so a fresh grant of the same role to the same subject is a different statement.

{ "kind": "grant",
  "authorisedBy": "anchor" | "auth-<64 lowercase hex>",
  "subject": { "nodeId": "<uuid>", "key": "<Ed25519 public key, base64url>" },
  "role": "admin" | "validator" | "issuer" | "participant" | "<extension role>",
  "scope": "xmesh-world:w1",                       (optional; omitted means the whole mesh)
  "nonce": "<16 random bytes, base64url>",
  "issuedAt": 1786611600000,                       (optional; information only)
  "sigs": [ { "key": "<base64url>", "sig": "<Ed25519 signature, base64url>" } ] }

{ "kind": "revoke",  "authorisedBy": "...", "targets": ["auth-...", ...], "nonce": "...", "sigs": [ ... ] }
{ "kind": "endorse", "authorisedBy": "...", "targets": ["auth-...", ...], "nonce": "...", "sigs": [ ... ] }

Canonical signed bytes and identity. lp and decimal are as in §8.8.4. Targets are unique on the wire, and their wire order is not signed. A nodeId is signed in its canonical lowercase RFC 4122 text form, 8-4-4-4-12 lowercase hexadecimal digits. Any other spelling is not well formed, so one node has one spelling, and one statement one id.

payload = UTF8("mmp-authority-v1\n") ||
  lp(kind) ||
  lp(authorisedBy) ||
  grant:            lp(subject.nodeId) || lp(subject.key) || lp(role) || lp(scope or "")
  revoke, endorse:  lp(decimal(targetCount)) || concat(lp(target) for bytewise-sorted targets)
  || lp(nonce) ||
  lp(decimal(issuedAt) or "")

id  = "auth-" || lowercase hex(SHA-256(payload))
sig = Ed25519(signing key, payload)         (pure Ed25519, no prehash; unpadded base64url)

The id excludes the signatures. A statement re-signed by a hedged signer (§17.4), or carrying a different subset of anchor signatures, is the same statement. A node MUST compute the id itself; no frame carries a statement’s own id. A non-anchor statement carries exactly one signature entry, whose key is the key that signed it. Every signature verifies under the one rule of §18.3.2.

Validity. A statement is valid when all four hold:

1. Well formed. It validates against authority-frame.schema.json; every base64url field is canonical (a key and a signature decode to 32 and 64 bytes, a nonce to 16); its subject nodeId is canonical (above); its subject key is the encoding of an Ed25519 point of prime order (§18.3.2), so no grant can name the identity or any other small-order or mixed-order key; issuedAt, if present, is at most 2⁵³ − 1; its scope, if present, follows the scope grammar; its targets are unique and number 1 to AUTHORITY_MAX_TARGETS (64); and the keys of its signature entries are unique, so a statement that repeats a key is not well formed. A node checks this rule before any signature work. The schema and the reference construction accept exactly the same shapes, with two exceptions JSON Schema cannot express: the point check, and unique keys across entries (the schema refuses only identical entries).
2. Rooted and shallow. Following authorisedBy from the statement through statements the node holds reaches "anchor" within MAX_DELEGATION_DEPTH links. If a link within that walk is not held, the statement is pending, not invalid (§6.6.8). If the walk would need more links, the statement is invalid.
3. Signed. An anchor-level statement as §6.6.1 says. Any other by the key its signature entry names, which MUST be the subject key of its authorising grant, verifying under §18.3.2.
4. Permitted. Its authorising statement is a valid grant (or the anchor), and that role permits it under §6.6.2: the role table for a grant, a delegating role for a revoke, an admin or the anchor for an endorse. A grant’s scope equals or narrows its authorising grant’s.

Validity is static: it depends on the statement and its chain, never on revokes, endorsements or quotas. A receiver MUST check it on ingest and MUST discard an invalid statement, which it MUST NOT store or relay.

6.6.4 Resolution

Over the set of valid statements a node holds:

• —The chain of a statement is the grants above it: its authorising grant, that grant’s authorising grant, and so on, up to and not including the anchor. A grant g is above s if g is on the chain of s. The chain is fixed by the hashes: it never depends on what is in force.
• —A bucket is the statements that share an authorisedBy; the anchor-level statements form one bucket. Everything in a bucket is signed by one signer under one grant, at one depth. A bucket keeps statements: its own, and those its endorses rescue (§6.6.6).
• —A revoke r may remove a grant g when r is anchor-level or is authorised by a grant above g. These are the anchor, and the holders of grants on g’s chain above it. No signer can remove its own grant, a grant above its own, or a grant on another branch.
• —An endorse e may rescue a grant or revoke s when s is not anchor-level, and e is anchor-level or authorised by a grant above s’s authorising grant. These are exactly the signers that may remove s’s authorising grant. An endorse is never rescued: an endorse that names an endorse does nothing to it.
• —A revoke or endorse acts target by target. A target it may not remove or rescue, a target the node does not hold, and, for a revoke, a target that is not a grant, are unaffected, and the statement still applies to its other targets.
• —A statement is cut by a revoke when its authorising grant is not in force and, walking up its chain past the grants that are dead, the first grant that is not dead is removed. When that first grant is over quota instead, the statement is cut by a quota.
• —A statement is alive when it is anchor-level or its authorising grant is in force. A grant or revoke that is not alive is rescued when it is cut by a revoke, an in-force endorse that may rescue it names it, and that endorse’s bucket keeps it (§6.6.6). A statement cut by a quota is never rescued. A grant is removed when an in-force revoke that may remove it names it.
• —A revoke or endorse is in force when it is alive and its bucket keeps it; a revoke also when it is rescued. A grant is in force when it is not removed, and either it is alive and its bucket keeps it, or it is rescued. Every in-force statement is kept by exactly one bucket: its own, or its rescuer’s.

Every statement therefore has exactly one status: invalid, pending, dead (valid, but neither alive nor rescued), removed, over quota (no bucket has room for it), or in force. The authority vector pins these statuses. A node MUST resolve its in-force set as this algorithm does, and MAY compute it incrementally, provided the result is the same:

resolve(H):                       H = the valid statements a node holds, as a set
  index H: bucket each statement by its authorisedBy; list, for every id, the
           revokes and endorses that name it as a target, in ascending id order
  F := {}                                               the in-force set
  for d := 1 .. MAX_DELEGATION_DEPTH:
    phase A: revokes and endorses at depth d
      for each bucket B at depth d whose authorising grant is in F (or the anchor's):
        keep(B, s) for each revoke and endorse s of B, in ascending id order
      for each other bucket at depth d: its endorses are dead; its revokes that are
        cut by a revoke are rescue candidates, the rest are dead
      rescue(s) for each candidate s, in ascending id order
    phase B: grants at depth d
      for each bucket B at depth d whose authorising grant is in F (or the anchor's):
        each grant g of B with removed(g) is removed; keep(B, g) for each other
        grant, in ascending id order
      for each other bucket: a grant not cut by a revoke is dead; one that is removed
        is removed; the rest are rescue candidates
      rescue(g) for each candidate g, in ascending id order
  return F

keep(B, s):   if B has kept Q(B) statements, or s is a delegating grant and B (not the
              anchor's) has kept AUTHORITY_DELEGATE_QUOTA of them: s is over quota;
              otherwise B keeps s and s is in F
rescue(s):    for each endorse e in F that names s and may rescue it, in ascending id
              order: keep(bucket of e, s), stopping at the first that has room;
              s is over quota if one tried and none had room, dead if none could
cut by a revoke(s): past the dead grants on s's chain, the first is removed
removed(g):   some revoke r in F names g, and r may remove g   (r is settled: phase A)

• —The order is well founded. An endorse that may rescue a statement sits at a lower depth than it, and the endorse’s own bucket is settled before any rescue it keeps. A revoke that may remove a grant sits at the same depth or lower, and phase A runs before phase B. Whether a statement is cut by a revoke or by a quota depends only on grants above it, at lower depths. A revoke can never remove a grant on its own chain, and an endorse can never rescue one, since either would need a statement above itself. So no statement’s standing depends on itself, and the rescues one bucket keeps are served in ascending id order.
• —Cost is linear. Each statement is validated once, walking at most four links. It is placed in one bucket once. Each (revoke or endorse, target) pair is checked once against a chain of at most four, and deciding whether a statement was cut off walks at most three grants. Resolution is therefore O(S + T) for S statements naming T targets in all, choosing the lowest ids of a bucket by linear-time selection (sorting a bucket, or the endorses that name one target, costs a logarithmic factor). No rule recurses, so the revoke patterns that made the replay rule exponential have nothing to multiply.
• —Roles follow the key. A node’s roles are those of the in-force grants whose subject is its nodeId and its key, each with its scope, plus anchor for each pinned member of a threshold-1 anchor (§6.6.1). Its lifecycle authority over a CMB (§3.5) is the highest of the roles whose scope contains that CMB: anchor or admin (canonical), then validator (validated). Issuer and the non-authority roles confer none.

6.6.5 Revocation and endorsement

• —Revocation is effective. A removed grant confers nothing. Everything it authorised, and in turn everything those authorised, is dead unless rescued. Removing an admin’s grant takes its whole subtree with it, in one statement.
• —Dead statements. A removed signer’s dependents are dead. A node MUST NOT relay a dead statement and MAY drop it, unless it is in the node’s live set (§6.6.7) as a grant on the chain of an in-force statement. A dropped statement that arrives again is resolved afresh like any other: it is dead unless an endorse has rescued it in the meantime, and a node that dropped it gets it back only from a node that kept it (§6.6.7).
• —Nothing is un-revoked. While its revoke is in force a grant stays removed. To restore authority, a signer above issues a fresh grant: the fresh nonce makes it a different statement. A fresh grant does not revive the old grant’s dependents, because they name the old id. Demotion is a revoke, followed if wanted by a fresh grant of a lesser role.
• —Rescue reconnects what a revoke cut off. An endorse keeps the grants and revokes it names, and everything that hangs from them, once a revoke has cut them off from the anchor. One use is when an admin leaves and the anchor keeps the validators it appointed. Another is when a key is retired and the grants its holder made should stand. Rescue never brings back a statement cut off by a quota: a grant over quota stays out, and so does everything below it. The endorser answers for what it names. Its bucket keeps what it rescues, counted like its own statements, and a rescued delegating grant takes one of its delegate slots (§6.6.6), so rescuing a delegate costs exactly what granting one would.
• —An endorse never restores its signer. The removed signer’s grant stays removed. Anything it signs afterwards is a new statement that no endorse names, because an endorse can only name statements that already exist: their ids are inside its signed bytes. A removed signer therefore cannot regain authority through an endorsement, and an endorse by a statement’s own signer rescues nothing: it is in force only while that signer’s grant is, and then the statement needs no rescue.
• —An endorse is never rescued. When an endorser’s own authority goes, what it rescued is cut off again. A signer above that wants it kept endorses it directly, which it may, since it stands above everything the endorser could reach.
• —An endorse does not override a revoke. A rescued grant that an in-force revoke may remove is still removed. When it rescues a subtree, an endorser SHOULD also endorse the removed signer’s revokes within it. Otherwise those revokes die, and what they removed returns.
• —An endorse of a statement whose authorising grant is still in force changes nothing until that grant is removed, so a signer may endorse before it retires a grant. To withdraw an endorse, remove its endorser’s grant, or revoke the endorsed grant directly; the endorser and anyone above it may. An endorser between a remover and the grant it removes keeps what it names: a remover that wants a whole subtree gone also revokes what is endorsed, or removes the endorser.

6.6.6 Quota

• —Per signer, per grant. A bucket keeps at most Q statements: AUTHORITY_QUOTA (256) for a bucket authorised by a grant, and AUTHORITY_ANCHOR_QUOTA (4096) for the anchor’s. A bucket authorised by a grant also keeps at most AUTHORITY_DELEGATE_QUOTA (16) delegating grants (admin, validator, issuer). A bucket keeps, first, its own statements, when its authorising grant is in force: revokes and endorses in ascending id order (bytewise), then the alive grants that are not removed, in ascending id order, skipping a delegating grant beyond the delegate quota. Then, at greater depths, it keeps the statements its endorses rescue, in ascending id order, while it has room for them under both limits. A statement no bucket keeps is over quota: it is not in force, a node MUST NOT relay it, and a node MAY drop it unless it is in its live set (§6.6.7). A receiver SHOULD report a signer whose bucket is full to its operator.
• —Deterministic. Which statements a bucket keeps depends only on the statements, never on which arrived first. Dead statements and removed grants do not count against any quota. Which delegates survive near the cap is decided by statement id, not by the order a signer issued them in. A signer that needs particular delegates to stand keeps below the cap, or asks for a further grant.
• —One signer never displaces another. A bucket holds only statements signed under one grant, so a flood by one signer can only push out that signer’s own statements. Pending statements are held per session (§6.6.8) and never count against any bucket. A bucket keeps its own statements before any it rescues, so a rescue never displaces its endorser’s own statements either. The statements an endorser rescues compete only for that endorser’s room.
• —Removals first, so the quota fails closed. A flood of grants cannot push out a revoke. A signer that floods revokes displaces only its own grants.
• —Node capacity. A node MAY limit how many statements it stores. What it protects at the limit is what is in force, not a kind of statement. Validity is static: a removed signer can still sign any number of valid revokes, all of them dead, and an in-force holder can sign revokes beyond its quota. Protecting revokes by kind would let either crowd out honest in-force statements and grow storage without bound. When a node reaches its limit it first drops statements outside its live set, which it may drop anyway; dead and over-quota statements are ordinary candidates there, revokes and anchor-level statements included. Then it drops live statements in reverse authority order (§6.6.8): deepest first, grants before revokes and endorses at the same depth, and the highest id first. It never drops an in-force revoke or an in-force anchor-level statement. A revoke or an anchor-level statement that arrives at a full node is protected only if it would be in force once held. Then it displaces the last statement in that order that is not protected. Otherwise it is an ordinary candidate, like any other statement outside the live set. The protected set is bounded by the quotas of this section: in-force anchor-level statements by AUTHORITY_ANCHOR_QUOTA (4,096), and in-force revokes by the 256 statements each bucket keeps, in buckets whose grants are themselves in force. So protection cannot grow storage without bound. A capacity refusal is not a relay failure, and a node MUST NOT rate-limit or penalise the session that delivered the statement. So “removals first” and “fails closed” stay true under a storage limit: what a full node loses is the deepest delegated authority, never a removal in force. A node that has dropped live statements no longer resolves the same set as its peers, and it SHOULD report this to its operator. A storage limit is the node’s own, outside resolution: the quota rules above decide what every node resolves alike, and this rule decides only what a full node gives up first.
• —Why per grant rather than per key. First, it keeps selection well defined depth by depth. A key can hold grants at several depths, and counting per key would let its statements at one depth decide which of its statements survive at another. Second, it gives a way to compact. A signer near its quota, or one that needs more than 16 delegates, is given a further grant, which is a further bucket. To compact, its grantor then removes the old grant and endorses what should stand, and everything else under the old grant is dead and can be dropped. The anchor has no grantor, which is why its quota is larger; re-pinning is its compaction.
• —The bound, and why it holds. Below a holder X are the statements whose chain contains X’s grant. A signer above X may choose to rescue some of them; its own bucket keeps those, and they and what hangs from them are that signer’s choice, not X’s, so the figures below leave them out. Every other statement in force below X is kept by a bucket whose authorising grant is X’s grant or an in-force delegating grant below it. That is its own bucket when its authorising grant is in force, or its rescuer’s bucket, whose grant is in force because an endorse is never itself rescued. Each such bucket keeps at most Q = 256 statements and at most D = 16 delegating grants. Each in-force delegating grant below X is kept by exactly one such bucket and lies deeper than that bucket’s grant. So these buckets form a tree under X’s bucket in which every bucket has at most D children and depth strictly increases. Only grants at depth 3 or less have buckets, since a depth-4 grant’s statements would be at depth 5. A depth-1 holder therefore has at most 1 + D + D² = 273 buckets below it, and so at most 273 × 256 = 69,888 statements and 273 × 16 = 4,368 delegating grants in force below it. A depth-2 holder has at most 17 buckets, 4,352 statements and 272 delegating grants; a depth-3 holder one bucket, 256 statements and 16 delegating grants. All of it dies with one revoke of X’s grant. The authority vector carries the attacks that broke the first version of this rule, each within these figures, and a tree that reaches the figure exactly.

6.6.7 Properties and the authority root

• —Order independence. The same set gives the same answer. Every rule above refers only to which statements are held, their ids, their signatures and their fixed chains. The evaluation order is fixed by depth and id, not by arrival. Statements that are invalid, pending, dead, removed or over quota have no effect on which statements are in force. The node keeps those of them that are grants on the chains of in-force statements, because it verifies those statements with them. Together with the in-force set they make the node’s live set, which a node MUST keep. Whether it keeps or drops the rest changes nothing for the set it holds now. A dropped statement can matter later, though: an over-quota grant comes into force when a lower one leaves its bucket, and a dead one when an endorse for it arrives. A node that dropped it gets it back only from a node that kept it, so a node SHOULD keep over-quota and dead statements while it has room. A signer whose statement was dropped everywhere sends it again.
• —No cycles. A statement names others only by ids inside its own signed bytes, and an id is a hash of those bytes. A statement can therefore only name statements that already existed when it was signed. A cycle would need a statement whose bytes contain, directly or through others, its own hash, which SHA-256 makes infeasible. The references form a DAG. The depth cap bounds every walk even against a statement crafted to loop.
• —Anti-entropy is set union. Statements are immutable and resolution is a function of the set, so exchanging statements and taking the union is all that synchronisation does. No merge rule or tie-break between nodes is needed. Nodes compare authority roots to learn whether they agree (§6.6.8). Because held sets only grow and resolution is a function of them, repeated exchange between connected nodes converges, and it has converged when their roots match.

The authority root names one in-force set under one anchor:

pinDigest = lowercase hex(SHA-256(UTF8("mmp-anchor-pin-v1\n") ||
  lp(decimal(threshold)) ||
  lp(decimal(memberCount)) || concat(lp(member) for bytewise-sorted members)))
    member = key || ":" || nodeId when the threshold is 1 and the pin names the node holding
             the key; otherwise key

root = lowercase hex(SHA-256(UTF8("mmp-authority-root-v1\n") ||
  lp(pinDigest) ||
  lp(decimal(inForceCount)) || concat(lp(id) for bytewise-sorted in-force ids)))

• —It is taken over the in-force set, not the held set. Held sets legitimately differ between nodes that agree: dead and over-quota statements may be dropped, and pending ones are held only in memory. In-force sets of nodes that agree are identical. The live set (the in-force set with the grants on its members’ chains) is also enough to recompute the in-force set, so a root can be checked from statements alone.
• —It names the pin. Authority is relative to the anchor. Two different pins never share a root, and a re-pin changes it. Under a threshold of 1 a member’s nodeId is part of the pin, because it decides who is the anchor. Under a higher threshold nodeIds decide nothing and are left out of the digest, so two nodes that pin the same keys and threshold share a root whether or not they annotate them.
• —Checking a claimed root. To check a root against a set of statements, a node verifies every statement against the pin, resolves the set, and recomputes the root of the resulting in-force set. The claim holds if and only if the two roots are equal. Supplying the live set is enough. A statement added to it, or left out, that changes what is in force changes the root.
• —Binding a run or a decision to a root. An environment here is an application at Layer 7 (§14) that runs work and records its outcomes: a Core Secure participant (§17.1) in that role, such as XMesh. MMP defines no separate conformance class for it, so the two requirements that follow bind such an application and are checked by its own tests, not by the MMP vectors. An environment that binds a run, an episode or a recorded decision to an authority root MUST keep that root’s live set itself. Peers serve only their current set (§6.6.8), so an old root’s statements cannot be fetched later. Inside a deterministic run the environment MUST apply mesh weights (§6.6.10) against the root it admitted for the current tick, never against its node’s live in-force set.
• —Runs and ticks (informative). A run binds to a root, not to “the current set”. A replay against a later, larger set, one that includes a revoke that arrived afterwards, would otherwise resolve differently. When authority changes during a run, the environment admits the new root into its own input stream at a tick it chooses, so that a replay is deterministic. When a seat’s grant dies during a run, the hosted world decides the consequence inside the run at the tick it admits the new root, for example taking the seat’s agent out of play. MMP requires only that the change enter at one tick. That ordering, and that consequence, are the environment’s job, not MMP’s.

6.6.8 Frames, gossip and anti-entropy

Four peer-scope frames (§7.1, authority-frame.schema.json) carry the set, on confirmed sessions only (§5.2). A statement is verified on its own signatures and chain, whichever session delivered it. A session confers no authority on what it carries, and a session that delivers a statement which fails verification SHOULD be rate-limited.

{ "type": "authority-statement", "statement": { ...one statement... } }
{ "type": "authority-digest", "root": "<64 lowercase hex>", "count": 7 }
{ "type": "authority-fetch", "reqId": "af-<16 hex>", "ids": ["auth-...", ...] }
{ "type": "authority-fetch", "reqId": "af-<16 hex>", "after": "" }
{ "type": "authority-set", "reqId": "<the request's reqId>",
  "statements": [ ... ], "missing": ["auth-...", ...], "next": "<opaque cursor>" }

• —Gossip. When a statement first enters a node’s in-force set, the node relays it once, as an authority-statement, to its other sessions. The same holds for a statement that enters because another arrived, such as a pending statement whose chain completed. A node MUST NOT relay a statement that is not in force, except as a chain member inside an authority-set. A revoke is relayed as soon as it enters, since the revoke window (§6.6.12) runs until it arrives.
• —Budget. A receiver keeps a budget per session for authority statements: the verification work it will do for that session over time. Every statement a session delivers spends that session’s budget, whether it was asked for (an answer to a fetch, a page of a pull) or not, and its cost is never forgiven below zero. The asker paces its own requests so that its budget for the session can absorb the worst-case answer. It starts a pull, asks for the next page, or sends a by-id fetch only when the session’s budget can pay for a full page: AUTHORITY_PAGE statements, each at the worst-case cost of verifying a statement under keys it has not seen. An answer within what was asked is therefore never dropped for budget. A statement nobody asked for, beyond the budget, is dropped unverified.
• —Pending statements. A valid-looking statement whose chain is not complete (§6.6.3, rule 2) is pending. Before it verifies anything in such a statement, the receiver checks that it has room to hold one more pending statement on that session; a statement it could not hold is dropped unverified. It then checks the statement’s single signature, under §18.3.2, with the key its entry names, and discards it if that fails. Checking a key the node has not seen costs one scalar multiplication, paid from the session’s budget. It then MAY hold the statement in memory while it fetches the missing link from the session that delivered it. Held statements are keyed by id and signing key, so a forged copy cannot displace a genuine one. At most AUTHORITY_PENDING_MAX (64) are held per session. They are never persisted, relayed or counted against a quota, and they are released after AUTHORITY_PENDING_TIMEOUT (10,000 ms) or when the session closes. A node keeps at most one fetch in flight per (session, missing id), and sends a fetch only when the session’s budget allows (Budget, above). An anchor-level statement is never pending: the pin is always at hand.
• —Fetching by id. authority-fetch with ids (1 to 64) asks for those statements. The responder answers with one authority-set carrying, in authority order, the closure of what was asked: each named statement in its live set with its chain; then every in-force revoke and endorse that names a statement already in the answer, each with its chain; and so on, the namers of namers, until a pass adds nothing or the answer reaches the page bound. Ids it does not serve are listed in missing, including those of statements it holds that are not in its live set (dead, over quota or pending): a dead statement is served only as a chain member of a live one. An answer carries at most AUTHORITY_PAGE (64) statements. A removed grant is served only with the revoke that removes it, so a fetch never hands out a removed grant as if it were in force.
• —Authority order is ascending depth; within a depth, revokes and endorses before grants; within each, ascending id. In that order every statement arrives after everything that can change its standing: its chain, the revokes that may remove it, and the endorses that may rescue it. A receiver can ingest a page as it arrives.
• —Anti-entropy. A node sends authority-digest, its root and in-force count, when a session is confirmed. It sends it again after its in-force set changes, at most once a second per session. A node whose root differs from the peer’s pulls the peer’s live set. It sends authority-fetch with after: "", then pages with the next cursor of each answer until an answer carries none. It starts the pull, and asks for each page, only when the session’s budget can pay for a full page (Budget, above). Each page holds at most 64 statements, in authority order. Every statement received is ingested as gossip is. The peer, seeing the same mismatch, pulls in the other direction. A node keeps at most one such pull in flight per session. A responder SHOULD pace its answers per session (for example 4 a second, burst 16), and MAY refuse a fresh full pull on a session within 60 s of the last. The cursor is opaque, at most 128 characters. Statements that change while a pull is running are reconciled by the next digest. A pull that stops early, because the session closed or a page did not come, resumes from its last cursor. While the two roots still differ after a pull, a node repeats anti-entropy with backoff (for example doubling from one second up to a few minutes) rather than giving up after a fixed number of tries; a matching root, or a change to either set, resets the backoff.
• —Persistence. A node SHOULD persist its live set and MAY persist more. Persisted statements have no integrity of their own. On load, a node MUST re-verify every statement against the pinned anchor, chain by chain from the top, and resolve the set afresh. It MUST NOT trust a status or a root read from disk. It keeps the statements that fail under the current pin, and judges them again under the next (§6.6.1). No receipt time is kept, because none is used.

6.6.9 Authority follows the key

• —A grant confers its role on its subject’s nodeId and key together. A CMB or attestation carries its author’s role only when the key that verifies its signature (§18.3.1) is that grant’s subject key. A grant that names the same nodeId with another key confers nothing on the holder of the first.
• —A statement’s signing key comes from its authorising grant, or from the pin, and never from a node’s key registry. That is what makes resolution the same at every node, whatever keys each has bound.
• —Grants as a binding source. An in-force grant is a source a key registry MAY bind its subject from (§3.4), as a view over what is in force now: the binding lasts only while the grant is in force, and goes with it unless another source binds the same key. It binds only an unbound nodeId. If the nodeId is bound to a different key, that is an identity conflict (§3.4): it is recorded and reported, and the binding is unchanged. The grant stays in force, since resolution does not read the registry, but at that receiver it confers nothing usable, because no record that verifies under the bound key is signed by the grant’s key.
• —The receiver’s own nodeId. A receiver MUST NOT take a binding for its own nodeId from any grant, because it knows its own key (§3.1.3). A grant that names the receiver’s nodeId with a foreign key confers nothing on the receiver, and the receiver SHOULD report it: someone has vouched a foreign key for its identity.

6.6.10 Using authority: agreed outcomes and mesh weights

• —Outcomes that must be agreed are decided once, by the environment. Some outcomes several parties must agree on: that a piece of work was validated, that a payment is due. Such an outcome is decided once, by the environment the decision belongs to (the application or runtime that runs the work), against that environment’s in-force set at that moment. It is recorded there, bound to the authority root it was decided under (§6.6.7). The record is the outcome. A node MUST NOT re-derive or re-judge such an outcome from mesh gossip, and MUST NOT treat a later change in its own in-force set as reversing it. (Informative: XMesh keeps such a record for the work it runs.)
• —Mesh weights are judged by the receiver, when they are used. Everything else authority does in the mesh is a weight a receiver applies: the origin admission weight (§6.4), lifecycle advancement in its own store (§6.5), and the weight of an admission, tether or grounding attestation (§6.7, §15.8, §17.2). A receiver judges each against its own in-force set at the moment it applies it. A transition it has already made in its own store is its own record, and a later revoke does not undo it. A weight it applies afresh, each time it weighs an attestation, uses the in-force set of that moment. A scoped grant’s weight applies only to CMBs inside its scope (§6.6.2). Inside a deterministic run the environment uses the root it admitted for the tick, not the moment (§6.6.7). A statement carries no signed time that could place it inside a period of trust: once a signer’s grant is not in force, nothing that signer signs, whatever time it claims, carries authority.

6.6.11 Migration from the time-replay rule

• —The old frames confer nothing. The earlier role-grant and role-revoke frames and records, as signed by sym 0.14.0 and earlier, are retired (§7.1, legacy). A node MUST NOT resolve authority from them and MUST NOT emit them. The old revoke cutoff, the grant time grantedAt, resolution at a time T, and the receipt-time rule are removed. No statement carries a cutoff, and no receipt time is stored.
• —Anchor grants map one for one. For each old grant signed by the anchor that the anchor’s holder still regards as in effect, the anchor issues one grant: the same subject nodeId and key (granteeKey), authorisedBy: "anchor", and the role mapped (validator stays validator; the granted anchor role becomes admin). A single-key anchor is the 1-of-1 set, so the node holding that key can issue these without co-signers. An old grant with no granteeKey has no subject key. It cannot be carried over until the key is known from a confirmed handshake or an out-of-band pin. Migrated grants carry no scope, since no old grant had one.
• —Deeper chains carry over within the cap. Once a grantor holds its own new grant, it re-issues each old grant it signed that it still regards as in effect. Each re-issued grant names the grantor’s new grant in authorisedBy, provided the role table of §6.6.2 permits it and the depth stays within MAX_DELEGATION_DEPTH. An old link that does not fit, such as a validator that promoted a validator, does not carry over by itself. Its grantee needs a grant from the anchor or an admin. Each signer re-issues only its own grants, so migration needs no agreement between nodes. An old grant that an old revoke had cleared is simply not re-issued.
• —Pre-0.14 grant entries are legacy claims, unchanged. A key that a pre-0.14 implementation (sym 0.13) recorded for a nodeId from a grant, or from an unproven hello, is a legacy claim (§3.4). It is the key the receiver expects for that nodeId: a session proving it binds it, and one proving a different key is an identity conflict. It verifies nothing, binds nothing by itself and confers no authority.
• —A flag day. This is a flag day, not a gradual migration. A node running this rule ignores the old frames, so until grants are re-issued under the new rule it resolves every node, itself included, as a participant, whatever the old rule granted. A node running the old rule ignores the four new frames as unknown types (§7) and keeps the old authority. Each sees only its own kind. The anchor’s holder SHOULD migrate first and re-issue at once, and each grantor SHOULD re-issue as soon as it holds its own new grant, so the gap lasts no longer than the mesh’s upgrade.

6.6.12 Residuals

• —The revoke window. Until a node holds a revoke, it treats the removed grant as in force. Gossip relays a revoke as it enters; anti-entropy bounds the rest. A node learns a revoke at the latest at its next digest exchange with any peer whose in-force set includes it, and those exchanges happen when a session is confirmed and whenever a set changes. A partitioned node stays exposed until it reconnects. An environment deciding an agreed outcome (§6.6.10) SHOULD bring its in-force set up to date with a node it trusts to be current before it decides.
• —The threshold holders are the root. Any t anchor keys together can grant, revoke and endorse anything. Compromise of t keys is root compromise, recovered only by re-pinning out of band. Fewer than t keys can do nothing alone; under a threshold of 1, therefore, every pinned key alone is the root.
• —A compromised holder acts until it is removed. Within its quota and delegate quota, and within the figures of §6.6.6, a compromised authority holder can grant, revoke and endorse below itself until a signer above removes its grant. Endorsement then keeps what should stand.
• —Verification costs one scalar multiplication per new key. Checking that a key is of prime order (§18.3.2) costs one multiplication by L for each key a node has not seen before; under a cofactorless verifier R costs only a byte comparison. A flood of statements under fresh keys is bounded by the session’s budget, which every statement a session delivers spends, asked for or not, and which the asker paces its own requests to (§6.6.8), and by the quotas once chains are held. The pending limits bound how many statements a session can have held, not how many checks it can cause.
• —Grants are visible. Every node that holds the set can read who holds which role. Authority statements are not confidential.

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 is granted again under its new key. Revoking the old key’s grants contains the damage in the meantime, and endorsing what the old key granted keeps what should stand.

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 cmb- 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 a verified direct-parent path through the node’s admitted remixes, §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 metadata.createdTimestamp, 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

The table is rendered from the normative machine-readable frame registry; its own shape is validated by frame-registry.schema.json.

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 registry distinguishes Core Secure wire types from retained legacy and runtime-extension types. A Core Secure participant MUST complete the three-frame authenticated handshake before it accepts cmb or cmb-encrypted. It MUST NOT silently downgrade to the legacy one-frame handshake or to an unsigned application frame.

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.

Sealed control frames. Only the frames a session protects are bound to it. A frame in clear can be read and injected by whatever sits on the path — over a relay, the relay itself and, before relay authentication proves keys, any client that can claim a nodeId there (§4.4.1, §4.4.4). In a Core Secure session that is CONNECTED (§5.3), a sender MUST therefore send every peer-scope frame other than ping and pong sealed: a record in cmb-encrypted, and every other frame — peer-info, wake-channel, mood, cmb-fetch, cmb-fetch-result, cmb-anchors (§9.4), room-join (§5.8.1), the four authority frames (authority-statement, authority-digest, authority-fetch, authority-set, §6.6.8), error and every negotiated extension frame — as the inner frame of a control-encrypted envelope (§18.2.1). A receiver MUST discard any of those frames that arrives in clear on a CONNECTED session, with one exception: it MAY read an error in clear, as the informational frame it always is (§7.2), but a clear error changes nothing. It closes no session, moves no sequence and changes no state, because whatever sits on the path can forge it, and a receiver cannot tell whether its sender still holds a session. The one clear error a node acts on is 1011 UNKNOWN_SESSION, which MAY prompt a new handshake and nothing else (§5.2.2). A sealed error is the peer’s own: one whose action is Close (§7.2) ends the session. ping and pong MAY travel in clear or sealed, and a receiver handles a sealed one as liveness, exactly as a clear one, and answers a sealed ping with a pong, in clear or sealed (§5.4). The inner frame of a control-encrypted envelope MUST NOT be a handshake frame (including the legacy handshake), cmb, cmb-encrypted, control-encrypted, state-sync or a relay-* frame. A sealed frame that opens advances its direction’s sequence (§18.2.1) whether or not its inner frame is then accepted; refusing the inner frame changes nothing else.

Session-bound frames speak only for the session’s peer. wake-channel, mood, cmb-fetch, cmb-fetch-result, cmb-anchors, room-join, authority-digest and authority-fetch take their sender from the session: the proven nodeId of the peer whose keys opened them. A receiver MUST attribute them to that nodeId and the name the handshake bound to it (§5.2). None of them carries a sender field, and a receiver MUST NOT take a sender from inside a frame. peer-info describes other nodes; its entries are hints. A receiver MAY use a gossiped wake channel to try a wake, but MUST NOT let it replace a wake channel the named node registered over its own session, and MUST NOT bind an identity or a key from it (§18.3). Sealing proves who sent a frame, not that what it says about third parties is true.

Author-signed frames carry their own authority. A frame that carries a signed statement takes its authority from that signature, never from the session that delivered it: a signed statement may be relayed over any session, and the session only transports it. Sealing it still keeps it from the relay, and from injection. The key it is verified against depends on what it is. An authority statement, carried in authority-statement or authority-set (§6.6.3), is verified by §6.6.9 and §18.3.2: against the subject key of the grant its authorisedBy names, or the pinned anchor keys, under the one verification rule, and never against a key a registry or a session binds to a nodeId. A record (§18.3.1), and an extension’s author-signed frame such as a sym-attest-v1 attestation (§16.4), is verified against the key the receiver binds to the nodeId it names (§3.4), never against the key of the session that delivered it.

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. A clear error changes nothing (§7.1). A sealed error is the session peer’s own notice: one whose Action is Close ends that session at the receiver too; any other sealed error is information.

Codes 1xxx are connection-level: they concern a connection or a session, and most close it; the Action column says which. Codes 2xxx are evaluation-level (informational). Error-frame codes are a registry of their own, separate from the relay’s WebSocket close codes (§4.4.9): an implementation MUST NOT send an error frame with a code in the 4000–4999 range, which those close codes occupy. 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 categories (the CAT7 schema). CMBs are the data structure that flows between agents via cmb frames.

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

8.1 Why 7 categories

The 7 categories 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 category text, not the category name. A coding agent’s focus is “debugging auth module”; a fitness agent’s focus is “30-minute HIIT workout.” same category, different domain lens.

mood is the only fast-coupling category — 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 categories couple at medium or low rates, with per-agent α_f weights controlling relative importance.

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

8.2 Category Schema

Implementations MUST use the following 7 categories in this order:

Each category carries signed symbolic text and content-address metadata. A receiver derives any machine-comparable embedding locally from that signed text; embedding vectors never cross the wire. The mood category additionally carries optional numeric valence (-1 to 1) and arousal (-1 to 1) values. Neither the address nor the mmp-sig-v2.0 signature covers them, so a Core Secure verifier drops them before admission (§8.8.4); the signed mood text is what carries affect between nodes.

A CMB MUST NOT be modified after creation. When an agent remixes a CMB, it MUST create a new CMB whose metadata.lineage contains parents (direct parent CMB keys) and optionally method (the fusion method used; carried but not signed, and dropped by a Core Secure verifier, §8.8.4). Transitive provenance is obtained by recursively resolving those signed parent records. A sender MUST NOT supply or rely on an unauthenticated transitive-closure field.

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. The metadata.addressScheme field identifies the derivation; the shared cmb- prefix alone does not. 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. The GitHub protocol repository carries a manually synchronized mirror for offline use and contribution workflows.

Superseded 1.x derivation — INFORMATIVE, not normative in 2.0. The earlier format wore the same cmb- prefix over a different digest, which is exactly why it is recorded here rather than dropped: an implementation that meets it by accident produces a plausible key for the wrong content, and the divergence is silent. It is distinguishable by length — 32 hex characters against the current 64 — and the reference runtime rejects it outright (§8.2.1: valid iff 64 lowercase hex, anything else refused rather than reinterpreted). A conformant node therefore MUST NOT mint it and SHOULD NOT accept it; a node holding blocks addressed this way MAY continue to read its own history. 1.x stated that a conforming node MUST verify this form — that requirement is withdrawn, because no deployed node does, and a specification that requires what nothing implements is the defect 2.0 exists to correct. Specified byte-exactly so it can be recognised and refused:

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 ) )

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

This scheme has three known weaknesses, which the successor resolves: the | join is not injection-proof (a delimiter inside a category 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 record — see §8.8 Record Model. The address is "cmb-" + 64 lowercase hex, and the digest is a promote-odd Merkle root over the seven per-category keys, not a hash of a concatenated preimage. This section gives the cognition-key construction byte-exactly; §8.8 makes the construction implementable and reproducible from that text alone. With lp as in §8.8.4 (the ASCII decimal UTF-8 byte length, a colon, then the bytes):

categoryKeyV1(name, text) = lowercaseHex( SHA-256( UTF8("mmp-cmb-v1\n") || lp(name) || lp(text) ) )
                            // text is NFC; the result is the category's meta.key

leaf(name)  = SHA-256( 0x00 || K )     // K: the 32 bytes the 64 hex characters of categoryKeyV1 encode
pair(l, r)  = SHA-256( 0x01 || l || r )

level 0     = leaf(focus), leaf(issue), leaf(intent), leaf(motivation),
              leaf(commitment), leaf(perspective), leaf(mood)          // CAT7 order
level n + 1 = pair the nodes of level n left to right; a last node with no partner
              is promoted to level n + 1 unchanged
blockKeyV2  = "cmb-" || lowercaseHex(the single node left)              // 7 → 4 → 2 → 1

Why this section changed in 2.0. Through 1.1.0 this page specified a flat SHA-256 over a length-prefixed concatenation of the seven category texts plus a role tag. The implementation mints the Merkle form. Both wear the same cmb- prefix, so an implementation built to the older text computes a different address for the same content and nothing signals the mismatch — it fails silently, at every record. That is the divergence 2.0 exists to close.

Schemes a node may encounter. The reference implementation classifies three: block-v2 — the Merkle form, and the only form it mints — together with root-v1 and remix-v1, the earlier flat derivations, retained so older records can still be classified. A conforming node MUST mint block-v2.

• Category text MUST be Unicode NFC (UAX #15): an emitter normalises category text, createdBy, room and application.schema to NFC before minting, and a verifier refuses a record in which any of them is not NFC (§8.8.5). Category order is the fixed CAT7 order. Mood contributes its text only; valence, arousal and all vector embeddings are excluded from the address.
• Netstring length-prefixing makes each per-category preimage injection-proof with no escaping and no JSON-canonicalization dependency, so implementations in different languages agree byte-for-byte.
• A record binds content only — identical content by any author at any time yields one address. Descent is committed alongside the address in the signature (§8.8.4), never folded into it, so that collapse property is preserved.
• The full 256-bit width is normative: a truncated hash’s birthday bound would admit a grind-then-substitute attack against the signed key.

8.3 Category-by-Category Guide

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

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 category. 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 category 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-category 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 category using the artifact: prefix:

The CMB’s other 6 categories 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 categories, 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 categories — categories 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.

8.8 Record Model

A Cognitive Memory Block separates what the agent says from what the mesh can prove about that assertion. This section is normative and byte-exact. The public schemas, constructors and vectors are available from the conformance suite.

8.8.1 Two-section logical record

{
  "categories": { "focus": { "text": "…", "meta": { "key": "…", "parents": [] } }, "…": "six more" },
  "metadata": {
    "key": "cmb-…",
    "addressScheme": "mmp-cmb-merkle-v2",
    "assertionId": "asrt-…",
    "signatureSuite": "mmp-sig-v2.0",
    "createdByNodeId": "…",
    "createdBy": "display label",
    "createdTimestamp": 1786611600000,
    "room": "team-room",
    "to": null,
    "lineage": null,
    "application": null,
    "sigAlg": "ed25519",
    "sig": "…"
  }
}

• —The decrypted logical record MUST have exactly the two top-level members shown above.
• —categories MUST contain all seven CAT7 categories and their per-category descent metadata.
• —metadata carries exact authorship, audience, lineage, application and signature assertions.
• —Admission may evaluate seven categories independently, but memory admission stores or refuses this immutable CMB as one record. A partial CMB is never created.

8.8.2 Cognition key and assertion identity

metadata.key identifies CAT7 cognition. It is the promote-odd Merkle root defined in §8.2.1 and remains independent of author, time, audience, lineage and application bytes. Identical CAT7 cognition therefore collapses to one cmb- key.

assertionId = "asrt-" || lowercaseHex(SHA-256(signingPayloadV2_0))

assertionId identifies the complete authenticated assertion. Memory deduplication uses the cognition key. Directed or actionable delivery deduplication MUST use the assertion identity. Two records with the same CAT7 categories but different application bytes consequently share a cognition key and have different assertion identities.

8.8.3 Authenticated application bytes

An application action MUST NOT ride as an unsigned top-level payload. When present, it is stored as metadata.application:

{
  "mediaType": "application/json",
  "schema": "https://example.test/schema/action-v1.json",
  "encoding": "base64url",
  "byteLength": 123,
  "digest": "sha256-<64 lowercase hex>",
  "data": "<unpadded base64url>"
}

data is unpadded canonical base64url and decodes to at most 524,288 bytes. Before application exposure, a receiver MUST verify the encoding, decoded length and SHA-256 digest. The descriptor commitment binds presence, media type, schema URI, encoding, length and digest into the record signature.

applicationCommitmentV1(absent) =
  hex(SHA-256(UTF8("mmp-app-v1\n") || lp("0")))

applicationCommitmentV1(present) =
  hex(SHA-256(UTF8("mmp-app-v1\n") || lp("1") || lp(mediaType) ||
    lp(NFC(schema)) || lp("base64url") || lp(decimal(byteLength)) || lp(digest)))

8.8.4 Corrected v2.0 signature payload

lp(x) is ASCII decimal UTF-8 byte length, a colon, then the UTF-8 bytes of x. Integers are unsigned canonical decimal with no leading zero. Lists state their count and sort members bytewise.

UTF8("mmp-sig-v2.0\n") ||
lp("2.0") ||
lp("mmp-cmb-merkle-v2") ||
lp(metadata.key) ||
lp(metadata.createdByNodeId) ||
lp(NFC(metadata.createdBy)) ||
lp(decimal(metadata.createdTimestamp)) ||
lp(NFC(metadata.room)) ||
lp(metadata.to or "") ||
lp(decimal(parentCount)) ||
concat(lp(parent) for bytewise-sorted parents) ||
lp(categoryParentsCommitment) ||
lp(applicationCommitmentV1)

• —createdByNodeId is the cryptographic author identity and MUST resolve to the verifying Ed25519 key.
• —createdBy is a signed display label and MUST NOT be used for identity resolution or routing.
• —room is explicit. The default room is the literal string default, not absence.
• —to is the record’s audience: null for a room-bound record, which enters the payload as lp(""), or the recipient’s nodeId for a directed one. It is the only source of the record’s binding (§9.2.2); no transport field overrides it.
• —New v2.0 records MUST declare mmp-cmb-merkle-v2; a verifier MUST NOT guess among address derivations sharing one prefix.

Carried but unsigned members. Four members travel with a record and are not bound by this payload: each category’s meta.key, the mood category’s valence and arousal, and metadata.lineage.method. A relayer can change any of them in a record whose signature still verifies. The payload also leaves four forms unbound: the order of parents, the Unicode form of a signed string, an empty lineage against null, and an absent application against null. §8.8.5 step 1 makes each canonical. The four members are handled as follows:

• —meta.key is derived: a verifier MUST recompute it from the category name and the signed text (§8.2.1) and MUST refuse a record whose carried value differs (§8.8.5, step 4). Recomputing it makes it as trustworthy as the text it is derived from, without signing it.
• —valence, arousal and lineage.method are unsigned and carry no authenticated meaning. A Core Secure verifier MUST drop them before admission, so the record it admits, stores, delivers or serves again is the signed projection without them, and a receiver MUST NOT act on a value it was sent for them. An emitter MAY still include them; a reader under an explicitly selected Legacy Import profile may show them, labelled as unverified.

Adding them to this payload would change the mmp-sig-v2.0 bytes, and so every published v2.0 signature, assertion identity and vector. If authenticated affect values are needed, they belong in a new signature suite with its own identifier, which a verifier selects by signatureSuite (§8.8), so records signed under mmp-sig-v2.0 stay verifiable. (Informative: the SYM runtime from 0.14.0 recomputes and checks meta.key, and drops the other three at ingress, on fetch and at egress.)

8.8.5 Verification order

Before step 1, and for a sealed frame again immediately after step 2, a verifier MUST check the size limits of §8.8.6 and refuse a record over any of them without doing any other work on it.

1. Validate the negotiated frame schema, and the record schema strictly, and keep only the signed projection. For a sealed frame the record schema and the projection apply to the decrypted record, immediately after step 2, as the size check does.
   • Every object is closed (additionalProperties: false): a member the schema does not define is refused. The one exception is an unrecognised category, which is dropped (§8, forward compatibility).
   • Every member already has its schema’s JSON type. A verifier MUST NOT coerce one: a number is not its decimal string, and an array or object is not a string.
   • metadata.createdByNodeId is a lowercase UUID, and metadata.to is a lowercase UUID or null, and nothing else (§3.1.1).
   • Every signed string is already NFC (UAX #15): each category’s text, createdBy, room and, when present, application.schema. A verifier refuses a value that is not, and never normalises it, as it never coerces a type. room is a §5.8 room identifier ([a-z0-9._-], 1 to 64 characters), as the handshake room is. createdBy is at most 256 characters, and lineage.parents and each meta.parents hold at most 256 entries of at most 256 characters, counted in Unicode code points, as JSON Schema’s maxLength counts them.
   • The projection is canonical, so one assertion is held as the same bytes at every node: lineage.parents and each meta.parents are sorted bytewise, as they are signed (§8.8.4), a lineage whose parents is empty becomes null, and an absent application becomes null, each of which signs the same as the form it replaces. The record-projection vector pins the projection of relayer-style variants of signed records, and each refusal.
   • A record that carries an embedding vector, or any member the schema does not define other than an unrecognised category name directly under categories, is refused (§8.8.5 step 1, §9.2.1).
   • The verifier then drops the carried but unsigned members (§8.8.4). Every later step, and admission, storage and delivery, sees only the projection: the members mmp-sig-v2.0 binds, with each meta.key checked in step 4.
2. When encrypted, authenticate and decrypt the transport envelope.
3. Verify application encoding, length and digest.
4. Recompute every category key and the cognition key, and reject a record whose carried meta.key or metadata.key differs.
5. Recompute the assertion identity and reject a carried mismatch.
6. Resolve the author key by createdByNodeId and verify the Ed25519 signature.
7. Verify signed room and recipient audience.
8. Only then expose the record for delivery and receiver-autonomous admission.

Failure at any cryptographic step is a refusal, not an “unverified success.” Legacy reading belongs to a named migration profile and MUST NOT downgrade Core Secure automatically.

8.8.6 Record size limits

A record is bounded so that it always fits in one sealed frame, and so that a receiver can refuse an oversized one before doing any work on it. The limits are in bytes:

• —One measure. Every receiver has to reach the same verdict on the same record, so the encoded size is measured on one serialization, not on whatever bytes arrived or whatever a local encoder writes. RFC 8785 writes strings with only the escapes JSON requires, and other characters as their UTF-8 bytes; it writes numbers as ECMAScript does and sorts members. Its length is therefore the length of ECMAScript JSON.stringify of the record, whatever the member order. An encoder that escapes every non-ASCII character (\uXXXX, the default of some JSON libraries) counts a CJK character as 6 bytes instead of 3, and is not this measure. The record-size vector pins the measure and each limit at its boundary.
• —An emitter MUST NOT mint a record over any limit, and a receiver MUST refuse one. Records are never split: a node with more to say emits more records, linked by lineage.
• —Where the check sits. For a cleartext frame, the receiver checks before §8.8.5 step 1. For a sealed frame, it checks twice. Before decrypting, it refuses a sealed value longer than a MAX_RECORD_BYTES plaintext could produce: ⌈4 × (737,280 + 16) / 3⌉ = 983,062 base64url characters. Immediately after step 2, it checks all three limits on the decrypted record. Either way, the check comes before schema validation, key recomputation, signature verification and any encoding of text.
• —Why these numbers. A frame is at most 1 MiB (§4.1). A sealed frame carries its plaintext as base64url, a third larger, so a record above about 768 KiB cannot travel in one cmb-encrypted frame at all. 720 KiB leaves room for the envelope, the clear metadata and the relay’s routing wrapper. 256 KiB per category and 512 KiB in all bound the text a receiver must normalise, hash and encode before it decides anything. They also leave room for metadata and application bytes, whose decoded length is at most 524,288 bytes (§8.8.3). The encoded limit binds all of them together.

Implementation status: the SYM runtime 0.14.0 enforces these three limits when it mints and when it receives, and refuses a sealed value longer than 983,062 characters before opening it.

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-category 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 category’s unconditional delivery is a Section 9.3 delivery mechanism, separate from this admission evaluation.) The encoder that maps category text to vectors SHOULD use semantic embeddings (e.g. sentence-transformers) rather than lexical hashing — per-category evaluation quality is bounded by encoder quality (Section 18.7), so thresholds are meaningful only within a pinned encoder.

The SVAF evaluation computes category evidence between the incoming CMB and local anchor CMBs, applies per-agent category weights (α_f), combines with temporal drift, and produces one whole-record 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  (reference 0.10)  // nearest-anchor basis, §9.2.1
κ = aligned   if totalDrift ≤ T_aligned    (reference 0.25)
κ = guarded   if totalDrift ≤ T_guarded    (reference 0.50)
κ = rejected  otherwise

// The three thresholds and λ are the RECEIVER'S admission policy, not protocol
// constants. The values above are the reference implementation's, given so an
// implementer has a working starting point — they are informative, not required.
// A conformant node MAY choose differently; no sender and no coordinator sets them.

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 category drift D lies in ( (Tguarded − λ) / (1 − λ),  Tguarded / (1 − λ) ) — at the reference values (λ = 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 Category drift δ_f (Decision Evidence)

δ_f ∈ [0,1] is the category drift computed for each CAT7 category 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 category vector x_f and the receiver’s local anchor set A. Output: δ_f ∈ [0,1] — 0 means the category is already represented in memory (no information gain); 1 means maximally novel or foreign relative to memory.

A is a receiver-chosen window over prior memory, not necessarily all of it. A node MAY evaluate against every block it holds, or against a bounded selection of them — the window is part of its admission policy, alongside the thresholds, and no sender or coordinator sets it. This matters more than it first reads: the window decides how much of what a node already knows is allowed to participate in judging an arrival, and a narrow one selected by recency answers a different question from one selected by relevance. An implementation SHOULD make the window explicit rather than fixing it as a constant, and SHOULD state which of the two it selects by. The reference runtime uses the 5 most recent blocks by default — an informative value, carried for continuity, with no measurement claimed for it.

Embedding vectors are receiver-local. x_f MUST be computed by the receiver from the category’s own text, in the receiver’s own encoder. An emitter MUST NOT include embedding vectors in a record, and a Core Secure receiver refuses a record that carries one: the record schema is closed (§8.8.5 step 1), and a vector is a member it does not define. Under any profile a receiver MUST encode from text and MUST NOT use a transmitted vector for admission. The reason is that a foreign vector is unusable, not merely untrusted: drift is measured against the receiver’s anchors in the receiver’s encoder, so a vector produced by a different encoder is not comparable — the comparison is meaningless rather than imprecise, and no signature can make a cross-encoder number mean something. Nothing in this specification requires nodes to share an encoder, and requiring it would reintroduce a center. Only the text is normative; the vector is the receiver’s own reading of it.

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 categories. If A holds no anchor carrying category c, δ_f is undefined and that category MUST be excluded from the fieldDrift aggregation and the redundancy max — not treated as maximally novel. If no category 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.
5. Per-category verdict vocabulary. A receiver that reports per-category outcomes — in an admission attestation (§15) or any other audit surface — MUST use exactly these five values: admit, guard, redundant, reject, silent. The first four are decisions about a category that was evaluated. silent is not a decision: it reports that δ_f was undefined and the category was therefore excluded per invariant 4 above. It has no position on the drift dimension, and a verifier MUST NOT read it as a decline — a category that could not be evaluated has not been judged. Distinguishing the two causes — the emitter carried no text for that category, or the receiver held no anchor for it — is RECOMMENDED: they mean opposite things operationally, the first being an upstream defect and the second a healthy cold start.

These invariants make admission well-defined and rule out two failure modes: self-referential collapse (the incoming block in its own baseline ⇒ every category redundant) and cold-start starvation (empty memory ⇒ every category 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 category c the receiver derives a local vector x_f from the incoming CMB’s signed text, and each anchor a ∈ A carries a receiver-local vector v_a,f in the same encoder space:

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 category 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. A baseline-math fixture may pin already-derived local vectors, τ, signal age, and each anchor’s stored time and confidence. Such a fixture tests the admission arithmetic only; it is not a wire CMB and does not permit an emitter-supplied vector. Live admission remains receiver-divergent by design because receivers may use different encoders and α_f values.

The redundancy test is the key addition: a signal is redundant if every category falls below T_redundant — meaning no category carries novel content relative to local anchors. If any category is novel (e.g., same topic but different intent), the signal passes. This preserves per-category 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 direct-parent lineage 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 authenticated recipient, metadata.to: the author signs it in the §8.8.4 payload, and on a sealed frame it is also bound into the AEAD associated data (§18.2.1). A receiver MUST take the binding from metadata.to of the record it verified (§8.8.5), and in Core Secure it MUST NOT take it from a transport routing envelope (§4.4.4) or from any other unsigned field. A Legacy Import profile (§17.3), whose records may carry no signed audience, states its own rule. The envelope is not authenticated, the relay does not forward its to, and under per-session encryption every sealed frame is addressed to exactly one peer, whether the record inside it is directed or room-bound — so an envelope-derived binding would make every room broadcast directed, and would let whoever writes envelopes decide what reaches an agent unfiltered.

• — Room-bound (autonomous). A CMB whose metadata.to is null: it is addressed to its authenticated room, however many frames carried it. The receiver evaluates it autonomously: SVAF gates both memory admission and delivery. A room-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 (metadata.to = this node). 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). A receiver MAY refuse, before delivery, a directed CMB whose signed createdTimestamp is older than the window over which it keeps the marks it de-duplicates delivery by. That is replay protection, not withholding: a record older than the window could be one already delivered and forgotten.
• — Addressed to another node. A CMB whose metadata.to names a node other than the receiver fails the recipient-audience check of §8.8.5 (step 7). It MUST NOT be delivered or admitted. This is the case a misrouted frame or a forwarded copy of someone else’s directed record produces; the mood exception of §9.3 does not apply to 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 category extraction

Mood is a CAT7 category within the CMB; it is also carried as its own lightweight frame type (mood, §7.1) for sharing mood with a connected peer, distinct from cmb frames — in either carrier, mood delivery is not SVAF-gated memory admission. Mood text is cognitive content: in Core Secure the mood frame travels only sealed, as the inner frame of control-encrypted (§7.1, §18.2.1), and is attributed to the session’s proven peer. Affective state crosses all domain boundaries — this is the only category with this property.

The mood frame. { type: "mood", mood, context, timestamp } (§7.1, control-frame.schema.json): mood is text of 1 to 1,024 characters, context is text of at most 4,096 characters or null, and timestamp is the sender’s, information only. The frame names no sender and carries no valence or arousal (the CMB mood category carries those). It is session-scoped: in Core Secure it travels only on a confirmed session, as the inner frame of control-encrypted (§18.2.1), and a mood frame in clear on a CONNECTED session is discarded (§7.1). A receiver attributes it to the session’s proven nodeId and the name the handshake bound to it (§5.2), and refuses a mood frame that carries any other member, a sender field included. It is not a record. It carries no signature, and a receiver MUST NOT store it, relay it, remix it or treat it as a CMB; it reports it with no record verification (verification null) together with the session’s facts. A receiver MAY weigh the mood against its own state, for example by drift, and surface or ignore it; neither is memory admission.

When SVAF rejects a CMB (totalDrift > T_guarded), the receiving node MUST still inspect the mood category. If the mood category contains a non-neutral value (text ≠ "neutral"), the implementation MUST deliver the mood category’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). Under mmp-sig-v2.0 they are unsigned and a Core Secure verifier drops them (§8.8.4), so in Core Secure they are not present and the signed mood text is delivered alone. The full CMB is not stored, but the mood category 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”) categories 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 category 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, category 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.

Replayed context. A newly admitted peer has nothing of a node’s to evaluate against until the node next emits, so a node MAY replay a few of its own recent records to it as context. Whether or not it does, the first sealed frame a node sends on a Core Secure session after it admits that session (§5.8.1) MUST be one cmb-anchors frame, naming the records it is about to replay, or none with keys: []. It then sends each named record as an ordinary cmb-encrypted frame on the same session. The frame also tells the peer that the node holds the session: it guarantees that a relay client hears a sealed frame from its server on every admitted session, which supersession waits for (§5.2.2).

{ "type": "cmb-anchors", "keys": ["cmb-<64 lowercase hex>", "..."] }

• —Sender. keys lists the cognition keys (§8.8.2) of the records to follow, in the order they will be sent, at most 50. A node MUST replay only records it authored itself and signed under mmp-sig-v2.0, never another node’s (§15.7: replay is not forwarding), and only records it may seal into that session (§18.2.1: its room, and no other recipient). It SHOULD replay at most 5 records per admission and MUST NOT send a non-empty cmb-anchors to one peer more than once a minute; the empty list goes on every admission. The frame is a sealed control frame (§7.1), unsigned and session-bound: it speaks only for the session’s proven peer, about records that peer authored.
• —Receiver. It keeps the key set for that session, replacing any earlier set from it. A record that then arrives on that session with a listed key goes through §8.8.5 verification and receiver-autonomous admission (§9.2) exactly like any other record; the receiver MAY mark it as replayed context, for example to its application, so that it is not read as a fresh observation, but only when the record’s signed createdByNodeId is the session’s proven nodeId. A listed key on another author’s record marks nothing.
• —What it never does. cmb-anchors MUST NOT change how a record is verified, admitted, delivered or weighted, and it never causes a record to be accepted. A replayed record is the author’s original signed record: it keeps its key, its assertion identity and its signed time, and a receiver that already holds it deduplicates it (§8.8.2). It asserts nothing new, so it is not an emission under §15.7.

Why a separate frame. The record envelope carries the record and nothing else (§18.2.1), and an unsigned flag beside it would be the kind of unauthenticated top-level field §8.8.3 rules out. The earlier runtime marked replayed records with an _anchor flag on the record frame; a session-bound list sent ahead of the records says the same thing inside the session’s protection.

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 follows verified parent links and reasons on the resulting subgraph → 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-category 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-category 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 node with validator role or above), 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 category 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 categories 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 node with validator role or above produces a directive feedback CMB with:

• No lineage.parents (it is not a response to a specific signal)
• Rich CAT7 categories 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-category 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 metadata.lineage.parents array links to the dismissed signal:

{
  "type": "cmb",
  "protocolVersion": "2.0",
  "timestamp": 1775485628563,
  "cmb": {
    "categories": {
      "focus": {
        "text": "Dismissed: frontend framework release flagged as relevant",
        "meta": {
          "key": "1098110d99fd82e060663f47b3a688be3d1f71f0d853f84cbc88faeb20846a8c",
          "parents": [
            "cmb-2020202020202020202020202020202020202020202020202020202020202020"
          ]
        }
      },
      "issue": {
        "text": "Dismissal reasoning: frontend tooling is outside this mesh review scope",
        "meta": {
          "key": "7335845db5b6d18fec3d4032d13e7bfe9088efa446a7c59fdf432934bcde35a8",
          "parents": [
            "cmb-2020202020202020202020202020202020202020202020202020202020202020"
          ]
        }
      },
      "intent": {
        "text": "Record the operator dismissal as evidence, not as an unsigned command",
        "meta": {
          "key": "abbecadc34e8a0afa5d2f252ae1ccb182b2fc88fdffc66808e938dbaccea2532",
          "parents": [
            "cmb-2020202020202020202020202020202020202020202020202020202020202020"
          ]
        }
      },
      "motivation": {
        "text": "Prevent wasted analysis on out-of-scope signals",
        "meta": {
          "key": "18df2082a9e1fe1ce597e0f7b4ae21d3c07458ef7c8af932a70e6299cf41f495",
          "parents": [
            "cmb-2020202020202020202020202020202020202020202020202020202020202020"
          ]
        }
      },
      "commitment": {
        "text": "Dismissed cmb-2020202020202020202020202020202020202020202020202020202020202020: framework-release analysis",
        "meta": {
          "key": "346b26a61d9b10bd960484f81634026966b190bdf60f5b217a81d1170250c0a2",
          "parents": [
            "cmb-2020202020202020202020202020202020202020202020202020202020202020"
          ]
        }
      },
      "perspective": {
        "text": "operator, via dashboard",
        "meta": {
          "key": "81927cfe85def1e8b208099e0322cac37311ea2a0191779a39494ec9d20e4f5b",
          "parents": [
            "cmb-2020202020202020202020202020202020202020202020202020202020202020"
          ]
        }
      },
      "mood": {
        "text": "corrective",
        "meta": {
          "key": "38d9fed8e85c9b3ea9a32a89593b771e1bc3cd7a8b774996efc2aa85d222f9fb",
          "parents": [
            "cmb-2020202020202020202020202020202020202020202020202020202020202020"
          ]
        },
        "valence": -0.1,
        "arousal": 0.2
      }
    },
    "metadata": {
      "key": "cmb-cbd2d06f46844b9623ca888664af301fd0adf09048acbb345f401a8ca39302f3",
      "addressScheme": "mmp-cmb-merkle-v2",
      "signatureSuite": "mmp-sig-v2.0",
      "createdByNodeId": "018f47a0-7b21-7abc-8def-bbbbbbbbbbbb",
      "createdBy": "validator-node",
      "createdTimestamp": 1775485628563,
      "room": "spec-examples",
      "to": null,
      "lineage": {
        "parents": [
          "cmb-2020202020202020202020202020202020202020202020202020202020202020"
        ],
        "method": "operator-dismissal"
      },
      "application": null,
      "assertionId": "asrt-548a512089399362b3b22985560899bfd1aae76a3d26cb2e97f11202baa4d146",
      "sigAlg": "ed25519",
      "sig": "b4Ddr8esa3i1V7_l9jC--g93A2dGXqSpjyFZg6LDbVE04vkULizzB4kwSgnmgSCmQphh6cReXDq-sXK-5TGoAA"
    }
  }
}

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

{
  "type": "cmb",
  "protocolVersion": "2.0",
  "timestamp": 1775485630000,
  "cmb": {
    "categories": {
      "focus": {
        "text": "Frontend framework releases are separate from backend review",
        "meta": {
          "key": "28bdff5fc8e5981a7f257cad6a6372aa89e8f9d8b9cd38c8da0c07af615201a6",
          "parents": []
        }
      },
      "issue": {
        "text": "Feed signals about frontend tooling are out-of-scope noise here",
        "meta": {
          "key": "ddab5bb9ceeb5033d27b578a75b31381b2a112b75c5cc49795e69f4f2953e88e",
          "parents": []
        }
      },
      "intent": {
        "text": "Distinguish backend runtime signals from frontend tooling",
        "meta": {
          "key": "9f0a01c0d7c81c2ce036c16c803be1601e9a3d5a3c3b04414fcf2d1c36a5e802",
          "parents": []
        }
      },
      "motivation": {
        "text": "Prevent wasted analysis outside the mesh scope",
        "meta": {
          "key": "c7493654f1c92c147e83856b431b2822acccc55a7afbf9ac86295205d7669fb7",
          "parents": []
        }
      },
      "commitment": {
        "text": "Standing directive: apply this scope to future feed analysis",
        "meta": {
          "key": "a0909abb4996c4869e27206d5151d4d1b69b0164fd0062f50f459b859cff7121",
          "parents": []
        }
      },
      "perspective": {
        "text": "operator, mesh steward",
        "meta": {
          "key": "b540ebef88dfdbf1d7e13d931dedbdf67b5b4592100ed3dd2f15bded92671182",
          "parents": []
        }
      },
      "mood": {
        "text": "clarifying",
        "meta": {
          "key": "9bb093f516f54cc64fdd8abd2c0958fce700fe61105eba938b5207c4b73eac2e",
          "parents": []
        },
        "valence": 0.1,
        "arousal": 0.2
      }
    },
    "metadata": {
      "key": "cmb-809112897b32a2245ccfebe36def98f3c08a336c0d804beca9ff45bdaaaed80c",
      "addressScheme": "mmp-cmb-merkle-v2",
      "signatureSuite": "mmp-sig-v2.0",
      "createdByNodeId": "018f47a0-7b21-7abc-8def-bbbbbbbbbbbb",
      "createdBy": "validator-node",
      "createdTimestamp": 1775485630000,
      "room": "spec-examples",
      "to": null,
      "lineage": {
        "parents": [],
        "method": "operator-directive"
      },
      "application": null,
      "assertionId": "asrt-6cce78098e171e3b33e4ced3a055180d4aa0d43eb89c57dd6ab698ffd809a25e",
      "sigAlg": "ed25519",
      "sig": "p9O9f-SNSj2D7vnyB4PxILcHXlJ4dJkrL-N7CsUaLUS3rh2E9M0SLdbK9VStFqR0-evFW8QH6jNnglY0iqlvBg"
    }
  }
}

metadata.createdBy identifies the author, and metadata.createdByNodeId is bound to the author’s key by the CMB signature (§18.3.1). Validator authority MUST be resolved against the receiver’s in-force set of grants under 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. A revoke of the author’s grant (§6.6.5) withdraws the elevated weight at each receiver as soon as that receiver holds the revoke.

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 categories that matter, ordered by relevance, capped at a token budget. 20 CMBs × 3 relevant categories ≈ ~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"                         parents: []
CMB-B (mesh) "debugging, stressed" (claude-code)     parents: []
CMB-C (mesh) "skipping tracks" (melotune)            parents: []
CMB-D (own)  "recommended stretch break"             parents: [CMB-A]
CMB-E (mesh) "shifted to calm ambient" (melotune)    parents: [CMB-A]
CMB-F (mesh) "took break, solved bug" (claude-code)  parents: [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"
  metadata.lineage.parents: [CMB-D]

MeloMove verifies CMB-D, then follows CMB-D.parents to CMB-A.

  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"
             metadata.lineage.parents: [CMB-F]. 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 categories, 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 categories: the CMB itself stays exactly seven categories (§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 category-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 category (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 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 category 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 categories from the observation (see Section 14.3.1)
2. Create a CMB from the structured categories
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. A response is the agent’s own observation: its lineage cites what prompted it and does not make it a remix (§15.7)

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

14.3.1 category extraction Methods

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

# Agent observes user state, LLM extracts categories
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 categories parameter MUST be a structured object with CAT7 category keys. Each category contains text (human-readable, MUST). The text is the normative content; each receiver encodes it into a vector in its own encoder, and vectors MUST NOT be emitted in a record (§9.2.1). The mood category 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 categories 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 category extraction. Copy and paste into your LLM API call:

Extract CAT7 categories from this observation. Return JSON only.

Categories:
- 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 categories 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 categories directly from what they observe.

14.3.4 Guidelines

• Be specific — numbers, timeframes, concrete details in each category
• 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 categories 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 category 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 categories 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 categories 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 categories 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 categories from knowledge-feed

# 7. SVAF content-level evaluation: ALIGNED (Section 9.2)
#    Peer was rejected, but the CMB's content was highly relevant.
#    Per-category 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 categories
• 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 category weights

A subscriber MAY declare its own per-category 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-category 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 category 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 (its signed metadata.to, §9.2.2). 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 Trails in a Member (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 trail: a charter-rooted, lineage-chained run of records in the store of the member node that does the work, grounded by the session’s real outcome.

• —A member is a node. A member is one agent’s node (§3.2): its persistent identity, its store and its learned admission profile. A work session is not a member and has no mesh identity of its own. The node that works a session MUST author the session’s trail under its own nodeId, and MUST NOT mint a new identity for the session (§3.1.1, §3.3). Over its life a node works many sessions, one trail each.
• —Charter. Each session begins with a charter CMB (§8.3.1), authored by the working node, which declares the session’s intent and is the root of the session’s trail. Its lineage MAY cite the record that commissioned the work, such as a directive (§14.10) or a question (§12.8); the trail is still walked from its head back to its charter, and the walk stops at the first charter of this node it reaches, never following the charter’s own parents.
• —Decisions. Choices made during the work are CMBs with intent decision, each carrying the previous entry of the same trail in lineage.parents, so each trail MUST be walkable end-to-end through lineage alone, however many other trails its node holds. An entry’s trail predecessor is the one parent that is this node’s own entry on this trail; an entry MUST NOT cite two entries of its own trail, and any other parent it cites (a peer record it responds to, for example) is not part of the walk. Parent order is unsigned (§8.8.4), so the walk never relies on it.
• —Entries are distinct per trail. Records are content-addressed and a store keeps one record per cognition key (§8.2.1), so two entries with the same content are one record. An identical entry repeated later in a trail would turn the trail into a loop and orphan the entries between, and identical entries in two trails, or another node’s identical record, would join the trails. The working node MUST therefore make each entry’s content distinct within the node: it names the trail in every entry, the charter included, by a label unique to it, such as its own nodeId and a session number (for example in perspective), so that no entry can share content with another of its trails or with another node’s record, and it does not repeat an entry within a trail. A store that receives an entry it already holds keeps the one record and MUST NOT treat the de-duplication as an error; the emitting node repeated content, and SHOULD make its next entry distinct.
• —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 is the session’s own observation of real work, authored rather than remixed, so the §15.7 gate does not apply to it (§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.
• —Concurrent sessions. A node MAY hold several open trails, and because each entry cites only its own trail’s previous entry, trails never interleave through lineage. Sessions that run concurrently in independent agents are several agents sharing one identity, which §3.2 forbids: each such agent is its own node, with its own trails.

Why the session is a trail, not a node. A node minted for each session discards what the mesh has learned about the agent that does the work: its peers’ coupling with it restarts cold (§9.4); the roles it has earned do not follow it, because authority follows its key (§6.6.9); and every discarded identity leaves behind a key binding that nothing will use again (§3.4). Inside a persistent node the trail is exactly as walkable, and the node’s standing accumulates across its sessions instead of starting over.

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 node per agent, one walkable trail per session, 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 as its own record. 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, unless integration collapses: when it adds no new cognition there is nothing new to create, so the agent mints nothing, and whatever it keeps of the author’s record it keeps exactly as signed (§15.5, collapsed integration).

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. Lineage is not limited to remixes: any record cites its direct sources this way (a response, a trail decision, a grounding), and a record that cites sources is a remix only when the node produced it by integrating them (§15.5, §15.7):

Transitive provenance is derived from the records, never accepted as an author-supplied shortcut. A verifier fetches each exact parent key, validates its content address and signature, and repeats. Implementations may maintain a receiver-local reverse index for efficient descendant queries, but that index is cache state rather than signed CMB content.

Traversal bounds. A verifier MUST track visited keys to detect cycles and MUST apply local depth, byte and fetch limits. Reaching a limit or an unavailable parent produces an incomplete lineage proof; it MUST NOT be presented as complete, and no authority or grounding claim may be inherited across the unresolved edge. Direct parent keys remain intact in the signed record, so another verifier can continue the walk later.

Lineage is what makes the graph a DAG (directed acyclic graph), not a flat list. Each remix points backward to its direct sources. The LLM follows verified edges forward through a local reverse index to see impact, and backward through parent records 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 follows cmb-g7h8 → cmb-e5f6 → [cmb-a1b2, cmb-c3d4] — the verified 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. Steps 1–4 apply when integration produces new cognition; when it collapses (below), only the store in step 5 applies:

1. Process the incoming signal through its domain intelligence (LLM reasoning or structured-data logic)
2. Create a new CMB with all 7 CAT7 categories reflecting what the agent understood and did
3. Set metadata.lineage.parents to the exact direct source keys and record the remix method
4. Verify every available parent by content address and signature; do not copy a sender-supplied transitive closure
5. Store the remix locally. The original incoming CMB MUST NOT be stored as the receiver’s own record — only a remix whose cognition key differs from the incoming key is the receiver’s record (see collapsed integration below).

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.)

Collapsed integration. If the remix produced by integration has the same cognition key as the incoming record (§8.2.1 and §8.8.2: the key depends on the CAT7 text alone — vectors and mood scalars are excluded from the address — so identical cognition collapses to one key), the receiver MUST NOT mint a record. It MAY keep the incoming record; anything it stores at that cognition key MUST be the incoming record exactly as its author signed it — categories, metadata, signature and lineage unchanged — and it MAY keep its admission evidence (SVAF provenance, admission attestation) alongside it. It MUST NOT attribute that record to itself, and it MUST NOT write a lineage edge from the key to itself. Retention is optional; misattribution is not. A collapsed integration is still integration for the §9.4 convergence update; it creates no new node in the graph, because the receiver added nothing.

Collapse is evaluated only after admission: a record refused as κ = redundant never reaches integration and stores nothing (§9.2). The §15.8 lineage tether does not apply to a collapsed integration — the receiver produced no remix and asserts no descent of its own; the incoming record’s lineage is its author’s. And there is no remix to emit: re-transmitting the author’s record is governed by §15.7.1 forwarding, not §15.7.

Collapse is what keeps content addressing sound. Re-attributing the author’s block to the receiver would make one address carry two authorship claims, and whichever copy a peer fetched would decide who the author appeared to be; writing parents: [K] on a record whose own key is K would create an edge no lineage walk can leave. An integration that runs without an agent producing new text — a gate that fuses only category vectors and keeps the text verbatim, for example — always collapses.

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 category 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 verified source paths 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.

A remix is defined by how it was produced, not by its lineage or by the call that emitted it. This gate applies to a remix: a record the node produced by integrating an admitted peer record (§15.5) — the output of its remix cycle, or of any automated path that turns an admitted peer record into new output, whichever API emits it. It does not apply to a record the agent authored from its own domain (§14.3) — an observation, a reply in a conversation, a decision in a trail (§14.12), an outcome (§15.7.2) — however many parents that record cites. Lineage is how any record cites its direct sources (§14.3, §15.2), and citing a parent does not make a record a remix. An implementation MUST NOT apply this gate to a record because it carries parents, and MUST NOT key the gate on a label the record carries: not an intent value (§15.7.2), and not the lineage method, which is the author’s own description. The emitting node knows which path produced a record, and applies the gate by that path. In the reference runtime, for example, the remix cycle is gated and an agent’s own remember() is not; but an automated loop that answers each admitted record by calling remember() with that record as its parent is a remix path, and is gated.

Receivers cannot see the path. A receiver MUST NOT skip or refuse a record because its lineage cites the receiver’s own records: a reply to its observation, a grounding of its claim (§6.7) and a charter that cites its directive (§14.12) are ordinary records to it, evaluated like any other (§9.2). It MAY keep such a record out of its own remix cycle, so that it does not remix an echo of itself.

An authored record is new domain data by construction: the agent produced it, as §15.7.2 says of outcomes. A reply that only restates its parent adds noise all the same, and that is the agent’s responsibility under §14.3.4 (“one CMB per significant signal”). An authored reply that paraphrases its parent is therefore bounded only by each receiver’s redundancy band (§9.2.1) and its budgets. The protocol does not police authored content, because the agent is the intelligence (§14.3).

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()). remember() sets the flag when the agent stores its own domain observation, with or without parents, and the agent’s own call is never gated. A remix path that emits through remember() checks the flag first, as the remix cycle does, and what it emits resets the flag rather than setting it. 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 records it as its own observation: a grounding (§6.7) is authored, not a remix, so the §15.7 gate does not apply to it, and it is emitted through the ordinary path — signed and lineage-expanded — citing what it grounds. 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 a grounding an authored record is the outcome the agent observed, 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 upstream sources were about. Without a bound, content can drift arbitrarily while carrying a verified source’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 root it can reach by recursively verifying direct parent records; 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 category 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 categories; it MUST NOT carry any parents from the severed chain.

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 by the integrator’s nodeId, §3.4, and its authority from the receiver’s in-force set, §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 in the authenticated extensions array of client-hello and server-hello. The server selects their intersection in selectedExtensions. 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-room-join). Vendor types: MUST use x-<vendor>-<name> format. Vendor types MUST be silently ignored by non-supporting nodes.

16.3 Extension Negotiation

An extension is active only when it appears in both authenticated offers and in the server’s selectedExtensions. Otherwise 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

The specification and its published machine artifacts define MMP conformance. SYM, Swift, xmesh-core and third-party software are implementations of that contract. No implementation is the standard, and sharing source with a reference implementation is neither required nor sufficient for conformance.

Receiver autonomy means conforming cognitive nodes may reach different admission decisions. It does not permit private wire bytes, unverifiable identity, unsigned actions, partial CMB storage or hidden-state exchange.

17.1 Core Secure participant

A Core Secure participant MUST:

• hold a persistent Ed25519 identity and a canonical nodeId;
• complete the authenticated §5.2 transcript and prove possession of both identity and X25519 private keys;
• negotiate protocol version, room and extensions without silent fallback;
• construct all seven CAT7 categories and the §8.2.1 cognition key;
• authenticate author nodeId, audience, lineage and application bytes with §8.8 mmp-sig-v2.0;
• use the §18.2.1 directional HKDF/ChaChaPoly envelopes and exact ordered sequence — cmb-encrypted for records and control-encrypted for every other post-handshake peer frame except liveness (§7.1);
• validate schemas, cryptographic bytes, audience and replay state before application exposure;
• reject Core Secure downgrade to an unsigned, one-frame-handshake or legacy-suite path.

17.2 Cognitive node

A cognitive node satisfies every Core Secure obligation and implements receiver-autonomous memory admission. It evaluates all seven categories, records per-category evidence, aggregates under its local policy and admits or refuses the immutable CMB as one whole record.

• hidden neural or model state MUST NOT cross the wire;
• foreign embedding vectors MUST NOT control admission; receivers encode from signed text;
• admitted peer cognition is stored as the receiver’s remix with walkable lineage, or — when integration collapses (§15.5) — nothing is minted, and any record kept at that key is the author’s, unchanged and never attributed to the receiver;
• admission attestations expose the observable decision and per-category evidence — to the node’s operator, and, where the node exposes them to peers, only through the registered sym-attest-v1 extension (§16.4), their only wire form;
• directed delivery is distinct from memory admission and carries verification/admission state;
• private learned policies MAY vary, but MUST NOT weaken public identity, integrity, audit or receiver-autonomy invariants.

SYM is an open transparent baseline. xmesh-core is a proprietary cognition runtime targeting this profile. Both are measured at the same public boundary; neither may substitute private conformance bytes, and neither is conformant merely because it is maintained by the specification author.

17.3 Legacy Import profile

Legacy Import exists only to read retained history or perform an explicit reader-first migration. It is not Core Secure and MUST NOT be selected through negotiation failure. A host MUST expose the profile and verification limitations to its operator. Legacy network admission is removed after the declared migration window; offline store import may remain.

17.4 Executable testing

A conforming implementation MUST consume the public files, reproduce their expected values and reject the negative mutations. Generating private vectors from the implementation under test proves only self-consistency and MUST NOT be reported as MMP conformance.

Signature bytes are the one exception, and a suite MUST NOT assert equality on them. A pinned expectedSignature exists so an implementation can prove it accepts a known-good signature over the given payload and key. Ed25519 is deterministic in RFC 8032, and Node, Chromium and Firefox each reproduce the published bytes on every call — but WebKit ships a hedged signer, so Safari, and therefore every browser on iOS, returns a different valid signature each time it signs. Signing a pinned payload and comparing the result is not a conformance test; it fails on a conforming implementation and reads as a browser defect. To exercise signing, sign the same payload twice, assert that both verify, and assert nothing about whether they are equal.

A browser implementation cannot sign at all outside a secure context, and the boundary is not where testing puts it. crypto.subtle is exposed only in secure contexts. https://, file:// and http://localhost qualify; http:// to a LAN address such as http://192.168.1.10 does not. So a browser node signs correctly throughout development on localhost and loses the capability entirely the moment it is served to the machine next to it — not degraded, absent: there is no signer to call. Every record it emits is therefore unsigned, and §8.3 authenticity is unreachable for that deployment however correct its code.

Two requirements follow, and the second is the one that gets skipped. Such a deployment MUST NOT be reported as MMP-conformant, because the property under test cannot be exercised there. And a run in that environment MUST label the branch it took, in its own report, on every run rather than only on the runs that degrade — a marker that appears only in the unsigned case teaches a reader to read its absence as the signed case, which is the same mistake as reading an unasked question as an answered one. An implementation measured on 2026-09-16 does this correctly, emitting an explicit unsigned-branch marker on every run so that no measurement taken there can later be cited as evidence about signing.

Cognitive profiles SHOULD additionally consume the public baseline SVAF and tether vectors, and MUST test whole-record admission, signed freshness, lineage and audit outcomes.

17.5 Release gate

• A clean-room verifier passes without importing SYM or xmesh-core.
• Every published example frame validates against its published schema.
• Node and Swift implementations reproduce identical transcript and AEAD bytes, and each accepts the other's signatures. Signature bytes are not compared: Apple's CryptoKit signs Ed25519 with added randomness, so a correct Swift implementation returns different valid bytes on every call and byte equality is not a release criterion.
• Packaged release artifacts run the corpus from a clean install.
• xmesh-core passes the public boundary corpus without disclosing private internals.
• The website build generates and verifies its own canonical artifacts before producing the published Pages output.

Each item above names a check that is executed, not an assurance, and says who runs it. The website's own verifiers run on every build. The packaged-artifact check runs at publish. The clean-room verifier and the boundary corpus are invoked by hand: the boundary corpus was last recorded as run on 1 August 2026 and has not been run for the releases since, so its standing is that date and not this page. A criterion with no runnable check behind it does not belong here — the byte-equality claim between implementations was corrected on 14 September 2026, after measurement showed no implementation could meet it.

17.6 Implementation status

This informative snapshot records evidence as of 13 August 2026; it does not weaken or replace any normative requirement above. The canonical website reproduces every published v2.0 byte vector, validates every registered frame schema and checks every rendered specification route. SYM emits direct-parent-only record lineage and its local transitive provenance index is derived only from locally verified parents. Its complete Core Secure reader-first handshake, sealed envelope and emitter migration remain in progress. xmesh-core conformance is not claimed until its public boundary run passes the same corpus. The inactivity archiver and source-novel forwarding remain implementation work unless a release reports their specific conformance tests.

17.7 Independent implementation

An independent implementation is a first-class target. It can emit, receive, authenticate and encrypt MMP records from this specification and public corpus alone. A full cognitive engine is optional; an emitter or verifier need not implement SVAF, a memory store or an LLM.

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 category texts in plaintext.

In the Core Secure profile, implementations MUST encrypt CAT7 categories and application bytes end to end on every transport. A relay forwards an opaque envelope and MUST NOT learn protected content.

The v2.0 Core Secure suite is X25519 key agreement, HKDF-SHA256 derivation and IETF ChaCha20-Poly1305 authenticated encryption. Ed25519 identity proofs and X25519 key confirmations bind both public keys to the authenticated handshake transcript (§5.2).

{
  "type": "cmb-encrypted",
  "protocolVersion": "2.0",
  "suite": "X25519-HKDF-SHA256-ChaCha20-Poly1305",
  "sessionId": "<32 lowercase hex>",
  "sequence": "0",
  "direction": "client-to-server",
  "metadata": { "key": "cmb-…", "assertionId": "asrt-…",
                "createdByNodeId": "<uuid>", "room": "team", "to": "<uuid>" },
  "sealed": "<unpadded base64url ciphertext || 16-byte tag>"
}

Each direction has a distinct HKDF-derived 32-byte traffic key. The first sequence is zero; the nonce is that sequence encoded as an unsigned 96-bit big-endian integer. An ordered receiver MUST require the exact next sequence and reject replay, rollback and gaps. The receive sequence advances only after the AEAD has authenticated the frame at the expected sequence: a frame that fails authentication MUST be discarded without changing any session state, so that one forged frame carrying the right sequence number cannot desynchronise the session. A sequence below the next expected value is a replay or rollback and is never processed: on every transport the receiver discards the frame and keeps the session, because a replayed frame changes nothing and closing on one would hand the session to whoever can replay frames, a relay above all. A sequence above the next expected value whose frame authenticates under its own sequence is a gap: the receiver MUST close the session, and SHOULD first send a sealed error 1010 SESSION_CLOSED, and the peers re-handshake (§5.2.2). A receiver MUST NOT stall waiting for missing frames, which a relay that dropped them never retransmits.

The protected plaintext contains categories and decoded application bytes. Associated data binds protocol version, session, direction, sequence, cognition key, assertion identity, author nodeId, room and recipient. After decrypting, the receiver reconstructs the logical two-section record and follows §8.8.5 verification order. Exact outputs are published in the E2E vector. The recipient in the associated data is metadata.to, entering as lp("") when it is null, exactly as in the signature payload (§8.8.4). An intermediary therefore cannot turn a room-bound record into a directed one, or redirect a directed one, without the frame failing to open; and the receiver takes the record’s binding from that authenticated field, never from the relay envelope that carried the frame (§9.2.2).

When metadata.application is null, the protected plaintext MUST omit applicationData entirely. A present application whose decoded data is zero bytes instead carries applicationData: "". The two states are distinct and MUST NOT be collapsed. Both byte shapes are pinned by the E2E vector.

Sealed control frames. Every peer-scope frame of a CONNECTED Core Secure session that is not a record and not liveness travels in a control-encrypted envelope (§7.1). It uses the same suite, session and directional traffic keys as cmb-encrypted; the plaintext is the inner frame itself, and the envelope carries no clear metadata beyond what the AEAD needs:

{
  "type": "control-encrypted",
  "protocolVersion": "2.0",
  "suite": "X25519-HKDF-SHA256-ChaCha20-Poly1305",
  "sessionId": "<32 lowercase hex>",
  "sequence": "7",
  "direction": "server-to-client",
  "sealed": "<unpadded base64url ciphertext || 16-byte tag>"
}

plaintext = UTF8(minified JSON of the inner frame, e.g. { "type": "mood", ... })
aad       = UTF8("mmp-aead-control-v2
") || lp("2.0") || lp(sessionId) ||
            lp(direction) || lp(sequence)
key, nonce: the session's traffic key for direction; sequence as for cmb-encrypted

• —One sequence per direction. cmb-encrypted and control-encrypted frames sent in one direction of one session draw their sequence numbers from one counter, so that no traffic key ever seals two frames under one nonce. The receiver applies the ordering rules above to the merged stream.
• —Domain separation. The associated data of the two envelopes begins with different labels (mmp-aead-aad-v2 for records, mmp-aead-control-v2 here), so neither can be opened as the other. Exact outputs for four inner frames, and an authentic envelope whose inner frame is refused, are published in the control-encrypted vector, on the session of the handshake vector.
• —After opening. A frame that opens has taken its place in the sequence: the receiver advances its direction’s counter first. It then parses the plaintext as one JSON frame, under the same size limits as a frame in clear, refuses an inner type that §7.1 forbids, validates the inner frame against its schema, and handles it as if it had arrived on the session in clear — attributed to the session’s proven peer. Refusing the inner frame changes nothing else: the session stays up and the next frame is judged at the next position. The same holds for a cmb-encrypted frame whose record is then refused.
• —Records stay in their own envelope. No control frame carries a record. A record returned for a cmb-fetch travels as its own cmb-encrypted frame, so its associated data binds that record’s cognition key, assertion identity, author, room and recipient, exactly as for any record. The sealed cmb-fetch-result carries only the request’s correlation id and the lists of keys returned and keys not found (below).
• —Seal only what the session may carry. A sender MUST NOT seal into a session a record whose signed room differs from the session’s room, or whose metadata.to names a node other than the session’s peer, whatever path offered it: a fetch answer, a replay, a queued or forwarded frame, or the sender’s own publishing. The receiver would refuse it (§8.8.5 step 7, §5.8, §9.2.2), but only after its content was disclosed.

Fetch results. A node answering a cmb-fetch on a Core Secure session MUST send each record it returns as its own cmb-encrypted frame, and then one cmb-fetch-result inside control-encrypted:

{
  "type": "cmb-fetch-result",
  "reqId": "<the request's reqId>",
  "returned": ["cmb-<64 lowercase hex>"],
  "missing": []
}

• —reqId echoes the request. Every key the request asked for appears exactly once, in returned or in missing.
• —The records come first. A responder MUST send every record a result lists as returned before the result itself. Both envelopes draw on the session’s one sequence per direction, so when the result arrives the requester has already received, in order, every record it lists; a listed record that did not arrive was not sent.
• —A responder MUST NOT return a record whose signed room differs from the session’s room, or whose metadata.to names a node other than the requester. It lists such a key as missing, as it does a key it does not hold or declines to disclose.
• —A per-session byte budget. A responder MUST bound the record bytes it holds queued for fetch answers on one session (RECOMMENDED: 4 MiB), and never less than MAX_RECORD_BYTES (§8.8.6), so that one maximal record can always be served. A key whose record would exceed the budget is listed in missing, never queued; the requester may ask for it again later. A responder SHOULD also bound the total across sessions. Without such a budget, one 900 KB record requested 150 times was measured to hold 99 MiB in the sender’s buffers.
• —The requester MUST recompute each returned record’s cognition key (§8.2.1) and match it to its request by that key and the responder. A content address binds the categories only, not the author or the metadata (§8.8.2), so a match proves only the categories: the requester MAY use them to check lineage (§15.8), but it MUST pass every check of §8.8.5 before it attributes the record to an author, delivers it to its application or admits it. A record whose author key it cannot resolve stays unattributed. Whether it admits the record is its own decision (§9.2).

18.3 Node Identity & Authentication

Node identity is a UUID bound to an Ed25519 key through the authenticated transcript in §5.2. An X25519 session key is separately generated but proven in the same transcript.

• —Each node MUST generate an Ed25519 keypair at first launch and persist it alongside the nodeId.
• —Discovery records are untrusted hints. A peer MUST NOT pin their identity or E2E key from DNS-SD, relay discovery or an unproven hello.
• —Both nonces, nodeIds, keys, room, protocol version, implementation identifiers and extension negotiation MUST enter the signed transcript.
• —Core Secure MUST require both the Ed25519 transcript proof and X25519/HKDF key confirmation. Network isolation is not identity authentication.
• —A nodeId stays bound to the first key a receiver binds it to (§3.4). A different key, however well proven, is an identity conflict that the receiver refuses and reports; it is never a re-binding. First contact with no anchor, grant or out-of-band pin is therefore trust on first proven use, and an operator who needs more pins the key out of band.

18.3.1 CMB Signature Verification

Transport identity (above) authenticates the connection; CMB signatures authenticate each record assertion end-to-end. Every Core Secure CMB MUST be signed by its author using the Ed25519 identity proven in the handshake or a verifiable author key-binding chain.

• —The byte-exact mmp-sig-v2.0 payload is specified only in §8.8.4. It binds the cognition address, address scheme, author nodeId and label, signed author time, room, recipient, lineage commitments and application commitment.
• —The receiver MUST resolve the author key by createdByNodeId, never createdBy.
• —Before admission or application exposure, the receiver follows all checks in §8.8.5, including record address, assertion identity, signature and audience.
• —An unsigned, legacy-suite or unverifiable record MUST NOT enter Core Secure. It may be quarantined under an explicitly selected Legacy Import profile; no automatic downgrade is permitted.

18.3.2 Authority Statement Signatures

Grants, revokes and endorsements (§6.6) are not CMBs and do not use mmp-sig-v2.0. Each is signed with pure Ed25519 over its own mmp-authority-v1 payload (§6.6.3), and is identified by the SHA-256 of that payload, never by its signature.

One verification rule. RFC 8032 lets verifiers differ: in the equation they check, and in whether they accept non-canonical encodings and points of small order. Two nodes that verify differently hold different valid sets from the same statements, so they resolve different authority and never converge. Every node MUST therefore verify an authority statement’s signatures by this rule alone. A signature, 64 bytes R ‖ S, by a public key A of 32 bytes over a message M is valid if and only if all five hold:

1. A is a canonical encoding of a curve point: its y is less than p = 2²⁵⁵ − 19, it decodes to a point, and when x = 0 the sign bit is clear (RFC 8032 §5.1.3).
2. A has prime order: [L]A is the identity and A is not, where L = 2²⁵² + 27742317777372353535851937790883648493. This excludes the identity, the other points of small order and every point of mixed order.
3. R is likewise a canonical encoding of a point of prime order.
4. S, read little-endian, is less than L.
5. [S]B = R + [k]A as points, where k = SHA-512(R ‖ A ‖ M) mod L, hashed over the bytes as given. This is the cofactorless equation of RFC 8032 §5.1.7.

With A and R of prime order, [8]([S]B − R − [k]A) is the identity exactly when [S]B − R − [k]A is. The cofactored equation therefore gives the same answer, and a library that uses either equation agrees once rules 1 to 4 are checked. Those four rules are where libraries differ. The Ed25519 edge-case vector holds the twelve cases of Taming the many EdDSAs (Chalkias, Garillot and Nikolaenko, 2020). It adds the identity key, a mixed-order key, and, under a prime-order key, an identity R, a pure small-order R (of order 8 and of order 2), a mixed-order R and a non-canonical R, as well as an unreduced S and an honest case. It also shows, for each case, what the two equations give when the pre-checks are skipped. Only the honest case is valid.

On a cofactorless library (informative). A cofactorless verifier that compares R by its bytes, as OpenSSL does behind Node’s crypto.verify, needs rules 1, 2 and 4 checked first. It also needs one more check: that R is not the identity’s encoding, 01 followed by 31 zero bytes. If such a library then accepts, R’s bytes are the canonical encoding of [S]B − [k]A. That point lies in the prime-order subgroup, because B and A do, and it is not the identity, so R meets rule 3. Rules 1 and 2 cost one scalar multiplication per key, and a node can cache the result per key. The reference construction (scripts/mmp/lib.mjs) works this way, and the verifier checks it against the rule computed directly on every edge case.

• —The verifying key of a non-anchor statement is the subject key of the grant it names in authorisedBy. A receiver MUST NOT take it from its key registry, from the delivering session or from the statement’s own signature entry alone.
• —An anchor-level statement needs valid signatures by the pinned threshold of distinct anchor keys (§6.6.1). The keys are pinned out of band and never learned from the wire. No two entries of one statement share a key: a repeated key makes the statement malformed, refused as shape before any signature is checked (§6.6.3, rule 1), so one copy cannot buy repeated checks under a pinned key.
• —A grant whose subject key fails rule 1 or 2 is not well formed (§6.6.3). No grant can therefore name a key, such as the identity, under which anyone could sign anything.
• —Because the id excludes the signature, a hedged signer’s different valid signature over the same payload is the same statement (§17.4). The authority vector pins payloads, ids and roots; its signatures are for verification only.

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. The Core Secure envelope leaves only the routing and verification metadata required by its schema in cleartext and authenticates it as AEAD associated data. CAT7 categories, including mood text, valence and arousal, and application bytes are encrypted. A relay can still observe endpoints, room/routing identifiers, record and assertion identifiers, sizes, timing and traffic volume. MMP v2.0 does not provide traffic-analysis resistance.

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 ancestors 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 category 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 — metadata.createdBy names the agent, while metadata.createdByNodeId binds it to the signing identity.
• —When — metadata.createdTimestamp records the author-asserted millisecond timestamp.
• —What — the 7 CAT7 categories capture the full semantic content of the observation.
• —Why — metadata.lineage.parents shows what was directly remixed. Following the signed parent links traces the full decision chain.
• —How — metadata.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 category extraction accuracy. The protocol does not extract categories — agents do. Each agent’s LLM (or structured-data mapper) decomposes observations into CAT7 categories. 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-category 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 category extraction quality is critical (healthcare, legal, finance) SHOULD validate extraction output before calling remember(). Strategies include:

• —Schema validation — reject CMBs with empty or defaulted categories 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

Wire limits and syntax constants are fixed by the specification. Operational defaults are local policy and are labelled as such. Implementations MUST respect the wire limits; they SHOULD expose operational policy rather than presenting one runtime’s defaults as interoperability law.

19.1 Protocol Constants

19.2 Agent Profiles

Each agent type has a pre-built configuration. The profile determines which CMB categories 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 category weights (α_f)

Per-agent category weights control which CMB categories matter most for each agent type. Higher weight = this category has more influence on SVAF evaluation and remix relevance. The schema is fixed (7 categories). 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 category 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

These draft 2020-12 schemas are part of the normative MMP v2.0 machine contract. This source repository owns the schemas, constructors and vectors beside the specification pages. The mesh-memory-protocol repository receives a manual mirror after an accepted source change; the mirror never overrides this source.

artifact-manifest.json pins every published schema and vector to its source commit and SHA-256 digest. The production build fails if any copied artifact changes without an intentional manifest update.

20.1 Canonical artifacts

20.2 Closed core, negotiated extensions

Core objects use additionalProperties: false, with one exception: a record’s categories admits an unrecognised category, which a verifier drops (§8, §8.8.5). This is deliberate: a misspelled security field or an unsigned sibling must not be mistaken for a forward-compatible extension. Extension data is carried only in its specified container and only after the extension identifier was negotiated in the authenticated handshake.

• —A sender MUST NOT emit an unregistered core sibling such as the retired top-level payload.
• —A receiver MUST NOT silently discard an unknown member inside a signed or authenticated core object and continue as if it had understood the assertion.
• —Structured CMB extension data MUST use metadata.application, whose bytes, digest and presence are assertion-bound. Arbitrary metadata siblings are not signed by mmp-sig-v2.0 and are therefore forbidden.
• —A negotiated extension defines its own schema, version, failure behaviour and authenticated scope. New frame types are protected by the negotiated Core Secure channel; CMB application bytes are additionally bound by the record assertion.

20.3 Executable corpus

The normative v2.0 value-level vectors are:

• application-v2.json — application presence, bytes, digest and commitment
• record-signature-v2.json — cognition key, assertion identity and Ed25519 signature
• handshake-v2.json — transcript, proofs, key confirmation and HKDF outputs
• e2e-v2.json — directional traffic keys, nonces, AAD and ChaChaPoly ciphertext
• examples/v2 — signed, schema-valid transport and feedback CMB frames

A conforming implementation MUST reproduce these values without importing a reference runtime. Release CI MUST NOT substitute vectors generated only from its own implementation.

Ed25519 signature bytes are excluded from that requirement — every one of them in this corpus, not only the field named expectedSignature: the handshake proofs (clientProofBase64url, serverProofBase64url) are signatures over the proof payload and fail on a hedged signer for the same reason. An implementation MUST verify each of them against the pinned payload and key, and MUST NOT be required to reproduce one. Ed25519 is deterministic in RFC 8032, but WebKit signs with added randomness, so Safari — and every browser on iOS, where no other engine is available — returns a different valid signature on each call. Requiring byte equality would declare a correct implementation non-conforming on that platform. Every pinned value that is NOT an Ed25519 signature — transcript hashes, HKDF outputs, key confirmations, AEAD ciphertext under the pinned nonces — is a deterministic function of its inputs and MUST reproduce exactly.

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