Codex 0 · Chapter 18 — Scale and Expansion

This chapter specifies what must change, and what must never change, as Anabasis grows from its current size to ten, a hundred, and a thousand times its current size.

18.0 Purpose

18.0.1 Codex 1, Article VII commits Anabasis to a hundred-year horizon. A design that works at current scale but silently fails at ten times that scale is a short-term implementation that trades long-term architecture for present convenience, which Article VII forbids without documentation. This chapter names the thresholds in advance so the tradeoff is never silent.

18.0.2 This chapter also names the ten expansion seams of Codex 0 §15 in enforceable detail: what attaches to each, what must already be stable before it can, what data it introduces, and what breaks if it is bolted on without preparation.

18.0.3 This chapter does not invent new systems. Every capacity change it specifies is a change to something already named in Codex 0 or the Registry — a threshold at which a reserved or partial entry must be built with a specific property, or an existing built entry must be re-architected without changing its contract.

18.1 Scope and non-scope

18.1.1 In scope: the effect of 10x, 100x, and 1000x growth in people, curriculum, assessment and review load, credential verification traffic, the knowledge graph, reporting, storage and retention, support and operations, and organizational structure; explicit thresholds; what must never be redesigned; and the ten expansion seams of Codex 0 §15.

18.1.2 Out of scope: financial projections and capital planning for growth (Codex 8); the amendment procedure by which a threshold rule is changed (Codex 9); the specific vendor or infrastructure chosen to meet a threshold, which is an engineering decision made under Chapter 17 at the time it is needed.

18.1.3 A multiplier in this chapter (10x, 100x, 1000x) is relative to the institution's size at the time a registry entry moves to built, not to any fixed absolute number; each entry's baseline is recorded when it is first built.

18.2 What never changes

18.2.1 Canonical Person. One row per real human being, held for life, never duplicated to add a role (Codex 0 §4). No scale multiplier changes this; the alternative — a Person record per context — breaks credential verification, audit history, and the constitutional guarantee that a person is not fragmented across the institution's systems.

18.2.2 Permanent credential verification. A credential issued today must still resolve at any future scale (Codex 0 §11; API-05). The verification contract's shape may gain fields; it never removes the ability to answer the question it answered on day one.

18.2.3 Registry IDs. An ID (DIV-, ENG-, API-, WF-, ENT-, AGT-, DASH-, TOOL-, SURF-, REV-) is permanent once assigned (Codex 0-REGISTRY, rule 1). Growth changes an entry's internal implementation and status, never its ID.

18.2.4 Clause numbers. A clause number in this book, once published, is never reassigned to a different statement. Amendment adds, deprecates, or supersedes a clause; it does not renumber to make room.

18.2.5 The API boundary set. The eleven boundaries of Codex 0 §11 are the fixed set of doors into the institution's data. Scale is met by making an existing boundary handle more traffic, more callers, or more versions — never by opening a new, unnamed path around it. A genuinely new boundary is proposed, numbered, and stabilised through Codex 0-REGISTRY before anything integrates against it; it does not appear as a shortcut inside an existing one.

18.2.6 What does not appear in 18.2 is a candidate for redesign at scale by default, subject to the thresholds in §18.3–§18.10.

18.3 People and identity

18.3.1 At current scale, identity and membership (ENT-01 through ENT-05) are read and written without needing to consider contention or lookup cost.

18.3.2 10x. Role lookups on every authorization check (Codex 1, Article VI.5) must be indexed and cached; an unindexed per-request role scan becomes a measurable latency cost at this size and is a defect from this point forward.

18.3.3 100x. Identity federation with partner institutions (Codex 0 §15.2) becomes load-bearing rather than occasional: single sign-on from universities and governments must handle simultaneous bulk provisioning (an entire cohort or organization onboarded at once), not one person at a time.

18.3.4 1000x. Membership queries ("everyone who holds role X in division Y") must be served from denormalized read models rather than computed live from the canonical role table on every request; the canonical table remains the single source of truth (§18.2.1, Codex 5) and the read model is rebuilt from it, never edited independently.

18.3.5 What never changes across all three thresholds: one canonical Person per human being (§18.2.1); roles as scoped grants, never duplicated identities (Codex 0 §4).

18.4 Curriculum volume

18.4.1 The curriculum hierarchy (school → program → course → module → lesson) is already n-deep and data-driven (Codex 0 §15.7), which is what makes this dimension tolerant of growth without a schema change.

18.4.2 10x more curriculum content requires the authoring tool (TOOL-01) to support versioning and review workflows at the module level, not only the course level, so ten times the content does not mean ten times the review bottleneck per change.

18.4.3 100x requires curriculum search and the adaptive engine (ENG-03) to operate over an indexed representation of the knowledge graph (ENG-01) rather than a full scan; browsing an unindexed catalogue of that size is not a usable interface, which is an experience failure under Codex 6 as much as a performance one.

18.4.4 1000x requires curriculum to be partitionable by school or partner organization for authoring and delivery purposes, so that one partner's authoring load does not contend with another's, while the canonical curriculum entity (ENT-09) and its verification remain unified.

18.4.5 What never changes: the curriculum hierarchy's shape and the rule that curriculum is data, not hardcoded page content, once TOOL-01 is built.

18.5 Assessment and human review load

18.5.1 Assessment and review (WF-01, TOOL-02, AGT-04) is the dimension most constrained by the Constitution rather than by engineering: assessment is never softened to improve completion figures (Codex 1, Article VI.7), and AI advises while people decide (Article VI.3).

18.5.2 10x submission volume requires peer review capacity to scale with enrolment, which is a division-level staffing and incentive design question (Codex 2), not something engineering alone can absorb; the review console must make reviewer load and backlog visible (DASH-03, TOOL-02) so the tradeoff is seen, not hidden.

18.5.3 100x requires the first-pass reviewer agent (AGT-04) to be load-bearing for triage — surfacing likely issues before a human reviewer sees a submission — while the human checkpoint before any weighted result remains mandatory (Codex 0 §10; Codex 0-REGISTRY §6). The agent's role is explicitly bounded to triage; it does not become the reviewer of record at any scale.

18.5.4 1000x requires a queueing and prioritization discipline for review (oldest-first is not sufficient at this volume; risk of credential-integrity harm from delay must be weighted), and requires faculty capacity itself to be modeled as a constrained resource in workforce planning (Codex 2), not assumed elastic.

18.5.5 What never changes: a human signs any weighted assessment result (Codex 0-REGISTRY, AGT-04); assessment rigor is never reduced to clear a backlog.

18.6 Credential verification traffic

18.6.1 Public credential verification (API-05) is, by its nature, a surface an external party (an employer, another institution) can call at any time, for any credential ever issued, including ones issued decades earlier (§18.2.2).

18.6.2 10x verification traffic requires the verification response to be served from a cache or read replica rather than the primary write path, so a spike in external checks never contends with credential issuance itself.

18.6.3 100x requires rate limiting and abuse detection on the public verification route (Chapter 17, §17.5.3) distinct from the authenticated application's rate limits, because this route is, by design, callable without an Anabasis account.

18.6.4 1000x requires the verification contract to be served independently of the rest of the platform's availability — verification uptime must not be coupled to the uptime of unrelated engines — because at this scale verification is effectively public infrastructure that outside parties depend on operationally.

18.6.5 What never changes: the verification contract's backward compatibility (§18.2.2); a credential's meaning is never revised retroactively to make a past assessment appear stricter or looser than it was.

18.7 The knowledge graph

18.7.1 The knowledge graph (ENG-01) links capabilities, curriculum, publications, and demonstrated ability (Codex 0 §5). Its cost grows superlinearly with the number of entities and edges it holds, not linearly with the number of people.

18.7.2 10x the number of capabilities and curriculum units requires graph queries used by the adaptive engine (ENG-03) to be pre-computed or cached along the paths actually walked at recommendation time, rather than traversed fresh per request.

18.7.3 100x requires the graph to be partitioned or sharded by domain (a school, a division) for write purposes while remaining queryable as a single graph for cross-division linkage (Codex 0 §2's cross-division data flows), because at this size no single write path can serialize all updates.

18.7.4 1000x requires graph edges to carry provenance and confidence metadata as first-class fields, not an afterthought, because at this size the graph will contain edges asserted by multiple engines and agents (AGT-02, AGT-03) and a person's trust in a recommendation depends on knowing where an edge came from.

18.7.5 What never changes: the graph is the single place demonstrated capability is recorded (Codex 0 §5, §1); no division forks a private copy of it.

18.8 Reporting

18.8.1 Reporting (API-10, the annual report, indexes, DASH-08/09) aggregates across the whole institution and is read by the smallest, most senior audience (executives, stewards, partners), which inverts the usual scaling pressure: correctness and auditability matter more than raw throughput.

18.8.2 10x the volume of underlying data requires reporting queries to run against precomputed aggregates refreshed on a stated cadence (Chapter 17, §17.11.3), not live joins across every canonical table at request time.

18.8.3 100x requires versioned index methodology (Codex 0 §14) to be enforced by tooling, not convention, because at this size a silent change to how an index is computed is indistinguishable, from outside, from a real change in the underlying trend — which would violate the Constitution's prohibition on softening or manipulating measurement.

18.8.4 1000x requires enterprise and partner reporting (Codex 0 §14) to be computed within agreed scope automatically, with the scope boundary enforced at the data layer (Chapter 17, §17.6), because manually curating every partner's report at this volume is not sustainable and manual curation is also where scope leaks happen.

18.8.5 What never changes: capability metrics are demonstrated capability, never consumption or time-on-site (Codex 0 §14; Codex 1, Article V); indexes are versioned and their methodology is published.

18.9 Storage and retention

18.9.1 Audit records (ENT-19), enrolment history, and credential records are additive and kept for the life of the institution (Codex 1, Article VII); they are the dimension of storage that never shrinks.

18.9.2 10x requires a stated retention and archival policy for lower-value operational data (raw structured logs, transient session state) distinct from the permanent record classes above, so storage growth is deliberate rather than incidental.

18.9.3 100x requires cold storage or archival tiers for historical data that is rarely queried (a member's activity from a decade prior) while remaining retrievable, because keeping everything in the hot path at this size is a cost and performance problem, not a correctness one.

18.9.4 1000x requires a data residency and regional storage strategy (Codex 0 §15.3) to move from a configuration flag on a small number of Organizations to a first-class dimension of storage architecture, because regulatory obligations at this scale will span multiple jurisdictions concurrently.

18.9.5 What never changes: history is additive and versioned (Codex 0 §7); nothing that constitutes a person's credential, audit, or assessment record is ever deleted to save storage cost.

18.10 Support and operations

18.10.1 At current scale, support is handled by people who can plausibly know most members personally.

18.10.2 10x requires a support and operations tool with a case record tied to the canonical Person (ENT-01), so context is not lost between one support interaction and the next.

18.10.3 100x requires tiered support (self-service surfaces answering the most common questions, escalation paths for the rest) and an operational reporting discipline (Codex 0 §14) covering reliability and access review at a cadence someone actually reads, not merely generates.

18.10.4 1000x requires support and operations to be organized regionally or by division (Codex 2) with a shared canonical case and audit trail, so that scale does not fragment the institution's single view of a member's history even as the people serving that member are distributed.

18.10.5 What never changes: a member's support history and the reasoning behind any elevated access to their record remain auditable (Codex 1, Article VI.6; §17.9).

18.11 Organizational structure

18.11.1 The five divisions and two offices (Codex 0 §3) are designed to scale by depth within each division before width is added.

18.11.2 10x the institution's size is absorbed inside the existing division structure: more people, more curriculum, more engagements, within the same five-division map.

18.11.3 100x may require a sixth division. The seam for this is Codex 0 §15.1 and is exercised, not invented fresh, when the need arises: the registry and interface pattern accept a new DIV- entry without touching the interfaces of the other five.

18.11.4 1000x may require sub-division structures (regional academies, discipline-specific advisory practices) organized beneath an existing division, which is an internal division matter under Codex 2 and does not by itself require a new top-level division or a new API boundary.

18.11.5 What never changes: the rule against duplication (Codex 0 §2) — two divisions never build a second version of the same shared capability; a shared need always moves to Technology (DIV-05).

18.12 The ten expansion seams (Codex 0 §15), in enforceable detail

18.12.1 Seam 1 — New division. Attaches: a new DIV- entry in the registry with the same eight-question record as the existing five. Must already be stable: the division interface pattern (how a division declares what it consumes from CapabilityOS and produces for others, Codex 0 §2) and the rule against duplication (§18.11.5). Data introduced: whatever canonical entities the division's workflows require, proposed and reviewed like any other (Codex 0 §16). Breaks if bolted on: a division added without registry entries duplicates existing engines instead of consuming them, and its data model diverges from Codex 5 normalization from day one.

18.12.2 Seam 2 — Universities and governments. Attaches: Organization (ENT-03) plus Partner membership plus SSO identity federation. Must already be stable: API-01 (Identity & Access) supporting external identity providers, and an agreed-reporting-scope mechanism (§18.8.4). Data introduced: Organization records, bulk membership records, agreed reporting scope. Breaks if bolted on: partner accounts created as one-off manual identities rather than through federated SSO become orphaned records with no path to bulk deprovisioning when a partnership ends, and reporting scope negotiated informally rather than encoded leaks data outside what was agreed.

18.12.3 Seam 3 — Languages and regions. Attaches: additional locales for content and layout; region-scoped Organization and data residency configuration. Must already be stable: localization-ready content architecture (Chapter 17, §17.12) and the residency-as-configuration pattern (§18.9.4). Data introduced: locale variants of curriculum and public content; residency metadata on Organization and Person. Breaks if bolted on: content hardcoded in one language requires a parallel fork of every surface to add a second language, which is exactly the rewrite this seam exists to avoid.

18.12.4 Seam 4 — New engine. Attaches: a new ENG- entry implementing the CapabilityOS engine interface pattern (Codex 0 §5; Chapter 17 §17.3). Must already be stable: the engine interface contract (declared inputs, outputs, and the rule that an engine never reaches into another's storage). Data introduced: whatever the new engine's domain requires, consumed from and produced to the knowledge graph and other engines through their declared interfaces. Breaks if bolted on: an engine built by directly querying another engine's tables couples the two permanently and makes either one unreplaceable without breaking the other (Chapter 17 §17.3.3).

18.12.5 Seam 5 — New credential class. Attaches: a new expression of Capability (ENT-06), CapabilityAssessment (ENT-07), and Credential (ENT-08), which already generalise beyond course completion (Codex 0 §15.5). Must already be stable: the Capability/Assessment/Credential entity model and API-05 verification contract (§18.2.2). Data introduced: new capability taxonomy entries and assessment rubrics specific to the new class; no new top-level entity. Breaks if bolted on: a credential class implemented as a special-cased table outside ENT-08 produces a credential that permanent verification (§18.6) cannot resolve alongside every other credential the institution has issued.

18.12.6 Seam 6 — Third-party integration. Attaches: an external caller consuming one or more published API- boundaries. Must already be stable: the specific API boundary's contract, its versioning discipline (Chapter 17, §17.5.6), and caller verification (§17.5.3). Data introduced: none beyond what the boundary already exposes; an integration is a consumer, not a data source, unless it writes back through the same boundary. Breaks if bolted on: direct database access granted to a partner to "save time" cannot be revoked cleanly, bypasses row-level policy review, and is precisely the private path Codex 0 §15.6 forbids.

18.12.7 Seam 7 — New school or program. Attaches: a new node in the curriculum hierarchy (§18.4.1), authored through TOOL-01. Must already be stable: the curriculum hierarchy's n-deep, data-driven structure and ENT-09's status as data rather than hardcoded page content. Data introduced: new Curriculum entity rows; no schema change. Breaks if bolted on: a school authored as a bespoke set of hardcoded routes (as opposed to curriculum data rendered by the existing hierarchy) duplicates the delivery engine (ENG-02) instead of using it, violating the rule against duplication (§18.11.5).

18.12.8 Seam 8 — Public knowledge surfaces. Attaches: a new SURF- entry generated from canonical sources (publications, indexes, the glossary, a possible Codices reading surface). Must already be stable: the canonical source it renders (ENT-13/ENT-14, or this book itself) and the rule that a surface names its data and engine or declares itself editorial (Codex 0-REGISTRY, rule 4). Data introduced: none beyond what the canonical source already holds; the surface is a read view. Breaks if bolted on: a public surface authored with its own duplicate copy of content drifts from the canonical source the first time either is edited, and the institution ends up maintaining two versions of the truth.

18.12.9 Seam 9 — Capital vehicles. Attaches: Investment (ENT-16) generalising to funds and syndicates, per Codex 0 §15.9. Must already be stable: ENT-15 (Venture) and ENT-16 (Investment) as they exist for direct investment, and API-08. Data introduced: fund and syndicate entities that reference existing Investment rows rather than duplicating them; participant records for indirect investors. Breaks if bolted on: a fund vehicle modeled as a wholly separate system from ENT-16 produces two incompatible views of the same underlying capital flows, breaking investor reporting (DASH-07) reconciliation.

18.12.10 Seam 10 — Successor stewardship. Attaches: the transfer of stewardship authority (Codex 0 §3, §15.10) to a successor generation, exercised through the amendment record (Codex 9). Must already be stable: the amendment record itself as a complete, chronological, and legible history of every doctrine change — this is the mechanism, not a system to be built later. Data introduced: none beyond the decision records already required by every amendment (DECISIONS/). Breaks if bolted on: if amendment history has been kept informally or incompletely, a successor steward inherits an institution whose doctrine cannot be reconstructed, defeating the purpose of Article VII's hundred-year horizon.

18.13 Interfaces

18.13.1 A threshold named in §18.3–§18.11 is met by moving the affected registry entry's implementation forward without changing its ID, its declared interface, or its governing Codex.

18.13.2 A seam exercised under §18.12 is recorded by creating the new registry entry (or entries) it requires, per Codex 0 §16's eight-question record, before implementation begins.

18.14 Invariants

18.14.1 No scale threshold ever produces a second canonical Person record for one human being.

18.14.2 No scale threshold ever breaks resolution of a credential issued before the threshold was crossed.

18.14.3 No registry ID is reassigned or reused when a threshold forces a re-architecture of the entry it names.

18.14.4 No new API boundary is created to route around an existing one that has become a bottleneck; the existing boundary is scaled instead, or a decision record justifies and numbers a genuinely new boundary.

18.14.5 No expansion seam is exercised without the "must already be stable" precondition named in §18.12 being true at the time.

18.15 Prohibitions

18.15.1 No sixth division created by giving an existing division's team a new name without a registry entry and interface review.

18.15.2 No partner or integration granted direct database access as a substitute for a published API boundary, at any scale.

18.15.3 No credential class implemented outside the ENT-06/ENT-07/ENT-08 model.

18.15.4 No index or capability metric's computation changed without a version and a published methodology note.

18.15.5 No permanent record (credential, audit, assessment) deleted to manage storage growth.

18.15.6 No new public surface duplicating content already canonical elsewhere instead of rendering it.

18.16 Open questions

18.16.1 The specific sharding strategy for the knowledge graph at 100x (§18.7.3) is deferred to a decision record at the time ENG-01 is built past its reserved status.

18.16.2 The organizational mechanism for sub-division structures at 1000x (§18.11.4) — whether by charter amendment or executive decision alone — is deferred to Codex 9.

18.16.3 The specific jurisdictional data residency framework referenced in §18.9.4 is deferred until a partner organization first requires it.

18.17 Governing Codices

18.17.1 Codex 1 (Constitution), Article VII.

18.17.2 Codex 0 §§1–15 and the Registry, in full, as the baseline this chapter projects forward.

18.17.3 Codex 2 (Divisions), for organizational-structure consequences.

18.17.4 Codex 5 (Data and APIs), for entity and boundary stability.

18.17.5 Codex 8 (Financial Doctrine), for the capital consequences of scale not addressed here.

18.17.6 Codex 9 (Governance and Amendment), for the seam-10 mechanism.

18.17.7 Chapter 17, for the engineering mechanisms by which thresholds are actually met.

18.18 Reading this chapter with the Registry

18.18.1 This chapter names conditions; the Registry (Codex 0-REGISTRY) names status. When a threshold in this chapter is met, the corresponding registry entry's status field is updated in the same change that implements it, per Codex 0-REGISTRY rule 5.