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.