0006 — The Institutional Systems Architecture

Date: 2026-07-31 Status: accepted Establishes: Codex 11; Codex 0 chapters 20 and 21; the SYS- Registry class; the nine-field decision record. Extends: 0001, 0003, 0004, 0005.

This record is written in the nine-field form it establishes, as the first instance of it.

1. Decision

Four things are adopted.

The four pillars. Human, Intellectual, Financial, and Technological Capital become the institution's frame for what it develops. They sit above the eight institutional strengths (Codex 0 §01.5) as forms of capital; the eight strengths remain the Codex 1 Article III feature test. Trust is not a pillar — it is the condition on which all four compound, and is therefore tested against each of them.

The twelve institutional systems. SYS-01 Identity, SYS-02 Learning, SYS-03 Knowledge, SYS-04 Business, SYS-05 Finance, SYS-06 Ventures, SYS-07 AI, SYS-08 Communication, SYS-09 Analytics, SYS-10 Governance, SYS-11 Operations, SYS-12 Infrastructure. Divisions own outcomes; systems own capability and cross every division. Every Registry entry names exactly one system. The twelve are permanent and closed: a thirteenth requires an amendment to Codex 11, not a decision record.

The capability graph, with consent tiers. One institutional graph, in three tiers of participation: institutional records always present; relationship records present but visible only to the parties and to explicitly scoped roles; personal signals — AI conversations, private drafts, notes, meeting content — never nodes. Institutional-intelligence questions are classified in writing as permitted, aggregate only, self only, or refused, before they are answered. A match between people is an offer that may be declined, never an assignment or a disclosed ranking. No answer is ever sold.

Institutional memory and the lifecycle. A permanent, append-only memory layer for institutional acts; the nine-field decision record with a mandatory written result; and the fourteen-stage lifecycle from Discover to Retire or Supersede, mapped onto the Registry statuses so that built requires Standardize, Teach, and Preserve rather than merely running.

2. Reasoning

Anabasis had divisions (Codex 2) and engines (Codex 3) but no permanent horizontal axis. Without one, every shared capability is built where it is first needed and then forked when a second division needs it. Identity is the clearest case: it belongs to the institution, and any division that owns it will shape it around its own needs. The twelve systems give every capability a permanent home that outlives the department that first required it.

The memory layer addresses the specific failure of long-lived organisations: they forget why. Not what — the what survives in the artefact — but why, which alternatives were rejected, and whether the expected outcome occurred. The result field is the whole point; without it a decision log is a record of intentions.

3. Alternatives considered

Replace the five divisions with the twelve systems. Genuinely viable, and the most tempting reading of the proposal. Rejected because accountability requires a named owner of outcomes, and a system cannot be held to a target — capability domains do not report. Dropping divisions would leave the institution with structure and no accountability. Instead, both axes exist, and the reconciliation is stated exactly (Codex 0 §20.4).

Extend the graph to everything, as literally proposed. Rejected on constitutional grounds. Codex 0 §06.9 and §06.13, Codex 4 §04.12, and Codex 1's no-surveillance commitment forbid it. The consent-tier model delivers the institutional intelligence the proposal wants — a person told what they have demonstrated and what remains — without building a system that would be indefensible to a member, a regulator, or a successor steward.

Add the memory fields to Codex 9 without a new chapter. Rejected as insufficient: the lifecycle, the question classification, and the exclusion rules have nowhere to live in a procedure section, and would have been lost.

4. Evidence reviewed

Codex 1 Articles III–V; Codex 0 §01.5 (the eight strengths), §02 (divisions), §05 (eleven engines), §06.9 and §06.13 (graph node prohibitions), §04.12 (people prohibitions), §16.5 (aggregation thresholds), §18 (scale seams); the Registry's ten ID classes; Codices 2, 3, 9, 10; docs/standards/00-index.md.

5. Expected outcomes

Every future proposal names a system before it is built, which should show up as fewer duplicate capabilities and no per-division forks. Every decision from this date carries nine fields with a review date. Registry entries stop reaching built while unstandardised and untaught.

6. Owner

Stewardship Office (DIV-07), as custodian of the Codices. Chapter 20's assignment of Registry IDs to systems is maintained with the Registry itself.

7. Date

2026-07-31.

8. Review schedule

Reviewed 2027-07-31, and thereafter annually with the Registry. Two specific things to check at review: whether any capability has been built outside a system, and whether any decision record's result field is unwritten past its review date.

9. Result

Unwritten. Due 2027-07-31. Per Codex 0 §21, this record is overdue if the field is still unwritten after that date. Decision records 0001–0005 predate the nine-field form; their results are appended at their next review rather than retroactively invented.

Institutional Critic (Codex 10)

1. 1Failure at 100x. The graph. A graph connecting every person, credential, engagement, and venture becomes both a performance problem and the single most attractive target in the institution. Codex 0 §06.10 and §18.7 already govern its scale behaviour; the consent tiers reduce the blast radius by keeping the highest-sensitivity material (conversations, drafts) permanently out of it. The second failure is the memory layer growing without curation until search returns everything and therefore nothing; §21 addresses this with supersession-in-place rather than accumulation.
2. 2Unverified assumptions. That twelve systems are the right twelve, and that they are genuinely exhaustive. Unverified — nothing has been built into most of them. Mitigated by making a thirteenth a Codex amendment rather than forbidding it outright, so the pressure to add one is visible rather than routed around. Also unverified: that anyone will write the result field. That is a discipline problem no document can solve; the mitigation is the overdue list.
3. 3Simpler solution. Assign a system tag to Registry entries and write nothing else. Rejected: a tag with no boundary tests is decided by whoever files the entry, and within a year the tags mean nothing. The boundary tests in §20.5 are the part that does the work.
4. 4Duplication. The systems overlap the divisions and engines by design, and the risk of them becoming a second, competing structure is real. Handled by §20.4: one reconciliation clause set, stating that systems group engines rather than replace them, and that no system is owned by a division. The memory layer overlaps SYS-03 Knowledge and SYS-10 Governance; the boundary test is that Knowledge holds the corpus and Governance holds the record of decisions.
5. 5Enterprise view. Favourable. An enterprise buyer's diligence asks who owns identity, where data lives, what is retained, and what is never collected. The consent tiers and the exclusion list answer the hardest of those questions in the negative, which is the answer that earns trust.
6. 6First-time user. Sees nothing. That is correct: this is internal doctrine, and no surface changes. When surfaces are eventually built on the graph, the first-time experience is governed by the Codex 6 rubric and by the rule that a match is an offer.
7. 7Legal, operational, security. The exclusion of personal signals is a data-protection posture as much as an ethical one: material never collected cannot be breached, subpoenaed, or misused. The self-only and aggregate-only classifications keep the institution clear of profiling people to third parties. Operationally, the nine-field record adds a recurring obligation — the review — that must be staffed or it will lapse.
8. 8Debt. Named: Chapter 20 assigns every existing Registry ID to a system, but the per-entry SYS- column is not yet added to the ten Registry tables; the assignment currently lives in the chapter. Repaid at the next Registry revision, when the column is added and the two are reconciled. Second: decision records 0001–0005 lack the nine fields and are reconciled at review, not retroactively.
9. 9Consistency. Nothing here alters Codex 1. The one place the proposal as received conflicted with doctrine — the unrestricted graph — was resolved in favour of doctrine and the conflict is stated in Codex 11 and in §21 rather than smoothed over.

Codex 8 evaluation

Revenue potential: indirect, and one direct seam — REV-06, licensing CapabilityOS to partner institutions, is materially easier to sell when the twelve systems and their boundaries are specified. Implementation cost: doctrine only; no runtime cost. Maintenance cost: moderate and permanent — the system assignment must be kept true as the Registry grows, and the decision reviews must actually happen. Operational complexity: adds one question ("which system?") to every proposal and one recurring review obligation. Customer value: indirect now; high later, through capability recommendations that are directed at the person rather than at the institution's engagement figures. Enterprise value: high — this is the document diligence asks for. Long-term strategic value: the highest of any doctrine written so far. The systems are what remain when every current department, technology, and person is gone.