0008 — The eight-layer institutional architecture, and Creation as the sixth capability

Date: 2026-09-01 · Office: Executive Office, with the Stewardship Office · Review: 2027-09-01

Extends: DECISIONS/0001 (the Codices as supreme authority), DECISIONS/0006 (the twelve institutional systems), DECISIONS/0007 (financial and governance doctrine). Answers: the open question technology-as-pillar, recorded 2026-08-01.

1. Decision

a. The institution is built in eight layers, in this order and no other:

b. Article Zero — the Master Rule. Every item in the institution has one purpose, one owner, one doctrine, one measurable outcome, and one place in the architecture. An item missing any of the five is not incomplete; it is misplaced, and is redesigned rather than shipped.

c. The hierarchy is fixed: Institution → Division → Business Capability → Platform Engine → Platform Service → Product → Feature. No rung is skipped and none is reordered. A feature that cannot name the service beneath it has no place to live.

d. Every engine belongs to CapabilityOS, is owned by Technology (DIV-05), and is consumed by divisions. No division forks an engine. Where two divisions need the same capability, the capability moves into the engine; it is never built twice.

e. The flywheel must close: Research → Academy → Capability → Careers & Business → Advisory → Ventures → Revenue → Research. A stage that produces nothing the next stage consumes is a break, not a stage.

f. The sixth capability is Creation, not Technology. Technology is an enabler and becomes a Division (DIV-05) and, as CapabilityOS and its engines, Layers V–VI. The published Six Capabilities read: Health, Character, Knowledge, Leadership, Capital, Creation.

2. Reasoning

Means change; capabilities are meant not to. The instruments of 1926 are not those of 2026, and a pillar named after the tools of one century cannot be read as doctrine in the next. What endures underneath the instrument is the human act of bringing into existence what did not exist before — an enterprise, an invention, a building, a proof, a body of work, an institution. That is Creation, and technology is one of its instruments.

The eight layers exist for the same reason: to make misplacement visible. An institution fails structurally not when a thing is missing but when a thing sits in the wrong layer — a product carrying doctrine, a division holding an engine, capital allocated before governance names who may allocate it.

3. Alternatives considered

• Keep Technology as the sixth capability. Rejected: it names an instrument, dates the doctrine, and left the actual human capability — making things — unnamed.
• Name the sixth capability Stewardship or Community. Rejected: stewardship is already the disposition Character and Capital carry, and community is an outcome the flywheel produces, not a capability an individual develops.
• Let each division own its own engines. Rejected outright: it is the single most reliable way to fork a platform, and Codex 3 forbids it.
• Fold Engines into CapabilityOS as one layer. Rejected: the systems are permanent and closed at twelve; engines are numerous and revisable. Collapsing them would make every engine an amendment to doctrine.

4. Evidence reviewed

Codex 1 (the capabilities as published); Codex 2 (divisions); Codex 3 (CapabilityOS, the engine ownership rule); Codex 8 Articles III and V (forms of capital, allocation path); Codex 9 (decision rights); Codex 11 and Codex 0 §20 (the twelve systems, closed); Codex 0 §05 and the Registry classes DIV-, ENG-, API-, SURF-, SYS-; the open question technology-as-pillar and its interim position.

5. Conflicts resolved

1. 1Layer V versus the twelve systems. An eleven-item public reading of CapabilityOS circulated alongside the twelve systems of Codex 11. Resolved in favour of Codex 11: the systems remain twelve and closed, and Layer V is a view of them, never a second enumeration.
2. 2Creation versus the creative domain. The twelve measurement domains already held creative. Resolved by scope: the domain measures origination; the capability names what is being developed. technical and creative now both map upward to Creation.
3. 3Technology as capability versus Technology as division. Resolved by layer: DIV-05 in Layer IV, CapabilityOS in Layer V, engines in Layer VI. Nothing named Technology sits in Layer I.

6. Institutional Critic (Codex 10)

• Failure at 100×: the risk is that the layers become labels applied after the fact. Mitigated by making the checks mechanical — architectureDefects() names an engine nothing consumes, a division owning no capability, a broken flywheel, and any identifier absent from the Registry.
• Unverified assumptions: the business-capability list is the first written enumeration and will be revised as divisions are stood up. The rule it enforces — one division, at least one shared engine — does not depend on the list being final.
• Simpler solution: four layers instead of eight. Rejected: governance and capital were the two that collapsed into "the institution", and those are exactly the two that must be separately checkable.
• Duplication: the capability mapping (Constitution → Capabilities → Schools → Domains → Actions → Outcomes) and the architecture answer different questions — what a person develops, versus how the institution is assembled. Both terminate in outcomes, and that is the join, not a duplication.
• First-time user: nothing member-facing changes except the name of the sixth capability, which is now stated in plainer language than the word it replaces.
• Debt: the Registry's ENG- table does not yet carry a layer column; until it does, the layer is asserted here and in src/lib/codices/architecture.ts. Repaid at the next Registry amendment.

7. Result at review (2027-09-01)

To be written at the review date, whether or not it flatters this decision.