The Registry MVP: Open Data, A Single Operator, LLM Sessions First
An MVP of the registry this site designs: one public vault whose records are append-only, hash-chained, signed statement logs; a processor as the only write-key holder; and every workflow written for its actual first user — a fresh LLM session holding nothing but public URLs. Open data on principle (a registry contains no secrets), and public in data, private in authority: one operator, one root, own-agents enrolment — build-order step 4 with the covers off. Draft-1 shipped the morning of 20 August; three project-lead briefs landed the same day, and what they correct is recorded in the change-control appendix rather than silently patched — it sits last because it never stops growing, and it is the one document to read either second or last, never not at all. Two later documents draw the thing: the register interface, screen by screen, and six Wardley maps of where the novelty actually sits. Document 10 turns all of it into six users, twenty-four stories with tests that can fail, and six workflows; document 11 adds the half that makes the mandate layer defensible — and answers, by refusing it, the question of who is using a mandate. Document 12 gives the grant the structure C1 implied and never specified, and document 13 settles which things get keypairs — fewer than proposed. Document 14 is the first that describes something shipped: map your own case.
Every source document, every supporting brief, this site's machine-readable front door, and the reference implementation — with a briefing for a fresh session picking it up cold. It asks for a readiness report rather than an implementation plan: read the supporting material, then the pack, then say whether you have what you need or list the questions that block you. It names the six things that trip a new reader, and asks for blocking questions rather than confidence, because a pack with a third of its decisions still open is one where a confident plan probably means the reader missed them.
The documents
| Document | Role |
|---|---|
| 00 — The leading brief | Scope, the four objects, and the reconciliation: public in data, private in authority |
| 01 — Architecture | The vault, the records as hash-chained statement logs, the processor as referee |
| 02 — Schemas | Identity, mandate, grant, acceptance, revocation — and where a mandate lives |
| 03 — Workflows | Verify, enrol, operate-under-mandate — copy-paste form for a fresh LLM session |
| 04 — Build order | Read path before write path; five phases; every definition of done is a fresh-session test |
| 05 — Diagrams | The design as pictures: the estate, the record, the write path, the walk, the demo, the gap |
| 07 — Tabletop exercise | Four participants, six injects, and the four rules meeting their first population |
| 08 — UX mockups | The register interface as intended output, screen by screen, with “nobody” as a first-class answer |
| 09 — Wardley maps | Six maps: where the novelty actually sits, and why a policy is worth what its weakest badge is worth |
| 10 — User stories, features and workflows | Who gets what, and how we know it works — six users, twenty-four stories, fourteen features, six workflows |
| 11 — Observability | Nobody can tell you who is using a mandate — the issuer's lane can tell you who has never checked one |
| 12 — The grant tree and control labels | Blast radius is a path through a tree, and the label on each node is the column nobody publishes |
| 13 — Keys and signatures | A key belongs to whatever can keep a secret — everything else is signed by something that can |
| 14 — The user assessment | The one document here describing something built — and a conformance test for the site's own claim |
| Appendix A — The PR/FAQ | The pack written backwards from a customer — and the customer-quote slot we could not fill |
| Appendix B — REP-0001: The registry core | The normative specification, in PEP form — with MUST, MUST NOT, and the sections PEP 1 makes mandatory |
| 15 — The screens, rendered | Document 08's twelve screens built by an outside session — and the six things the fixed-width form was hiding |
| Appendix C — Doctrine | Wardley's forty doctrines, and an honest self-assessment of this project against every one |
| Appendix D — Change control | Every correction and every decision in one place — the errata, and the register of what is settled and what is not |
Why it is on this site
This pack is build-order step 4 made concrete. Its constraints are this site's published pages: the four rules (implemented as processor checks plus a public validator), identity vs. mandate (with the mandate living in the issuer's record — the same rule the v0.33.61 register brief derives independently), the bootstrap trap (the enrolment workflow walks the gradient as commands), and the shipped surface (the lane, the four capability tiers, and the two absences the registry supplies).