8. CMBs (CAT7) — MMP Specification

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.

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 method (the fusion method used). 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.

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-normalised (UAX #15). 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.
• —New v2.0 records MUST declare mmp-cmb-merkle-v2; a verifier MUST NOT guess among address derivations sharing one prefix.

8.8.5 Verification order

1. Validate the negotiated frame and record schemas.
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.
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.