The registry that was built, and then retired
The four rules read like a design derived from somebody else's failure. They are also derived from our own build. In February 2026 this project shipped a key registry; in June it formally superseded it. That history is what turns two of the four rules from assertions into checked claims — which is the standard the rules page sets for itself.
The registry is not an idea this project is reaching for. It is one this project built, ran, and decided was not enough.
What was built
In a six-day burst between 20 and 22 February 2026 — 29 commits, 183 tests — the project shipped a working key registry behind admin authentication:
| Capability | How it worked | Which rule it exercises |
|---|---|---|
| Publish a key | Validated public-key material and bound it to a SHA-256 fingerprint | Rule 4 — every entry signed by something checkable |
| Duplicate rejection | A publish naming an already-registered fingerprint was refused outright | Rule 1 — one record, one owner |
| Lookup by short code | Human-exchangeable base-36 codes rather than raw fingerprints | The usability half of a directory |
| Unpublish | Soft delete — the record was marked, not destroyed | Rule 2 — supersede rather than delete, reached independently |
| Transparency log | A genuinely hash-chained append-only log: each entry's hash covers the previous one | The MVP's own record chain, prefigured |
What it could not carry, and the retirement
In June 2026 the project published a vault-hosted registry design that explicitly replaces it — the corpus's reality tree records the shipped service, in its own words, as being superseded by that proposal. This was a design decision, not neglect. What the February service could not carry:
| Limit | What the replacement proposes |
|---|---|
| It was a store, not a graph. Entries were keys; there was nowhere to put the relationships between them | Clues rather than storage — an entry is a node, and the edges are the value |
| Trust was flat. A key was present or absent; there was no way to say who vouched for whom, or to distinguish a claim from an endorsement | Two-level trust: downward asserted by the truster, upward self-declared and granting nothing |
| It was one server. No federation, no mirroring, no way for one registry to recognise another | A vault, mirrorable by anybody, with registries recognising registries |
| Resolution was a lookup. One code in, one key out | Resolution as the caller's job — walk the graph, handle cycles, and return a partial result honestly |
That last row is the one most worth keeping. A partial resolution is a legitimate output: I followed the chain this far, gained this much trust, and stopped because I lack the keys to continue. A registry that can only answer yes or no is hiding the interesting half of the question.
The design lesson the MVP inherits
One property of the February build carries a warning forward rather than a reassurance. The transparency log was hash-chained, which makes it tamper-evident to anyone reading the whole chain — and that is genuinely useful. But a hash chain by itself has a known limit:
A hash chain proves that a reader's own view is internally consistent. It cannot, on its own, prove that every reader was shown the same view.
Showing different readers different consistent chains is equivocation, and detecting it needs something outside the chain — a second party who has seen the log and will say what they saw. The MVP's record design is a hash chain too, so it inherits exactly this limit, and its tabletop exercise is where that gets tested rather than assumed. Publishing the limit alongside the design is the point of publishing the design early.
Why this page exists
Because "we should build a key registry" and "we built a key registry, ran it, and replaced it for these four reasons" are very different claims, and only the second is checkable. It also gives the registry a concrete user — somebody already running the shipped commands who has hit exactly the two walls the site names — instead of a hypothetical one.