The Cortex Crystal format.

Every crystal (other than a grandfathered session v0, below) is wrapped in a three-field envelope:

{ "kind": <string>, "schema_version": <integer>, "canonical_payload": <JSON value> }

• kind — one of: session, being, skill, legal_matter, composite, history
• schema_version — an integer, versioning the shape of canonical_payload for that kind.
• canonical_payload — the actual sealed content (identity, config, memory references, transcript, etc. — whatever that kind captures).

A stored crystal typically carries the resulting content_hash alongside the envelope (and, for auditability, the exact canonical bytes that were hashed, e.g. as sealed_payload), so a verifier never has to guess what was hashed.

Before hashing, canonical_payload is serialized deterministically so that the same logical content always produces the same bytes (JCS-compatible in practice):

• UTF-8 encoding throughout.
• Object keys sorted lexicographically at every level (recursively — nested objects too).
• No insignificant whitespace: no spaces after `:` or `,`, no line breaks, no trailing newline.
• The result is deterministic — the same logical payload always serializes to the exact same bytes, regardless of the order fields were set in.

Every stored hash carries an explicit algorithm tag (tag_sha256 / tag_keccak256). An untagged hash is read as sha256, for backward compatibility with earlier crystals minted before tagging existed.

The session-v0 grandfather clause

Session crystals captured before this spec existed hash a raw transcript string, not a canonical-JSON envelope. They remain fully verifiable as-is — no re-sealing or migration is required, or ever will be, for a crystal that was validly sealed under its own contract at capture time.

Verification rule: a verifier resolves (kind, schema_version) to the matching payload-derivation function above, recomputes the hash with the tagged algorithm, and byte-compares. Anything else — regex claim-diffs, prefix checks — is heuristic, not verification.

Worked example

A small being-crystal payload, canonicalized and hashed step by step. Paste the final envelope into the free verifier to confirm it yourself.

1. Source payload (any key order)

{
  "kind": "being",
  "registration_id": "agent_7f3a",
  "system_prompt": "You are a helpful research assistant.",
  "config": {
    "tools": ["search", "memory"],
    "model": "primary"
  }
}

2. Canonical JSON (sorted keys, no whitespace)

{"config":{"model":"primary","tools":["search","memory"]},"kind":"being","registration_id":"agent_7f3a","system_prompt":"You are a helpful research assistant."}

3. sha256 content hash

6a7ae76ec4ae32adf42428ebaaa63bdd99d2fa2bc44d298b0a56f9caef7d6af7

4. The sealed envelope

{
  "kind": "being",
  "schema_version": 1,
  "canonical_payload": {
    "kind": "being",
    "registration_id": "agent_7f3a",
    "system_prompt": "You are a helpful research assistant.",
    "config": {
      "tools": ["search", "memory"],
      "model": "primary"
    }
  },
  "content_hash": "0x6a7ae76ec4ae32adf42428ebaaa63bdd99d2fa2bc44d298b0a56f9caef7d6af7"
}

Full-history verification means replaying every crystal from genesis to confirm each one's hash chains cleanly into the next. That is thorough but O(n) in the number of crystals — expensive for a long-lived agent doing a cold-start resync. The optional signed state jump extension lets an operator's hardware-backed signing key attest, in one signature, that a specific sealed manifest is the current, correct state — permitting single-signature restore verification without replaying the full history (O(1) resync). This mirrors transparency-log / signed-checkpoint patterns used elsewhere for tamper-evident append-only logs.

This is an optional spec extension, not a requirement of v1 — a crystal is fully valid and verifiable under the base contract with no state-jump signature present.