Codex 0, Part II — The Institutional Registry

The registry is the table of contents of Anabasis. Part I of Codex 0 is the narrative map; this is the enumeration. Every division, engine, API boundary, workflow, entity, agent, dashboard, internal tool, public surface, and revenue stream has exactly one entry here, and every entry answers the same eight questions.

Nothing enters src/ without an entry. An entry with an unanswered field is not ready to build.

The eight-question record

ID · Name
1 What it is            one sentence
2 Why it exists         the institutional strength it increases
3 Who uses it           user types and roles (Codex 4 names)
4 How it connects       upstream and downstream entries, by ID
5 Governing Codex       the Codex whose rules bind it
6 Owning division       exactly one
7 Data                  entities consumed / produced (Codex 5 names)
8 Future dependents     what is planned to be built on top of it

Every entry also carries a status:

Most of the institution is reserved. That is the honest state and the registry says so rather than describing intent as if it were a system.

Rules of the registry

1. 1IDs are permanent. A thing may be renamed; its ID never changes, so references in decision records still resolve in twenty years.
2. 2One owner. Exactly one division owns each entry. Shared need is resolved by moving the capability to Technology (DIV-05), never by a second implementation.
3. 3Connections are by ID. Prose references are not connections. If two entries interact and neither names the other, the registry is wrong.
4. 4No orphan surfaces. A surface that names no data and no engine is either editorial by nature (and says so) or a gap to be closed.
5. 5Status moves upward only through work, never through optimism.

1. 1Every entry names one system. In addition to its owning division, every entry belongs to exactly one of the twelve institutional systems (§0, SYS-). Systems own capability; divisions own outcomes. An entry that fits no system is misplaced and is redesigned rather than filed under the nearest one.
2. 2Every entry may carry a lifecycle stage (Codex 0 §21): the fourteen stages from Discover to Retire or Supersede. reserved covers Discover through Validate, partial covers Build through Improve, built requires Standardize, Teach, and Preserve to have been reached. A thing is not built merely because it runs.

0. Institutional systems — `SYS-`

Governing Codices: 11 and Codex 0 Chapter 20 · The twelve are permanent and closed: a thirteenth requires an amendment to Codex 11, not a decision record. No system is owned by a division; each is owned by the institution and stewarded by the division named below.

Chapter 20 assigns every ENG-, API-, WF-, ENT-, AGT-, DASH-, TOOL-, and SURF- entry to exactly one system, states what each system must never absorb, and fixes the boundary tests between adjacent systems. Where this table and Chapter 20 disagree on an assignment, the chapter governs.

1. Divisions and offices — `DIV-`

Governing Codex: 2 · Data: all entities within their own boundary · Users: all types.

2. CapabilityOS engines — `ENG-`

Owner: DIV-05 Technology (consumed by all, forked by none) · Governing Codex: 3.

3. API boundaries — `API-`

Governing Codex: 5. A boundary is stabilised before anything integrates against it.

Contract rules that bind all of the above: credential verification is permanent and backwards-compatible; internal contracts are typed and validated at the edge; breaking changes require a version, a migration window, and a decision record.

4. Cross-division workflows — `WF-`

Governing Codex: 0 §6 (stages) and 5 (emitted data). Every stage that changes a person's standing emits ENT-19.

5. Canonical entities — `ENT-`

Governing Codex: 5. Every member-data table ships with explicit grants and row-level policy in the migration that creates it. None of the reserved entities exist as tables yet; profiles and lesson progress are the only implemented member data.

6. AI agents — `AGT-`

Owner: DIV-05 · Governing Codex: 3 and 1 (Article on AI). No agent reads what its subject could not read; none acts alone on a consequential matter; none trains on member data without explicit, revocable, purpose-specific consent.

Administrative assistance is a capability of AGT-01 and TOOL- surfaces rather than a separate agent; a distinct administrative agent is not reserved, to keep the count of things with access to operational data as small as possible. AGT-06 through AGT-14 are reserved IDs only: none is specified beyond this row, and each requires a full Chapter 13 specification (scope, permitted data, checkpoint, refusal behaviour, evaluation, prohibitions) before any implementation.

7. Dashboards — `DASH-`

Governing Codex: 3 and 6. A dashboard is defined by the question it answers and is a view over engines; it owns no data.

8. Internal tooling — `TOOL-`

Governing Codex: 7. Tooling is built on the same APIs external surfaces use; no privileged private path around doctrine.

9. Surfaces — `SURF-`

Every route that exists today, registered. Governing Codex for all: 6 (experience) plus the domain Codex named. "Public" means no authentication.

9.1 Institutional surfaces

9.2 Academy surfaces

Owner: DIV-01 · governed by Codices 6 and 3 · data: ENT-09 curriculum, ENT-10 enrolment, ENT-07 assessment.

9.3 Member surfaces (authenticated)

Owner: DIV-01 · governed by Codices 4 and 6 · access decided server-side from ENT-05, never by UI concealment.

9.4 Reserved surfaces

Named so they are not invented twice: advisor workspace, enterprise console, founder portal, investor portal, researcher workspace, steward and executive reporting, administrator access console, public credential verification, and a Codices reading surface. Each will take a SURF- ID when proposed, with all eight fields answered.

10. Revenue streams — `REV-`

Governing Codex: 8. Governing system: SYS-05 (Finance). Standing constraints: favour recurring revenue, diversify across engines, meet operating expenses and the reserve floor before any discretionary allocation, follow the Codex 8 Article V allocation path, never monetize trust.

Recognition basis for each stream is fixed by class in STD-F §3.3 and stated in the stream's entry before first invoice. No stream may be introduced without a Codex 8 seven-axis evaluation and a Codex 10 review recorded in DECISIONS/.

10a. Financial and governance instruments — `FIN-` and `GOV-`

Governing Codices: 8 (financial) and 9 (governance). Nothing here is a product surface; each is an institutional instrument with named custody, named decision rights, and a reporting obligation.

No FIN- or GOV- entry moves past reserved without the eight fields answered, a Codex 10 critique, and, where it touches money, the STD-F §5 checklist.

11. Using the registry

Before proposing anything:

1. 1Find the entry. If none exists, create one and fill all eight fields.
2. 2If the work spans entries, name every ID it touches.
3. 3If it duplicates an existing entry, stop — extend the existing one or move it to DIV-05.
4. 4If the fields cannot be answered, the proposal is not ready.
5. 5If an answer contradicts a Codex, name the conflict (Codex 9); do not design around it.
6. 6When work ships, move the status and say what remains.