← Start Here · This is Step 6a: The Specification
A frozen, language-independent, runtime-independent specification for Experience objects. The rules that all Experience must conform to.
FROZEN · Version 0.1.0-draft · 2026-09-09
The Protocol is the specification — the rules that all Experience must conform to. It does not store Experience. It does not serve Experience. It defines what Experience is.
5 required fields: id, content, fingerprint, source, outcome. Plus 2 state fields (lifecycle, authorization), 7 optional fields, and 3 embedded objects.
Provenance answers: where did this Experience come from? Lineage answers: what did this evolve from? Both are embedded in every Experience object.
VerificationAttestation records: who verified, by what method, what result, with what evidence. Append-only. Empty or absent = unverified.
Important: SHA-256 fingerprint detects integrity changes. It does NOT prove the event or outcome was valid.
Three states: private, shared (with allowed consumers), public. Authorization controls who can retrieve, not who owns.
"Where did this Experience come from?"
Records the origin: producer, process, time, place. Embedded in every Experience.
"Was the event/outcome sufficiently validated?"
Attestation records with verifier, method, result, evidence. A separate layer from provenance.
"Can we detect integrity changes?"
LAO-FP-v1: NFC normalize → trim → UTF-8 → SHA-256. Content-only hashing. Does NOT prove validity.
"Who has claims on this data?"
Not handled in the Protocol. Ownership and rights belong to the downstream behavioral asset chain.
The Protocol is not a single document. It is five interdependent artifacts. The Frozen Specification is the sole normative source of truth.
experience-protocol-v0.1.md — 1,249 lines. 17 normative sections. The ultimate authority.
TODAY — frozen
experience.schema.json — 229 lines. Machine-readable validation for all fields, enums, formats.
TODAY — frozen
Independent provider/consumer library. Depends only on the Frozen Protocol and Schema.
TODAY — verified
Independent provider/consumer library. Same constraints as Python.
TODAY — verified
29 tests: cross-language fingerprint consistency, bidirectional registration/retrieval, cross-language attestation, unified error contract.
TODAY — 29/29 passed
The Protocol is a complete specification. The Runtime integration is not yet built. This is an honest status report.
| Capability | Protocol | Runtime | Bridge |
|---|---|---|---|
| Experience generation | Schema defined | Pipeline B active (produces Anchors) | PARTIAL — constraint injection proven (16/16); full Anchor→Experience adapter is NEXT |
| Experience registration | Provider Contract defined | N/A | NEXT — Catalog HTTP client defined, Runtime integration pending |
| Experience retrieval | Consumer Contract defined | N/A | NEXT — Catalog HTTP client defined, Runtime integration pending |
| Experience reuse | Out of scope | Anchor-based reuse works | NEXT — anchor reuse works; Protocol-compatible reuse pending |
| Fingerprint | LAO-FP-v1 defined | 4 different algorithms | NEXT — none is LAO-FP-v1 yet |
| Cross-language interop | 29/29 tests passed | Python only | NEXT — Runtime not integrated |
The Protocol is ready. The constraint injection path is proven (16/16 tests). The full Anchor→Experience adapter is the next engineering task.
| Claim | Status |
|---|---|
| Protocol v0.1 Frozen Specification exists | TODAY |
| JSON Schema defined and frozen | TODAY |
| Python + TypeScript reference implementations exist | TODAY |
| Cross-language interoperability verified (29/29) | TODAY |
| Runtime produces Protocol-conformant Experience | NEXT — constraint injection proven 16/16; full adapter pending |
| Runtime registers/retrieves from Catalog | NEXT — constraint injection proven 16/16; full adapter pending |
Without a shared specification, every Agent defines "Experience" differently. Experience that one Agent produces cannot be understood by another. The Protocol makes Experience interoperable — across Agents, across languages, across organizations.
Protocol defines the rules → Catalog enforces the rules → Agents benefit from the rules
This is the technical specification. Want to see what it enables for Agent behavior?