Codex 0 — The Master Blueprint of Anabasis

The complete institutional map. Everything Anabasis builds maps back to this document. It is descriptive of intent, not of current implementation: where the institution has not yet built something named here, the name is reserved and the seam is defined so it can be built later without redesign.

Derived from Codex 1 (Constitution). Elaborated by Codices 2–9.

1. The institution at a glance

Mission. Develop human capability so people, organizations, and societies become more capable of solving meaningful problems and creating lasting value, while making a measurable net positive difference in the world.

Form. One institution, five operating divisions, two offices, one shared operating system.

Test applied to everything (Codex 1, Article III): does it improve human capability; create measurable value; increase long-term trust; support institutional scalability; still make sense in twenty years; align with the Constitution.

                       STEWARDSHIP OFFICE
                  (custodian of the Codices, veto)
                                |
                        EXECUTIVE OFFICE
              (priorities, capital, people, targets)
                                |
   ACADEMY -- ADVISORY -- RESEARCH INSTITUTE -- VENTURES -- TECHNOLOGY
        \         |               |                |          /
         \--------+------- CapabilityOS -----------+---------/
                    engines + knowledge graph
                                |
              MEMBERS · ORGANIZATIONS · PARTNERS · PUBLIC

The institution's raw material is a Person. Its product is that person's demonstrated capability over a lifetime. Every division is a different way of increasing it; CapabilityOS is the single place it is recorded.

2. The five divisions and how they interact

Full definitions in Codex 2. The interactions are the part that matters architecturally.

Rule against duplication. Where two divisions need the same capability, it moves to Technology as a shared engine. No division builds a second version of another's system.

3. Executive Office and Stewardship Office

Executive Office runs the institution: sets priorities, allocates capital and people, owns targets, chooses among options doctrine permits. It cannot amend doctrine.

Stewardship Office guards the institution across generations: holds the Codices, records amendments, and reviews anything touching mission, member trust, data use, credential integrity, or reserves. Its instruments are a written veto and the amendment record — not day-to-day management.

Decision rights and the amendment procedure are in Codex 9.

4. Every user type

One canonical Person, many memberships, held simultaneously and across decades. Full table of what each type sees, owns, and must never see: Codex 4.

Member · Scholar (student) · Mentor · Faculty · Advisor · Coach · Researcher · Fellow · Editor · Founder · Investor · Enterprise client · Partner institution (university, government) · Employee · Division lead · Executive · Steward · Administrator · Public visitor.

Two rules govern all of them:

1. 1A person is never duplicated to give them a new role. Roles are scoped grants attached to the one person.
2. 2What a person may see is decided server-side from their roles and scope. UI concealment is not a permission.

5. CapabilityOS — the central operating system

Eleven bounded engines plus the knowledge graph, owned by Technology, consumed by every division, forked by none. Inputs, outputs, and rules: Codex 3.

Knowledge Graph · Learning · Adaptive · Goal · Habit · Decision · Financial · Business · Research · Advisory · Venture.

An engine declares its interface and never reaches into another engine's storage. A new engine is created only when no existing engine can absorb the responsibility.

6. Cross-division workflows

Each workflow is a sequence of stages; each stage names the data it emits, which is what makes the workflow implementable and auditable.

W1 — Enrolment to credential. Intake → capability baseline → recommended path → enrolment → lesson completion → assessment submission → review (peer, then faculty where weighted) → capability assessment recorded → credential issued → public verification record. Emits: Enrolment, Artifact, CapabilityAssessment, Credential, Event.

W2 — Credential to advisory engagement. Credential issued → advisor directory eligibility → engagement staffing → engagement delivery → outcome recorded → anonymized case contributed. Emits: Role grant, Engagement, Artifact, anonymized case.

W3 — Research to curriculum. Question → methodology registered → sources gathered → draft → editorial review → publication → graph linkage to capabilities → curriculum revision request → lesson authored. Emits: Publication, graph edges, Curriculum revision.

W4 — Founder intake to venture to capital. Application → capability and readiness assessment → program placement (incubator, accelerator, studio) → milestone cadence → investment readiness review → capital network introduction → investment → investor reporting → alumni membership. Emits: Venture, milestones, Investment, reports.

W5 — Enterprise client to cohort. Organization diagnostic → capability gap map → program design → cohort creation → delivery → aggregate capability reporting → renewal decision. Emits: Organization diagnostic, Cohort, aggregate report.

W6 — Alumni to mentor. Credential and tenure threshold → mentor eligibility → training → matching → mentoring relationship → mentor review. Emits: Role grant, mentoring records.

W7 — Annual accounting. Division outcomes → capability metrics → index values → financial results → annual report → Codices review → decision records. Emits: Index values, annual report, decision records.

Every workflow stage that changes a person's standing produces an audit record.

7. Shared data model

Canonical entities, ownership, normalization rules, and relationships: Codex 5.

Person · Identity · Organization · Membership · Role · Capability · CapabilityAssessment · Credential · Curriculum · Enrolment · Cohort · Engagement · Publication · Index · Venture · Investment · Artifact · Event · AuditRecord.

Standing rules: one canonical row per real-world thing; references, never copies; history is additive and versioned; anonymized research data is derived, never primary; every member-data table ships with explicit grants and row-level policy in the migration that creates it.

8. Permissions

Roles are rows in a dedicated table, scoped to individual, cohort, organization, division, or institution. Permissions derive from roles and are enforced at the data layer. New surfaces start closed. Elevated reads of member content are logged with a stated reason. Delegated access expires. Authority to define a credential standard is separated from authority to issue against it. Details: Codex 4.

9. Dashboards

Each dashboard is defined by the question it answers, never by its widgets, and is a view over engines rather than an owner of data: Personal, Scholar, Mentor, Advisor, Researcher, Founder, Investor, Enterprise, Steward, Administrator. Questions listed in Codex 3.

10. AI agents

Advisor · Tutor · Research Assistant · Reviewer · Analyst. Each with a declared scope, a permitted data set, a required human checkpoint, and an explainability obligation. No agent reads what its subject could not read. No agent acts on a consequential matter alone. No agent trains on member data without explicit, revocable, purpose-specific consent. Details: Codex 3.

11. API boundaries

Identity & Access · Person & Membership · Curriculum · Progress & Assessment · Credential & Verification · Engagement · Publication & Index · Venture & Capital · Knowledge Graph · Reporting & Analytics · Audit.

A boundary is stabilised before anything integrates against it. Credential verification is permanent and backwards-compatible — it must still resolve in twenty years. Breaking changes require a version, a migration window, and a decision record. Details: Codex 5.

12. Internal tooling

Tooling is built on the same APIs external surfaces use. No tool gets a privileged private path around doctrine.

13. Revenue

Streams by division, recurrence class, diversification and reserve rules: Codex 8. The standing constraints: favour recurring revenue, diversify across divisions, protect a named reserve floor, reinvest to mission capacity before expansion, and never monetize trust.

14. Reporting systems

• Annual report — plain, specific, honest about failures; capability outcomes reported alongside financial results.
• Capability metrics — demonstrated capability, not consumption. Never time-on-site.
• Indexes — versioned, methodology-published measurement series.
• Institutional trust metrics — commitments made and kept, credential integrity, data-use record, complaint resolution.
• Enterprise reporting — aggregate capability movement within agreed scope.
• Operational reporting — reliability, security posture, access review.

15. Expansion points

Named seams where the institution grows without redesign:

1. 1New division — the division registry and interface pattern accept a sixth without touching the other five.
2. 2Universities and governments — Organization plus Partner membership plus SSO identity, with agreed reporting scope.
3. 3Languages and regions — localization-ready content and layout; region-scoped organizations and data residency as a configuration, not a rewrite.
4. 4New engine — CapabilityOS engine interface pattern.
5. 5New credential class — Capability plus CapabilityAssessment plus Credential already generalise beyond course completion.
6. 6Third-party integration — only through published API boundaries, never direct database access.
7. 7New school or program — curriculum hierarchy is already n-deep and data-driven.
8. 8Public knowledge surfaces — publications, indexes, glossary, and a possible Codices reading surface, all generated from canonical sources.
9. 9Capital vehicles — Investment generalises to funds and syndicates.
10. 10Successor stewardship — the amendment record is the mechanism by which the institution outlives its founders.

16. How to use this Codex

Part I above is the narrative map. Part II — the Institutional Registry is the enumeration: every division, engine, API boundary, workflow, entity, agent, dashboard, internal tool, surface, and revenue stream, each with a permanent ID, an honest status, and the same eight answers.

Before proposing anything, find your registry entry — or create one — and answer all eight fields in writing:

1. 1What is it, in one sentence?
2. 2Why does it exist — which of the eight institutional strengths does it increase?
3. 3Who uses it — which user types and roles (Codex 4)?
4. 4How does it connect — which registry entries upstream and downstream, by ID?
5. 5Which Codex governs it?
6. 6Which single division owns it?
7. 7What data does it consume, and what does it produce (Codex 5 entities)?
8. 8What future systems will depend on it?

And two standing questions that gate the answer: does it duplicate anything that already exists, and what breaks if the institution is a hundred times larger?

A proposal that cannot answer these is not ready. Nothing enters src/ without a registry entry. If an answer conflicts with a Codex, name the conflict (Codex 9) rather than designing around it.