8. Cognitive Memory Blocks (CAT7)

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

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

8.1 Why 7 Fields

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

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

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

8.2 Field Schema

Implementations MUST use the following 7 fields in this order:

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

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

8.2.1 Content Address & Canonical Serialization

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

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

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

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

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

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

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

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

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

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

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

8.3 Field-by-Field Guide

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

8.3.1 Well-Known Intent Values Informative · New in 1.1.0

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

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

8.4 Per-Agent Field Weights (α_f)

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

8.5 Artifacts

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

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

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

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

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

8.6 Origin

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

8.7 Authentication

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

Q&A