Codex 0 · Chapter 20 — The Twelve Institutional Systems

This chapter specifies the twelve institutional systems, SYS-01 through SYS-12: what each holds, the pillar it serves, and the boundary it never crosses. It reconciles the system view with the five divisions of Chapter 02 and the eleven engines of Chapter 05, and assigns every existing Registry entry to exactly one system.

20.0 Purpose

20.0.1 An institution is not its departments; it is the systems that connect them. Departments change, people come and go, technology evolves — systems endure. A division can be renamed, absorbed, or split without the institution losing what it knows how to do; a system cannot be discarded without the institution losing a capability outright.

20.0.2 This chapter exists so that every capability the institution operates belongs to a defined institutional system, never to an isolated department. It states the first principle, the four pillars, the twelve systems in full, and the boundaries between them, so that a builder can place any new capability without inventing a thirteenth home for it.

20.0.3 This chapter reconciles three views of the same institution that could otherwise drift apart: divisions (Chapter 02, who is accountable for outcomes), engines (Chapter 05, what implements a capability), and systems (this chapter, what capability exists and where it lives regardless of who is accountable for it or how it is built).

20.1 Scope and non-scope

20.1.1 In scope: the first principle; the four pillars of capital and their relationship to the eight institutional strengths of Codex 0 §01.5; the twelve institutional systems, SYS-01 through SYS-12, their responsibilities, holdings, and prohibitions; the boundaries between adjacent systems; the relationship between systems, divisions, and engines.

20.1.2 Not in scope: division mandates and capacity (Chapter 02); engine interfaces and internals (Chapter 05); the canonical shape of any entity (Chapter 07); API contract mechanics (Chapter 10); permission enforcement (Chapter 08); the specific technology chosen to implement any system, which is an engineering decision under Chapter 17.

20.1.3 This chapter does not create new Registry entries and does not change the status of any existing one. It re-groups what the Registry already enumerates under a durable, division-independent structure. Where this chapter and the Registry appear to disagree on an ID's holder, the Registry's division ownership (Chapter 02, §02.9) and this chapter's system ownership are two different questions and both stand (§20.4).

20.2 The first principle

20.2.1 Every capability the institution operates belongs to exactly one of twelve institutional systems. A capability that fits none of the twelve is misconceived and is redesigned, not appended (§20.4.5).

20.2.2 A system is defined by what it is responsible for holding and deciding, independent of which division is presently accountable for it, which engine presently implements it, or which surface presently displays it. Two divisions may consume the same system; a system is never rebuilt a second time to save a division from depending on the first.

20.2.3 Systems are permanent in number. The twelve named in §20.3 are the complete and closed list. A thirteenth requires a Codex amendment (§20.9.4), never a decision record made in the course of ordinary work.

20.2.4 Every initiative — a feature, a surface, an engine, an agent — strengthens one or more of the twelve systems and, through it, one or more of the four pillars (§20.2). A proposal that cannot name the system it strengthens has not yet been designed.

20.3 The four pillars

20.3.1 Above the twelve systems and the eight institutional strengths sits a smaller frame: the four forms of capital an institution accumulates over a hundred-year horizon. Every system, in the end, compounds one or more of these.

20.3.2 The pillars are forms of capital, not a second feature test. Codex 1 Article IV and Codex 0 §01.4.2 already require every feature to strengthen at least one of the eight institutional strengths — people, knowledge, trust, technology, research, education, capital, community. That test is not superseded, relaxed, or duplicated here. The pillars sit above the eight strengths as an accounting of what kind of capital a strengthened strength ultimately becomes; they are read after the Article IV test is passed, never instead of it.

20.3.3 Mapping the eight strengths to the four pillars:

20.3.4 Trust is not a form of capital. It is the condition on which all four forms of capital compound. A person will not invest human capital in an institution they do not trust; knowledge is worthless if its provenance cannot be trusted; financial capital withdraws at the first sign of broken commitments; technology adopted without trust in its stewardship is technology rejected. Trust is therefore treated explicitly, in every system that touches it, as the precondition rather than as a fifth pillar competing for the same ledger line as the other four.

20.3.5 Every initiative names at least one pillar it strengthens, drawn from which strength it satisfies under Article IV (§20.3.3). An initiative claiming to strengthen a pillar while failing every one of the eight strengths has misapplied this section and is redesigned.

20.4 The system / division / engine relationship

20.4.1 Divisions (Chapter 02, DIV-) own mandates and outcomes: they are accountable for what gets produced and for whom. Systems own capability and cross every division: they are what exists, independent of which division is presently drawing on it. Engines (Chapter 05, ENG-) are implementations inside a system: the concrete server-side unit that does the recording, sequencing, or computing.

20.4.2 A system is never owned by a division. Ownership in the divisional sense (Chapter 02 §02.2.1) continues to apply to every Registry entry individually; a system is the grouping those entries sit inside, and the grouping itself answers to no single division.

20.4.3 Every Registry entry names exactly one system, in addition to the exactly one division it already names under Chapter 02 §02.2.1. The two assignments answer different questions — who is accountable (division) and what capability this is (system) — and neither substitutes for the other.

20.4.4 Where a capability is needed by two divisions, Chapter 02 §02.2.3 already requires it to move to DIV-05 Technology rather than be built twice. This chapter adds the system-level form of the same rule: a capability needed by two divisions belongs to the one system that owns it, and no division builds a private copy of that system's capability inside its own surfaces to avoid depending on it.

20.4.5 The twelve systems are permanent and closed (§20.2.3). Anything proposed that fits none of them is not a gap in the list; it is a sign the proposal has been designed around a department rather than around an institutional capability, and it is redesigned before it is given a Registry entry.

20.4.6 The twelve systems do not replace the five divisions of Chapter 02 or the eleven engines of Chapter 05. They group them. A division remains the answer to "who is accountable for this outcome." An engine remains the answer to "what computes or records this." A system is the answer to "what durable institutional capability is this part of," and that answer is what survives a division being restructured or an engine being rewritten.

20.5 The twelve institutional systems

Each system is given in the same form: purpose, what it holds (by Registry ID), the pillar it primarily serves, what it must never absorb, and its scale behaviour.

20.5.1 SYS-01 — Identity

Purpose. Holds the single, durable record of who a person or organization is to the institution, and what they are permitted to do.

Holds. ENT-01 Person, ENT-02 Identity, ENT-03 Organization, ENT-04 Membership, ENT-05 Role · API-01 Identity & Access, API-02 Person & Membership · TOOL-04 Admissions & Intake · SURF-15 /enroll, SURF-20 /scholar/settings.

Pillar. Human Capital, as the precondition for every other holding of it: no capability record means anything until the person it describes is uniquely and durably known.

Must never absorb. Curriculum, credential meaning, or any subject-matter record. Identity states who someone is and what they may do; it never states what they know or have built.

Scale behaviour. Role lookups on every authorization check are indexed and cached from 10x current scale onward (Chapter 18 §18.3.2); identity federation with partner institutions becomes load-bearing, not occasional, at 100x (§18.3.3).

20.5.2 SYS-02 — Learning

Purpose. Delivers curriculum, assesses demonstrated capability, and issues the credentials that certify it.

Holds. ENG-02 Learning, ENG-03 Adaptive · API-03 Curriculum, API-04 Progress & Assessment, API-05 Credential & Verification · WF-01 Enrolment to credential, WF-06 Alumni to mentor · ENT-07 CapabilityAssessment, ENT-08 Credential, ENT-09 Curriculum, ENT-10 Enrolment, ENT-11 Cohort, ENT-17 Artifact · TOOL-01 Curriculum Authoring, TOOL-02 Assessment & Review Console, TOOL-03 Credential Issuance · SURF-10 through SURF-14 (Academy surfaces), SURF-16 through SURF-19 (Scholar surfaces).

Pillar. Human Capital.

Must never absorb. The corpus of published knowledge a curriculum is built from, or the graph of what connects to what — that is Knowledge's holding (§20.5.3), consumed by Learning through a declared interface (ENG-01, API-09), never duplicated inside it.

Scale behaviour. The authoring tool must support versioning and review at the module level, not only the course level, from 10x volume onward, so ten times the content does not mean ten times the review bottleneck per change (Chapter 18 §18.4.2).

20.5.3 SYS-03 — Knowledge

Purpose. Holds the institution's durable corpus — research, publications, the capability taxonomy, and the graph connecting them — as its long-term memory of what is known and how it was proven.

Holds. ENG-01 Knowledge Graph, ENG-09 Research · API-07 Publication & Index, API-09 Knowledge Graph · WF-03 Research to curriculum · ENT-06 Capability, ENT-13 Publication, ENT-14 Index · TOOL-05 Editorial Pipeline, TOOL-06 Index Management · SURF-03 /philosophy, SURF-06 /glossary, SURF-09 /research.

Pillar. Intellectual Capital.

Must never absorb. The record of institutional decisions made from research — that is Governance's memory (§20.5.10) — and never the delivery mechanics of teaching a capability, which belongs to Learning even where Knowledge supplies the substance being taught.

Scale behaviour. At 100x the number of capabilities and curriculum units, adaptive queries against the graph must run over a pre-computed or indexed representation rather than a full traversal per request, and the graph itself is partitioned by domain for write purposes while remaining queryable as one graph for cross-division linkage (Chapter 18 §18.7.2–§18.7.3).

20.5.4 SYS-04 — Business

Purpose. Applies institutional capability inside client organizations: engagements, diagnostics, and the operational relationship with enterprise clients and partners.

Holds. ENG-08 Business, ENG-10 Advisory · API-06 Engagement · WF-02 Credential to advisory engagement, WF-05 Enterprise client to cohort · ENT-03 Organization (as client), ENT-12 Engagement · TOOL-07 Engagement Management, TOOL-09 Partner & Enterprise Console.

Pillar. Financial Capital, with Human Capital as the direct means by which it is earned — a Business engagement exists to apply developed people's capability, not to sell capacity for its own sake.

Must never absorb. Equity ownership in, or the building of, an organization from nothing — that is Ventures (§20.5.6). An engagement serves an organization that already exists and remains independent of the institution; a venture is one the institution helped build and may hold a stake in.

Scale behaviour. Constrained by qualified advisor availability at every scale (Chapter 02 §02.4.5); an engagement is never accepted without a named accountable advisor whose committed capacity is on record, regardless of demand.

20.5.5 SYS-05 — Finance

Purpose. Holds the institution's ledger: revenue, reserves, forecasting, and the financial record the institution and its members rely on.

Holds. ENG-07 Financial · WF-07 Annual accounting · REV-01 through REV-06, all revenue streams.

Pillar. Financial Capital.

Must never absorb. The interpretation of the ledger for decision-making purposes, which belongs to Analytics (§20.5.9); Finance is the ledger of record, not the dashboard drawn from it. Finance also never absorbs equity stakes in ventures the institution has built, which remain a Ventures holding even where their value appears in institutional accounts.

Scale behaviour. Reporting on financial data runs against precomputed aggregates refreshed on a stated cadence from 10x volume onward, never live joins across every canonical table at request time (Chapter 18 §18.8.2).

20.5.6 SYS-06 — Ventures

Purpose. Develops founders and builds enterprises the institution helps capitalize, from intake through investment and reporting.

Holds. ENG-11 Venture · API-08 Venture & Capital · WF-04 Founder intake to venture to capital · ENT-15 Venture, ENT-16 Investment · TOOL-08 Venture Pipeline · SURF-07 /ecosystem, SURF-08 /institutions.

Pillar. Financial Capital, compounded through Human Capital — a venture is built by developed founders, and its outcome returns capital and community to the institution.

Must never absorb. Advisory work for organizations the institution does not hold a stake in — that traffic is Business's (§20.5.4). Ventures also never absorbs Finance's ledger function; an investment record here states what was committed and to whom, not the institution's own financial position.

Scale behaviour. Venture count never exceeds the mentor and studio capacity recorded for the cohort period, at any scale (Chapter 02 §02.6.5).

20.5.7 SYS-07 — AI

Purpose. Holds every agent and every engine whose function is recommendation, planning, decision-structuring, or reasoning over another system's data, always advisory and never the system of record for what it reasons about.

Holds. ENG-04 Goal, ENG-05 Habit, ENG-06 Decision · AGT-01 through AGT-14, all agents.

Pillar. Technological Capital, in direct service of Human Capital — every agent exists to make a person's or the institution's own judgement more capable, never to substitute for it.

Must never absorb. The source of truth for any other system's data (§20.6, boundary 6). AI holds the reasoning layer over Learning's progress, Knowledge's graph, Finance's ledger, and Business's engagements; it never becomes the place any of those facts are authoritatively recorded, and it never becomes the recorded decision-maker of a consequential act (Chapter 05 §05.6.6.2).

Scale behaviour. The first-pass reviewer agent (AGT-04) becomes load-bearing for triage at 100x submission volume, while the human checkpoint before any weighted result remains mandatory without exception at every scale (Chapter 18 §18.5.3).

20.5.8 SYS-08 — Communication

Purpose. Holds messaging, notifications, calendar, events, and the community and forum spaces members and organizations use to reach each other.

Holds. No Registry ID is presently assigned to this system; it is named and reserved so that messaging, notification, calendar, and community capability is not built piecemeal inside Learning or Business surfaces before a proper boundary exists for it (§20.9.2 records this as open).

Pillar. Human Capital, through Trust as its compounding condition — communication is the channel through which every commitment the institution makes to a person is actually delivered and confirmed.

Must never absorb. Assessed instruction. A message, notification, or forum post is never the vehicle by which a capability is taught and certified; that remains Learning's holding even where Communication carries the surrounding conversation (§20.6, boundary 9).

Scale behaviour. Not yet specified; this system's engine and boundary do not exist, and no scale behaviour can be stated for a capability that has not been built (§20.9.1).

20.5.9 SYS-09 — Analytics

Purpose. Holds the institution's reporting, dashboards, and the interpretation of institutional performance drawn from every other system's data, within agreed scope.

Holds. API-10 Reporting & Analytics · DASH-01 through DASH-10, all dashboards · ENT-18 Event · TOOL-10 Reporting Studio · SURF-05 /annual-report.

Pillar. Technological Capital, in service of every other pillar — Analytics exists to make what the institution already holds legible, not to hold anything new itself.

Must never absorb. The ledger, the graph, the enrolment record, or any other system's primary data. Analytics is a read layer over declared boundaries (Chapter 05 §05.2.5); a dashboard that stores its own copy of another system's facts has stopped being Analytics and has become an unauthorized second record.

Scale behaviour. Versioned index methodology is enforced by tooling, not convention, from 100x volume onward, because at that size a silent change to how a measure is computed is indistinguishable from outside from a real change in the underlying trend (Chapter 18 §18.8.3).

20.5.10 SYS-10 — Governance

Purpose. Holds the Codices, institutional policy, the audit trail of consequential action, and the institution's own memory of the decisions it has made.

Holds. API-11 Audit · ENT-19 AuditRecord · TOOL-11 Access & Audit Console · SURF-01 /, SURF-02 /charter, SURF-04 /leadership, SURF-14 /academy/doctrine.

Pillar. Trust, held explicitly rather than folded into one of the four pillars (§20.3.4) — Governance is the system whose entire purpose is to keep the condition on which the other four compound intact.

Must never absorb. Research memory. Governance records what the institution decided and why; it never becomes a second copy of Knowledge's corpus of what the institution has learned through research (§20.6, boundary 3). It also never absorbs measurement itself, which is Analytics's holding; Governance holds the record of decisions made from a measurement, not the measurement.

Scale behaviour. The audit boundary (API-11) remains append-only at the data layer at every scale; no caller, regardless of role, is ever granted an update or delete path against an AuditRecord (Chapter 10 §10.12.11).

20.5.11 SYS-11 — Operations

Purpose. Holds the institution's own internal administration: its people as employees, its internal projects, and the vendors and assets it depends on to function.

Holds. No Registry ID is presently assigned to this system; internal HR, hiring, payroll, and vendor administration are not yet named as Registry entries, and this system is reserved so that such capability, when built, is not folded into Identity's holding of the institution's members (§20.6, boundary 1; §20.9.3).

Pillar. Human Capital, applied to the institution's own staff rather than to its members.

Must never absorb. A person's institutional record as a member, scholar, founder, or client. Operations administers employment; it never becomes a second Person record or a second Role grant outside the one canonical record Identity holds (Chapter 07 §07.2.2).

Scale behaviour. Not yet specified; no engine or boundary exists for this system today.

20.5.12 SYS-12 — Infrastructure

Purpose. Holds the mechanism the whole institution runs on: cloud, databases, storage, security enforcement, monitoring, and disaster recovery.

Holds. No dedicated Registry ID is presently assigned to this system as a standalone entry; its responsibilities are presently exercised as the operating substrate beneath every ENG-, API-, and SURF- entry owned by DIV-05, and as the engineering standards of Chapter 17 rather than as entries of their own (§20.9 records this as an open question worth a future Registry pass).

Pillar. Technological Capital.

Must never absorb. The model of who a person is. Infrastructure enforces security mechanically — encryption, access control at the transport and storage layer, backup and recovery — but the meaning of who someone is and what they are permitted to do is decided by Identity and Chapter 08's permission model, never inferred by Infrastructure from what it happens to be able to technically restrict (§20.6, boundary 8).

Scale behaviour. Verification uptime and other permanent-boundary infrastructure must be served independently of the rest of the platform's availability from 1000x scale onward, because at that size external parties depend on it as public infrastructure (Chapter 18 §18.6.4).

20.6 Boundaries between adjacent systems

20.6.1 Identity vs. Operations. Test: is this a person's institutional record of who they are and what they may access, or the employment administration of a staff member's job at the institution? The former is Identity; the latter is Operations. A staff member is still exactly one Person record in Identity; their employment file is a separate Operations record referencing that same Person, never a duplicate of it.

20.6.2 Learning vs. Knowledge. Test: is this the delivery of a specific curriculum to a specific scholar, or the corpus and graph a curriculum draws its content from? Delivery, progress, and assessment are Learning; the corpus, its provenance, and the graph of what connects to what are Knowledge.

20.6.3 Knowledge vs. Governance. Test: is this the institution's memory of what it has learned through research, or its memory of what it decided and why? Research memory is Knowledge; the record of decisions, including decisions that drew on research, is Governance.

20.6.4 Business vs. Ventures. Test: is the institution serving an organization that exists independently of it, or building one it holds a stake in? Serving is Business; building and capitalizing is Ventures.

20.6.5 Finance vs. Analytics. Test: is this the ledger itself, or the interpretation of the ledger for a decision or a report? The ledger of record is Finance; every dashboard, forecast narrative, and index drawn from it is Analytics.

20.6.6 AI vs. every system. Test: does this hold the authoritative fact, or reason over a fact held elsewhere? AI holds agents and reasoning; it never holds the source of truth for another system's data, and a recommendation it produces is advisory until a human or another system of record acts on it (Chapter 05 §05.6.3.2).

20.6.7 Analytics vs. Governance. Test: is this the measurement, or the record of a decision made because of the measurement? Measurement and its aggregation are Analytics; the decision record — who decided, on what evidence, and why — is Governance.

20.6.8 Infrastructure vs. Identity. Test: is this the mechanism that enforces security, or the model of who someone is and what they may do? Encryption, access control enforcement, and monitoring are Infrastructure; the Person, Role, and Membership model those mechanisms enforce is Identity.

20.6.9 Communication vs. Learning. Test: is this a conversation, or assessed instruction? A message, a forum thread, a calendar invitation is Communication; a lesson, a submission, and its graded assessment is Learning, even where a conversation about that lesson happens alongside it in Communication.

20.7 Interfaces

20.7.1 Every Registry ID named in §20.5 is unchanged in its Chapter 02 division and Chapter 05/10 boundary specification; this chapter adds a system field to each without altering any other field.

20.7.2 DIV-01 through DIV-07 (Chapter 02) remain the accountable owners of the entries listed above; no division loses ownership by virtue of this chapter's grouping.

20.7.3 ENG-01 through ENG-11 (Chapter 05) are distributed across SYS-02, SYS-03, SYS-04, SYS-05, SYS-06, and SYS-07 as specified in §20.5; none is duplicated across two systems.

20.7.4 API-01 through API-11 (Chapter 10) are distributed across SYS-01, SYS-02, SYS-03, SYS-04, SYS-06, SYS-09, and SYS-10 as specified in §20.5.

20.8 Invariants

1. 1Every Registry entry names exactly one system, in addition to exactly one division.
2. 2The twelve systems are the complete and closed list; nothing is added to it by decision record alone (§20.9.4).
3. 3No system holds another system's source of truth; cross-system access happens through the producing system's declared boundary (Chapter 05 §05.3, Chapter 10).
4. 4Every initiative names the pillar it strengthens, and does so only after passing the Article IV eight-strength test (§20.3.2).
5. 5Trust is treated as the condition on which the four pillars compound, never as a fifth pillar competing for the same accounting.
6. 6AI never becomes the recorded decision-maker or the system of record for any fact it reasons over.

20.9 Prohibitions

1. 1No forked implementation of a system's capability inside a single division to avoid depending on the system's declared interface.
2. 2No system holding another system's source of truth, including through a cache or read model that is treated as authoritative rather than rebuildable.
3. 3No thirteenth system created by convenience, urgency, or a single team's preference; a genuine gap is named as an open question (§20.9 below) and closed only by Codex amendment.
4. 4Identity is never delegated to a division; the canonical Person, Role, and Membership record remains a single system regardless of which division's surface a person is using.
5. 5AI never becomes the system of record for data it reasons over, and never becomes the named decision-maker of a consequential act.

20.10 Open questions

1. 1Communication: built or integrated. Whether Communication (SYS-08) is built as a first-party engine and boundary or integrated from a third-party messaging and community platform is undecided; no ENG- or API- ID is presently reserved for it, and the decision materially affects whether Chapter 05's engine interface pattern applies to it at all.

1. 1Where the AI memory layer's storage sits. ENG-04 Goal, ENG-05 Habit, and ENG-06 Decision hold state (goals, cadence, decision records) that is reasoned over by SYS-07 AI but is arguably a durable personal record in its own right, closer in kind to Identity's or Learning's holdings than to a transient recommendation. Whether this state should be re-homed to a system other than AI, or AI should be understood to hold durable state as well as reasoning, is open and should be settled before ENG-04 through ENG-06 leave reserved status.

1. 1Whether Operations is internal-only at present. SYS-11 is defined against internal staff administration because no Registry entry yet exists for it; whether Operations should also hold internal project and task management presently exercised informally by each division, and whether that expands its scope beyond "internal-only," is undecided.

1. 1Whether Infrastructure warrants dedicated Registry entries. SYS-12 presently has no ENG- or API- ID of its own and is treated as the substrate beneath DIV-05's other entries. Whether cloud, storage, and monitoring capability should be given first-class Registry entries of their own, rather than being assumed as an unstated dependency of every other entry, is open.

1. 1Whether ENT-14 Index belongs to Knowledge or Analytics. Index (ENT-14) is authored as durable published measurement (Knowledge, §20.5.3) but is also the raw material Analytics interprets and reports against (§20.5.9). This chapter places it in Knowledge because it is authored and versioned research output rather than a derived dashboard value, but the boundary is close enough to warrant naming here rather than assuming it is settled.

20.11 Governing Codices

Codex 1 (Article III feature test, Article IV institutional test), Codex 0 Chapter 01 (§01.4, §01.5, the tests and the eight strengths), Codex 0 Chapter 02 (the five divisions), Codex 0 Chapter 05 (the engine model), Codex 0 Chapter 07 (canonical entities), Codex 0 Chapter 10 (API boundaries), Codex 0 Chapter 18 (scale and expansion), Codex 0-REGISTRY (all ID classes), Codex 9 (amendment procedure for a thirteenth system).