Codex 0 · Chapter 01 — The Institution

Specifies what Anabasis is, what it exists to do, how its purpose is tested, and the model that all later chapters elaborate.

01.0 Purpose

To fix the institution's definition so that every subordinate specification has a stable referent. Chapters 02–19 describe parts; this chapter describes the whole those parts belong to.

01.1 Scope and non-scope

In scope. The nature of the institution, its mission, the tests applied to all work, the institutional strengths, the whole-institution model, the unit of value, the horizon, and the doctrine of continuity.

Not in scope. Division mandates (Chapter 02), governance mechanics (Chapter 03), user types (Chapter 04), and anything technical.

01.2 Nature

01.2.1 Definition

Anabasis is an institution: a body constituted to pursue a purpose beyond the working life of any person in it. It is not a company that happens to sell education, not a platform, and not a product portfolio. Its legal and commercial forms are instruments; the institution is the thing they serve.

01.2.2 Composition

One institution, five operating divisions, two offices, one shared operating system:

                       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

01.2.3 One body, not a federation

The divisions are functions of one institution, not affiliated entities. They share one Person record (§07), one permission model (§08), one operating system (§05), and one doctrine. A division may not fork a shared capability, hold a private data model, or issue commitments in the institution's name outside its mandate.

01.2.4 Continuity over ownership

Stewardship, not ownership, is the organising relationship. Every holder of authority holds it in trust and hands it on. The mechanism by which the institution outlives its founders is the written amendment record (Chapter 03, Codex 9) — not the presence of any individual.

01.3 Mission

01.3.1 Statement

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.

01.3.2 Subordination of finance

Financial success sustains and expands the mission. It never replaces it. A financially attractive activity that does not develop capability is outside the mission regardless of margin (Chapter 15).

01.3.3 The unit of value

The institution's raw material is a Person. Its product is that person's demonstrated capability over a lifetime. Every division is a different means of increasing it; CapabilityOS is the single place it is recorded (§05, §07).

Consequences that bind the whole architecture:

1. 1Capability is measured by demonstration, never by consumption (§16).
2. 2A person is never duplicated to give them a new relationship (§07.2, §08.3).
3. 3Records of demonstrated capability outlive the surfaces that produced them (§10, §18).

01.4 The tests

01.4.1 The Six Questions (Codex 1, Article III)

Before any feature, page, workflow, schema change, or integration is proposed it must satisfy all six:

1. 1Does it improve human capability?
2. 2Does it create measurable value for people?
3. 3Does it increase long-term trust?
4. 4Does it support institutional scalability?
5. 5Would it still make sense twenty years from now?
6. 6Does it align with the Constitution?

A "no" requires redesign before proposal, never a caveat after it.

01.4.2 The Institutional Test (Codex 1, Article IV)

Every feature must strengthen at least one of: people, knowledge, trust, technology, research, education, capital, community. A feature that strengthens none does not belong, however well built.

01.4.3 The Registry Test

No system, surface, engine, agent, dashboard, tool, or revenue stream enters src/ without a Registry entry whose eight fields are answered (Appendix 99). An unanswered field means the proposal is not ready.

01.4.4 The Critic

Anything major — a new surface, a schema change, a revenue stream, a doctrine exception — is examined in writing against Codex 10's nine questions and Codex 8's seven axes before acceptance. A failed question means redesign, not a caveat.

01.4.5 The Experience Test

Every interaction answers: did this make the person's life better? If the honest answer is "it increased engagement", the interaction fails and is removed (Codex 6, Chapter 11).

01.4.6 Order of application

Tests are applied in order 01.4.1 → 01.4.2 → 01.4.3 → 01.4.4 → 01.4.5. Failure at any stage stops the proposal there; later tests are not a route to rehabilitate an earlier failure.

01.5 The eight institutional strengths

Strengths compound: research feeds education, education feeds advisory and ventures, ventures and advisory feed research, and technology carries all of it. Chapter 02 specifies those flows; Chapter 09 specifies them as workflows.

01.6 The member

01.6.1 Standing

The member is not the product; the member is the reason the institution exists. Optimization targets are learning, competence, trust, and long-term outcomes.

01.6.2 What the member is owed

1. 1A true account of what the institution holds about them, and control over it (§07.9, §11).
2. 2Assessment that means what it says, never softened to improve completion figures.
3. 3Explanations for any automated judgement that affects them (§13).
4. 4Exit without penalty: cancellation and export are as easy as joining (§15).
5. 5Accessibility as a functional requirement, not an enhancement.

01.6.3 What the member is never subjected to

Dark patterns, manufactured urgency, manipulative gamification, sale or brokerage of their data, unexplained automated decisions, or consent bundled into unrelated actions.

01.7 Horizon

01.7.1 The hundred-year design rule

Where a short-term implementation would create long-term architectural, financial, or organizational debt, the long-term design is chosen and the shortfall documented rather than hidden.

01.7.2 What must never require redesign

The canonical Person; the separation of roles from profiles; permanent credential verification; the API boundary set; Registry IDs; clause numbers. Chapter 18 specifies these as invariants under scale.

01.7.3 Named debt

Debt is permitted only when named: what was traded, why, and what would repay it. Unnamed debt is a defect (§17).

01.8 Interfaces

DIV-01..DIV-07 (Chapter 02, 03) · ENG-01..ENG-11 (Chapter 05) · ENT-01 Person (Chapter 07) · every test in §01.4 is enforced at proposal time by the Registry (Appendix 99).

01.9 Invariants

1. 1One institution, one Person record, one operating system, one doctrine.
2. 2Mission outranks revenue in every conflict.
3. 3Capability is demonstrated, not consumed.
4. 4Authority is held in trust and handed on in writing.
5. 5No test in §01.4 may be waived by urgency, deadline, or commercial opportunity.

01.10 Prohibitions

1. 1Describing Anabasis as a startup, platform, app, or product in institutional surfaces or internal doctrine.
2. 2Optimising any surface for time-on-site, streaks, or attention capture.
3. 3Selling, renting, or brokering member data, in any form, ever.
4. 4Making claims of certification, compliance, or audit outcome without documented evidence and approved wording.
5. 5Treating this book as a description of built capability (§00.5).

01.11 Open questions

1. 1Legal form. The institution's eventual legal structure — including whether stewardship is vested in a foundation or trust — is undecided and material to §01.2.4.
2. 2Measurement of net positive difference. §01.3.1 claims a measurable net positive difference; the methodology that substantiates it is not yet specified (Chapter 16).
3. 3Membership classes. Whether membership has classes beyond role scoping, and what they entitle, is open (Chapter 04, Chapter 15).

01.12 Governing Codices

Codex 1 (Articles I–VIII), Codex 2, Codex 6 §Institutional UX, Codex 8, Codex 9, Codex 10.