0003 — The Institutional Registry becomes the mandatory pre-implementation artefact
A recorded institutional decision, with reasoning and result.
- Authority rank
- 5
- Version
- v1.0
- Adopted
- unrecorded
- Held by
- Stewardship Office
- System
- SYS-10
Source · docs/codices/DECISIONS/0003-codex-0-registry.md · registered by rule
Date: 2026-07-31 Status: Accepted Amends: Codex 0 (adds Part II, rewrites §16), Codex 9 (procedure), README, AGENTS.md
Decision
Codex 0 gains Part II, CODEX-0-REGISTRY.md: an enumeration of every division, CapabilityOS engine, API boundary, cross-division workflow, canonical entity, AI agent, dashboard, internal tool, surface, and revenue stream. Each entry carries a permanent ID, an honest status (built / partial / reserved), and the same eight answers: what it is, why it exists, who uses it, how it connects, which Codex governs it, which single division owns it, what data it consumes and produces, and what future systems will depend on it.
Nothing enters src/ without a registry entry. An entry with an unanswered field is not ready to build.
Why
Part I of Codex 0 described the institution as a narrative map. It could not answer the eight questions for any individual thing: a reader could learn that the Academy owns the Curriculum boundary, but not look up a route or an engine and read its owner, users, data, governing Codex, and dependents in one place. The registry is what turns doctrine into a map contributors can locate their work on, and it is what separates building an institution from shipping a product.
Registering existing surfaces also produced the institution's first honest audit: most of Anabasis is reserved, several built surfaces (annual report, ecosystem, institutions, research) are editorial with no data behind them yet, and only identity and lesson progress exist as real member data.
Codex 8 evaluation
| Axis | Assessment |
|---|---|
| Revenue potential | None directly; it gates and sequences every revenue stream (REV-01..06). |
| Implementation cost | Low — markdown only, no build or runtime surface. |
| Maintenance cost | Low but perpetual: status fields and new entries must be kept current or the registry becomes fiction. |
| Operational complexity | None technically; one added step before any proposal. |
| Customer value | Indirect: fewer duplicated systems and fewer abandoned surfaces. |
| Enterprise value | High — an enterprise buyer can be shown what exists, who owns it, and what data it touches. |
| Long-term strategic value | Highest of the doctrine work so far: it is the mechanism by which contributors decades from now understand where their work fits. |
Codex 10 — Institutional Critic
- 1At a hundred times the scale? A single markdown table set stops scaling somewhere past a few hundred entries. The ID scheme is the mitigation: entries can be split into per-class files, or later generated from a structured source, without renumbering.
- 2Unverified assumptions? That contributors will keep status fields honest. Unverified. Mitigated only by making status part of the shipping step, in
AGENTS.md. - 3Simpler solution? Yes — keep the narrative map and require the eight answers ad hoc per proposal. Rejected: unrecorded answers cannot prevent duplication, which is the specific failure the registry exists to stop.
- 4Duplication? It overlaps Codices 2, 3, 5, and 8 by design. Those remain the rule-giving texts; the registry is the index and holds no rules of its own beyond the six registry rules.
- 5Enterprise view? Favourable — declared ownership, data lineage, and honest status are what diligence asks for.
- 6First-time contributor? Better: one file answers "where does my work fit" instead of ten Codices.
- 7Legal, operational, security? Positive on all three: data-per-entry is the beginning of a data map; audit and access entries are named rather than implied. The registry is internal doctrine and must not be quoted as a compliance or certification claim.
- 8Technical debt? The registry duplicates facts that live in code (routes, curriculum data). Drift is the debt. Repaid by, at minimum, reviewing
SURF-entries whenever routes change, and eventually by generating that class from the route tree. - 9Consistency? Consistent with Codex 1 Article III, Codex 0 §16, Codex 5's one-canonical-definition rule, and Codex 9's conflict procedure.
No question failed. Accepted without exception.
Consequences
docs/codices/CODEX-0-REGISTRY.mdcreated; Codex 0 §16 rewritten to require a registry entry.docs/codices/README.mdandAGENTS.mdupdated to bind future work to it.- Project memory records the registry so every future session inherits the requirement.
- No changes under
src/. The site is unaffected.