Experience Catalog v0.1 — the registry

What the Catalog does

The Catalog is the instantiation of the Protocol — the actual registry where Experience objects are stored, discovered, and retrieved. It enforces lifecycle, authorization, and fingerprint integrity.

① Registration

POST /v1/experiences — Register a new Experience. Validates schema, computes fingerprint (LAO-FP-v1), enforces publish prerequisites.

② Discovery

GET /v1/experiences — Discover Experience objects by domain, outcome, lifecycle, authorization, tags.

③ Retrieval

GET /v1/experiences/{id} — Retrieve a specific Experience with full canonical JSON, fingerprint, and verification attestations.

④ Lifecycle

PATCH /v1/experiences/{id} — Transition lifecycle: draft → published → retired. Enforces valid transitions.

⑤ Attestation

POST /v1/experiences/{id}/attestations — Submit verification attestation. Append-only.

⑥ Authorization

PATCH /v1/experiences/{id}/consumers — Update allowed consumers for shared Experiences.

Implementation status

TODAY — implemented and tested

SQLite database layer: db.py (702 lines)
FastAPI application: app.py (435 lines)
OpenAPI 3.0 specification: openapi.yaml (864 lines)
74/74 smoke tests passed
Python reference client (independent)
TypeScript reference client (independent)
29/29 cross-language interop tests passed
LAO-FP-v1 fingerprint: cross-language deterministic

NOT YET — Runtime integration

Runtime → Protocol adapter (NEXT — constraint injection proven 16/16)
Catalog HTTP client in Runtime (NEXT)
Catalog → Runtime reuse path (NEXT)
Runtime produces Protocol Experience objects
Runtime registers Experience in Catalog
Runtime retrieves Experience from Catalog

The Catalog is a working registry. The constraint injection path is proven (16/16 tests). The full Experience adapter is the next task.

Read the Protocol specification →

What this proves and what it does not

What this proves

The Protocol is implementable by independent parties
Cross-language fingerprint consistency is achievable
The Catalog can register, discover, retrieve, attest, and authorize Experience
The Frozen Specification is sufficient for third-party implementation

What this does NOT prove

That the Runtime currently produces Protocol Experience (it does not)
That Experience is stored in the Catalog from production (it is not)
That Agents retrieve and reuse Catalog Experience (they do not)
That this is a production marketplace (it is a reference implementation)

Claim-level status

Claim	Status
Catalog v0.1 implementation exists (6 endpoints)	TODAY
OpenAPI 3.0 specification generated	TODAY
74/74 smoke tests passed	TODAY
29/29 cross-language interop tests passed	TODAY
Runtime registers Experience in Catalog	NEXT — constraint injection proven 16/16; full adapter pending
Runtime retrieves and reuses Catalog Experience	NEXT — constraint injection proven 16/16; full adapter pending
Public Catalog browsing interface	NEXT

Why the Catalog matters for Agent reliability

The Catalog is where Experience becomes shareable. Without it, every Agent's Experience is trapped in its own session. With it, verified Experience can be discovered, retrieved, and reused — making Agents reliably better over time.

Protocol defines the rules → Catalog enforces the rules → Agents benefit from the rules

This is the technical registry. Want to see what it enables for Agent behavior?

Next: Reliable Agent — how Experience creates reliability →

← Protocol · Catalog (you are here) · Evidence → · Reliable Agent →