Codex 0 — The Master Blueprint of Anabasis

The complete institutional specification. Every other Codex plugs into this book rather than redefining it.

0.1 Authority

1. 1Codex 0 derives from Codex 1 (the Constitution) and is subordinate to it in every conflict.
2. 2Codex 0 outranks Codices 2–11. Where a domain Codex and Codex 0 disagree on specification, Codex 0 governs. Where they disagree on a rule of principle, the domain Codex is amended or Codex 0 is corrected by decision record — never resolved in code.
3. 3Codices 2–11 hold rules; Codex 0 holds the architecture those rules apply to. A domain Codex should cite a Codex 0 clause rather than restate it.
4. 4Nothing in src/ may contradict a clause of this book. Where it does, the code is the defect.

0.2 How to cite this book

Every normative statement is a numbered clause. Citations take the form:

Codex 0 §07.4.2          chapter 07, section 4, clause 2
Codex 0 §11.6            chapter 11, section 6 (whole section)
Registry ENG-03          a registry entry, Appendix 99

Clause numbers and registry IDs are permanent. A section may be retitled and a clause may be superseded, but numbers are never reused and never renumbered. A superseded clause is struck in place with a pointer to the decision record that replaced it, so a citation written today still resolves in twenty years.

0.3 Reading order

A first-time contributor reads 01, 02, 04, then the chapter covering their work, then the Registry entry for the thing they are about to touch.

Before designing a surface, dashboard, flow, or form, use the companion instruments in ../CODEX-6/: RUBRIC.md (the eight-dimension Institutional UX score), TEMPLATE-page.md, TEMPLATE-interaction.md, and TEMPLATE-review.md. Chapters 11 and 12 specify what a surface is; the rubric decides whether a given one may ship.

0.4 Chapter form

Every chapter is written in the same shape, so the book is navigable and additive rather than narrative:

Purpose               why the chapter exists
Scope and non-scope   what it governs, and what it explicitly does not
Specification         numbered sections of numbered clauses
Interfaces            the registry IDs it touches
Invariants            what must always hold, at any scale, in any era
Prohibitions          what is permanently forbidden here
Open questions        what is genuinely undecided
Governing Codices     which Codices bind this chapter

The Open questions section is not decoration. A specification that conceals its unknowns is fiction. Unknowns are named there and closed only by a decision record in ../DECISIONS/.

0.5 Status honesty

Most of what this book specifies is not built. Every registry entry carries built, partial, or reserved, and chapters mark status where they specify a system. This book describes the institution's architecture, not its inventory; it must never be read, quoted, or shown to a client as a description of delivered capability.

0.6 How to extend this book

1. 1A new system, surface, engine, boundary, agent, dashboard, tool, or revenue stream requires a Registry entry with all eight fields answered (Appendix 99) before any implementation.
2. 2A change to specification requires a decision record naming the clauses it amends, the Codex 10 Institutional Critic examination, and the Codex 8 seven-axis evaluation.
3. 3A new chapter is added only when no existing chapter can absorb the subject — the same rule the engine model applies to engines (§05.2).
4. 4Amendments touching mission, member trust, data use, credential integrity, or reserves require the Stewardship Office's assent (Codex 9).
5. 5When work ships, the author moves the Registry status and names what remains. An untouched status after shipped work is a defect.

0.7 Change log

0.8 Governing Codices

Codex 1 (supreme), Codices 2–11 as cited per chapter, Codex 9 for amendment, Codex 10 for review of anything major.