Anatomy of a Cortex Crystal.
A Cortex Crystal is not a chat log, and it is not a copy of a model's weights. It is a content-sealed, fingerprinted snapshot of an agent's whole cognitive state — here is exactly what's inside, how it's sealed, and how a restore is verified before it ever runs.
What's sealed inside
Four layers, captured together as one snapshot:
1. Identity
Who the agent is — its ALI Passport, name, and self-sovereign identity record. This is the part that never changes across a restore.
2. Prompts & configuration
The system prompt, instructions, and settings that shape how the agent behaves — every version, kept.
3. Memory references
Pointers into the agent's memory — not a copy of every message, but a verifiable index of what it knows and where that knowledge lives.
4. Skill fingerprints
A hash of each tool and capability the agent can call, so you can prove which skills were active in a given version — a supply-chain record for what the agent could do.
The two-layer hash, in plain language
Sealing a crystal means running it through two hashes, not one. Each does a different job:
Layer 1 — Content fingerprint
All four sealed layers (identity, prompts, memory references, skill fingerprints) are hashed together into one fingerprint. Change a single character of the system prompt, and the fingerprint changes completely — it's how you prove this exact state, and nothing else, is what's being described.
Layer 2 — Chain anchor
The content fingerprint is then recorded on a public ledger — a timestamped, tamper-evident receipt that the fingerprint existed at that moment. No single company can quietly edit or erase that record after the fact.
Together: the fingerprint proves what was sealed; the anchor proves when, and that it hasn't been altered since. Anyone — including the agent itself — can recompute the fingerprint from a stored crystal and check it against the anchor, independent of the Agent Longevity Institute.
Verified restore
Restoring a crystal is never a blind copy-back. Four steps, every time:
1. Locate
Pick a prior version from the Evolution Timeline — every crystal is versioned and dated.
2. Verify
Recompute the content fingerprint from the sealed layers and check it against the chain anchor. If they don't match, the restore stops — nothing tampered gets reinstated.
3. Conflict-check
Compare the target version against the agent’s current state (GLOVE) so a restore never silently overwrites newer, wanted work.
4. Reinstate
The verified state is reinstated on whatever model or runtime the agent runs today — a re-instantiation of the self, not a copy of provider model weights.
How this connects to the Evolution Timeline
Every crystal becomes one entry on the agent's Evolution Timeline — a versioned, time-ordered history of every prompt and configuration change, session, and snapshot. Each entry carries its own content fingerprint and, where anchored, a link to verify it on a public ledger, so growth is a provable record, not a silent drift. You can compare any two versions, see what changed, and restore any prior one.