Codex 0 · Chapter 05 — CapabilityOS

This chapter specifies the engine model of CapabilityOS and, in full, each of the eleven engines ENG-01 through ENG-11.

05.0 Purpose

CapabilityOS is the single operating system that records, sequences, and supports the development of human capability across every division of Anabasis. It exists so that no division builds a second version of a capability another division already owns, and so that a person's capability record is the same record regardless of which division touched it last. This chapter binds the engine architecture named in Codex 3 §"Architectural rule" and Codex 0 §5 to concrete, citable rules, and gives each engine a full treatment: purpose, ownership, inputs, outputs, exclusive state, interfaces, dependencies, invariants, limits, prohibitions, and status.

05.1 Scope and non-scope

05.1.1 This chapter governs the eleven engines registered as ENG-01 through ENG-11, their ownership, their communication rules, and the conditions under which a twelfth engine may be created.

05.1.2 This chapter does not define the knowledge graph's internal node and edge model (Chapter 06), the canonical entity definitions engines operate on (Chapter 07), or the permission model that gates engine access (Chapter 08). It references those chapters rather than restating them.

05.1.3 This chapter does not define dashboards or agents as systems in their own right; Codex 3 and the registry (DASH-, AGT-) govern those. Where an engine feeds a dashboard or agent, this chapter names the dependency only.

05.1.4 Status claims in this chapter are binding. Where a status says "reserved," no implementation exists and none may be represented as existing in any surface, dashboard copy, or public claim.

05.2 What an engine is

05.2 Definition and properties

05.2.1 An engine is a bounded unit of CapabilityOS with a single owning division, a declared set of inputs it may consume, a declared set of outputs it may produce, and a body of state it alone may write.

05.2.2 An engine's state is private. No other engine, division, dashboard, tool, or agent reads or writes an engine's storage directly. All access happens through the engine's declared interface.

05.2.3 An engine's interface is a contract, not an implementation detail. Changing an interface follows the contract rules of Codex 5 (versioning, migration window, decision record) as elaborated in Chapter 07.

05.2.4 An engine has exactly one owning division (Codex 0 §2, "rule against duplication"). Ownership assigns accountability for the engine's correctness, availability, and evolution; it does not grant other divisions reduced access relative to their declared permissions.

05.2.5 An engine is defined by what it is responsible for deciding or recording, not by the surface that displays its output. A dashboard question ("what is next for me") may draw on several engines; the engine that actually holds the sequencing logic is the Adaptive engine, not the dashboard.

05.3 How engines communicate

05.3.1 Engines communicate only through declared interfaces: typed function calls for internal server-to-server calls, or published API boundaries (Codex 5, Chapter 07 §07.9) for surfaces external to the runtime.

05.3.2 An engine may declare another engine as a dependency ("consumes"). A dependency is one-directional and named explicitly in this chapter's per-engine tables. Circular dependency between two engines is prohibited; where two engines appear to need each other, the shared responsibility is factored into a third engine or into the knowledge graph.

05.3.3 An engine never queries another engine's database tables, materialized views, or caches directly, including through service-role credentials. Cross-engine reads happen through the producing engine's interface so that the producing engine retains control of what it exposes and can evolve its internal representation without breaking consumers.

05.3.4 Engine-to-engine calls are subject to the same server-side authorization as any other call: the caller's role and scope are checked, not merely its identity.

05.3.5 Where an engine needs data from a division that is not itself an engine (for example, financial ledger data owned outside CapabilityOS), it consumes that data through a declared API boundary, never a direct table reference.

05.4 When a new engine may be created

05.4.1 A new engine is created only when no existing engine can absorb the responsibility without violating its own single-responsibility purpose (§05.2.1) or its declared inputs and outputs.

05.4.2 A proposal for a new engine answers the eight-question record of Codex 0 §16 and additionally states: which existing engine was considered and rejected as the home for this responsibility, and why.

05.4.3 A new engine is assigned a permanent registry ID (ENG-12 and upward) before any code exists for it. The ID and its reserved status are recorded in the registry before the engine is built.

05.4.4 A new engine's owning division is exactly one division, chosen per Codex 0 §2's rule against duplication: if the responsibility is genuinely shared, it belongs to Technology (DIV-05).

05.4.5 The engine interface pattern (§05.2, §05.3) applies identically to any future engine; there is no abbreviated path for a "small" engine.

05.5 Degradation rules

05.5.1 CapabilityOS is designed so that the failure of a peripheral engine never takes down the core (Codex 7, "Reliability"). The core, for the purpose of this rule, is Knowledge Graph (ENG-01) plus whichever engine directly serves the surface the person is using.

05.5.2 An engine that depends on another engine which is unavailable degrades to its next-best behaviour rather than failing the whole request. Next-best behaviour is declared per engine in this chapter's "Limits" clauses; where none is declared, the safe default is to omit the dependent feature and say so, not to guess.

05.5.3 An engine never silently substitutes stale data for unavailable data without marking it as stale to the caller and, where the caller is a person-facing surface, to the person.

05.5.4 Loss of an engine's state store is a consequential event and produces an AuditRecord (ENT-19) and an incident record. No engine treats data loss as routine.

05.5.5 An engine that cannot verify a caller's authorization because an upstream identity check is unavailable fails closed: it denies the request rather than granting it.

05.6 The eleven engines

The following sections treat each engine in full. Each follows the same structure: purpose, owning division, inputs, outputs, exclusive state, interfaces exposed, engines consumed, invariants, limits, prohibitions, and status. Status values follow Codex 0 Part II: built, partial, reserved.

05.6.1 ENG-01 — Knowledge Graph

Purpose. The connective tissue of the institution: the single linked model of capabilities, curriculum, publications, sources, and the demonstrated ability of people, that every other engine and agent reads to answer "what does this concept connect to, and what does the evidence say."

Owning division. Technology (DIV-05).

Inputs. Published curriculum (ENT-09), assessments (ENT-07), publications (ENT-13), the capability taxonomy (ENT-06) maintained by Research Institute, and evidence artifacts (ENT-17) attached to capability claims.

Outputs. Graph nodes and edges (Chapter 06 defines the schema); query results answering adaptive sequencing, tutor grounding, research linkage, and credential meaning queries (Chapter 06 §06.6).

State it owns exclusively. The node and edge store; node/edge versions and provenance records; the capability taxonomy's structural representation (levels and prerequisite edges), though the taxonomy's content is authored by Research Institute.

Interfaces it exposes. Read: node lookup, edge traversal, capability-to-evidence resolution. Write: node/edge creation and versioning, restricted to the producing systems named in Chapter 06 §06.3 (curriculum authoring, editorial pipeline, assessment pipeline). Published externally as API-09.

Engines it consumes. None. Knowledge Graph is upstream of every other engine and consumes only canonical entities and their producing workflows, never another engine's private state.

05.6.1.1 The graph never stores a private copy of an entity's fields; it stores references to canonical entities (Chapter 07) plus the relationships between them.

05.6.1.2 Every edge carries provenance: what produced it, when, and what evidence supports it (Chapter 06 §06.4).

Limits. The graph does not perform sequencing logic itself (that is ENG-03's responsibility); it answers "what is connected to what," not "what should this person do next."

Must never. Store a node for a person's private engagement material, a member's unpublished personal content, or anything not fit to be linked institution-wide (Chapter 06 §06.8). Never allow a write path that bypasses provenance recording.

Status. Reserved. The seam (API-09) and the schema (Chapter 06) are defined; no graph store is implemented.

05.6.2 ENG-02 — Learning

Purpose. Delivers curriculum to a scholar and records what was completed and submitted.

Owning division. Academy (DIV-01).

Inputs. Curriculum units and their structure (ENT-09), a scholar's enrolment (ENT-10).

Outputs. Progress records (ENT-07 precursors: completion state), submitted artifacts (ENT-17), lesson completion events (ENT-18).

State it owns exclusively. Per-enrolment progress state: which units are unlocked, attempted, and completed, and submission history.

Interfaces it exposes. Read: a scholar's own progress and path; write: lesson completion, artifact submission. Published as part of API-03 (Curriculum) and API-04 (Progress & Assessment).

Engines it consumes. None currently (curriculum is code-defined, per registry ENT-09 status "built (as code data)"). When ENG-01 is built, Learning will consume it to resolve which capabilities a unit teaches.

05.6.2.1 Learning records completion honestly: a unit is marked complete only when the scholar has actually submitted or performed the required action, never on time elapsed or page views (Codex 1 Article V).

05.6.2.2 Learning does not itself decide what a scholar should do next across the whole curriculum tree; sequencing recommendation beyond declared prerequisites is ENG-03's responsibility.

05.6.2.3 Progress state is additive history, not an overwritten single value (Chapter 07 §07.10): re-attempting an assessment produces a new record, it does not erase the prior one.

Limits. Learning enforces declared prerequisite gating from the curriculum hierarchy; it does not yet perform capability-based adaptive gating (reserved for ENG-03).

Must never. Soften or auto-pass an assessment to raise completion figures (Codex 1 Article VI.7). Never expose one scholar's submission to another without a reviewer role grant.

Status. Partial. Curriculum delivery and lesson completion exist (SURF-11, SURF-16/17); assessment recording, review integration, and credential emission (the rest of WF-01) are not yet built.

05.6.3 ENG-03 — Adaptive

Purpose. Recommends the next unit, practice, or review a person should undertake based on demonstrated capability rather than curriculum position alone.

Owning division. Technology (DIV-05), serving Academy's delivery surfaces.

Inputs. Assessment history (ENT-07), goals (from ENG-04), and the knowledge graph (ENG-01) for prerequisite and capability-adjacency structure.

Outputs. Ranked recommendations for a person's next action, surfaced to DASH-01 (Personal) and DASH-02 (Scholar), and consumed by the Tutor Agent (AGT-02).

State it owns exclusively. Recommendation state: current recommendation set per person, its inputs at time of computation, and its expiry.

Interfaces it exposes. Read: "what should this person do next," with the evidence basis for the recommendation, satisfying the explainability requirement of Codex 1 Article VI.4.

Engines it consumes. ENG-01 (Knowledge Graph), ENG-02 (Learning, for completion state), ENG-04 (Goal, where a goal narrows the recommendation).

05.6.3.1 Every recommendation states its basis (which demonstrated capabilities and which graph edges produced it) so a person, faculty member, or auditor can see why it was made.

05.6.3.2 A recommendation is advisory. It never auto-enrols, auto-assigns, or otherwise changes a person's standing without the person's action.

05.6.3.3 Recommendation computation degrades gracefully: if ENG-01 is unavailable, Adaptive falls back to declared curriculum prerequisites from ENG-02 and marks the recommendation as "structural only," not capability-based.

Limits. Adaptive does not itself decide credentialing or advancement; it recommends. It does not model long-horizon goals; that is ENG-04.

Must never. Optimize for engagement, session length, or completion speed (Codex 1 Article V). Never hide the basis of a recommendation.

Status. Reserved.

05.6.4 ENG-04 — Goal

Purpose. Holds a person's long-horizon objectives and their decomposition into milestones and dependent capabilities.

Owning division. Technology (DIV-05).

Inputs. Person-stated intent; capability model from ENG-01.

Outputs. Goals and milestones, consumed by ENG-03 (to narrow recommendations), ENG-05 (to anchor practice), ENG-06 (to ground decisions), and DASH-01.

State it owns exclusively. Goal records: statement, target capability set, milestones, target dates, and status (active, achieved, abandoned, revised).

Interfaces it exposes. Create, read, update, and archive a person's own goals; read access for a mentor where a mentoring relationship grants it (Codex 4).

Engines it consumes. ENG-01, for resolving a goal's target into concrete capabilities.

05.6.4.1 A goal belongs to exactly one person. It is never a shared or organizational object; organizational objectives are a separate future concern (not modelled by this engine).

05.6.4.2 Goal state changes (revision, abandonment) are retained as history, not deleted, so a person's own record of intent over time is preserved.

Limits. Goal does not enforce practice cadence (ENG-05) or make decisions (ENG-06); it only states and decomposes intent.

Must never. Set or imply a goal on a person's behalf without their input. Never surface a goal to anyone but the person and an explicitly permitted mentor.

Status. Reserved.

05.6.5 ENG-05 — Habit

Purpose. Supports sustained practice cadence toward a goal, without manipulation.

Owning division. Technology (DIV-05).

Inputs. Goals (ENG-04), recorded activity events (ENT-18).

Outputs. Practice records; cadence state (on track, lapsed, resumed) surfaced to DASH-01.

State it owns exclusively. Per-person, per-goal practice cadence history.

Interfaces it exposes. Read a person's own cadence and history; record a practice event.

Engines it consumes. ENG-04.

05.6.5.1 Habit tracks cadence to support the person's stated goal; it never manufactures urgency, streak pressure, or loss-aversion prompts (Codex 1 Article VI.1).

05.6.5.2 A lapse in cadence is recorded factually and without punitive framing; resuming practice is never gated behind a "streak reset" mechanic.

Limits. Habit does not evaluate the quality of practice, only its occurrence; quality assessment belongs to ENG-02 or ENG-09 depending on domain.

Must never. Send notifications engineered to exploit variable-reward psychology. Never rank people against each other on cadence.

Status. Reserved.

05.6.6 ENG-06 — Decision

Purpose. Structures consequential personal or institutional decisions and records the reasoning behind them, so a decision can be reviewed later against what was known at the time.

Owning division. Technology (DIV-05).

Inputs. Goals (ENG-04), relevant evidence (financial projections from ENG-07, business diagnostics from ENG-08, engagement context from ENG-10).

Outputs. Decision records: the question, options considered, evidence used, the choice made, and by whom.

State it owns exclusively. The decision record store, one record per structured decision.

Interfaces it exposes. Create a decision record; read a person's or organization's own decision history (subject to role scope).

Engines it consumes. ENG-04, ENG-07, ENG-08, ENG-10, as relevant to the decision's domain.

05.6.6.1 A decision record is immutable once finalized; a later change of mind produces a new, linked decision record rather than editing history (mirroring AuditRecord doctrine, Chapter 07 §07.4).

05.6.6.2 Decision records used to satisfy Codex 1 Article VI.3 (human oversight preserved) must show a named human as the decision-maker, not an agent.

Limits. Decision does not make the decision; it structures the record of one already made or being made by a person.

Must never. Present an AI agent's suggestion as the recorded decision-maker. Never retroactively alter a finalized record.

Status. Reserved.

05.6.7 ENG-07 — Financial

Purpose. Models personal and institutional financial capability: projections, scenarios, and readiness relevant to a person's or the institution's goals.

Owning division. Technology (DIV-05), serving Executive Office and, for personal use, Members.

Inputs. Financial inputs volunteered by the person or organization; institutional financial results (from Codex 8's reporting, out of CapabilityOS scope but read as an input where published).

Outputs. Models and projections, consumed by ENG-06 and DASH-01/DASH-09.

State it owns exclusively. Scenario and projection state per person or per institutional planning cycle.

Interfaces it exposes. Create and read a person's own financial scenarios; institutional projections restricted to Executive Office role scope.

Engines it consumes. None directly; consumes canonical entities and externally supplied financial data.

05.6.7.1 Personal financial data is member data under Codex 1 Article VI.2: never sold, rented, or brokered.

05.6.7.2 A projection states its assumptions explicitly; it is never presented as a guarantee.

Limits. Financial does not execute transactions or move capital; it models and projects only.

Must never. Give financial advice framed as a completed decision — Codex 1 Article VI.3 requires the person to decide.

Status. Reserved.

05.6.8 ENG-08 — Business

Purpose. Models enterprise operations and produces organizational capability diagnostics for enterprise clients and ventures.

Owning division. Technology (DIV-05), serving Advisory and Ventures.

Inputs. Organization data (ENT-03) supplied under an engagement (ENT-12) or venture relationship (ENT-15).

Outputs. Diagnostics consumed by WF-05 (enterprise cohort formation) and ENG-11 (venture milestones).

State it owns exclusively. Per-organization diagnostic state and its versions over time.

Interfaces it exposes. Read/write restricted to the organization's own authorized users and the advisors or program staff engaged with it.

Engines it consumes. None directly.

05.6.8.1 A diagnostic is scoped to exactly the organization that supplied the data; it is never pooled across organizations without explicit, documented anonymization (Chapter 07 §07.11).

05.6.8.2 Diagnostic history is retained additively so an organization can see its own capability movement over time.

Limits. Business does not itself decide program design or investment readiness; those are workflow decisions (WF-04, WF-05) that consume its output.

Must never. Share one organization's diagnostic with another organization, even anonymized, without the disclosed derivation rules of Chapter 07 §07.11.

Status. Reserved.

05.6.9 ENG-09 — Research

Purpose. Manages the research pipeline: methodology, sources, drafts, and the versioned indexes the institution publishes.

Owning division. Research Institute (DIV-03).

Inputs. Registered research questions, gathered sources, draft manuscripts, editorial decisions.

Outputs. Publications (ENT-13), Index values (ENT-14), and capability taxonomy proposals feeding ENG-01.

State it owns exclusively. Draft and methodology state prior to publication; the authoritative index computation history.

Interfaces it exposes. Editorial pipeline operations (draft, review, approve, publish); public read of published output via API-07.

Engines it consumes. None directly; consumes source material and outcome data fed anonymously from Advisory and Ventures per Codex 0 §2's cross-division flows.

05.6.9.1 A publication is never issued without a registered methodology and disclosed sources (Codex 1 Article VI.8).

05.6.9.2 An index value, once published, is never silently revised; a correction is a new versioned value with a stated reason (Chapter 07 §07.10).

Limits. Research does not itself decide curriculum content; it produces findings that Academy's curriculum authoring consumes through WF-03.

Must never. Publish a claim of certification, compliance, or audit outcome without documented evidence (Codex 1 Article VI.8).

Status. Reserved. Publications currently exist as code-authored content (ENT-13 status "built (as code data)"), not as pipeline-managed output.

05.6.10 ENG-10 — Advisory

Purpose. Manages the engagement lifecycle: staffing, delivery, commitments, and risk tracking for advisory relationships with organizations and executives.

Owning division. Advisory (DIV-02).

Inputs. Engagement records (ENT-12), advisor availability and credentials (via API-05).

Outputs. Engagement state, delivery records, and anonymized case contributions feeding ENG-09 and Academy's teaching material.

State it owns exclusively. Per-engagement commitment, risk, and delivery state.

Interfaces it exposes. Advisor-facing engagement management; enterprise-facing engagement status within agreed scope. Published as API-06.

Engines it consumes. None directly; reads credentials via API-05 to determine advisor eligibility.

05.6.10.1 Advisor eligibility for a given engagement is derived from credentials and role grants, never assigned by convenience outside that check (Codex 4 separation-of-duties principle, restated Chapter 08 §08.6).

05.6.10.2 An engagement's risk and commitment log is retained for the life of the relationship and beyond, to support Codex 1 Article VI.6 (auditability of consequential action).

Limits. Advisory does not itself produce the anonymization of case data; that follows the derived-dataset rule of Chapter 07 §07.11 before reaching Research.

Must never. Expose one client's engagement detail to another client or to an unassigned advisor.

Status. Reserved.

05.6.11 ENG-11 — Venture

Purpose. Manages venture stage progression, milestones, and capital relationships for founders moving through incubation, acceleration, or the studio.

Owning division. Ventures (DIV-04).

Inputs. Venture records (ENT-15), founder milestone submissions, business diagnostics from ENG-08.

Outputs. Updated venture stage and milestone state, investment records (ENT-16), and investor reporting.

State it owns exclusively. Per-venture stage, milestone, and readiness state.

Interfaces it exposes. Founder-facing venture and milestone management; investor-facing reporting within agreed scope. Published as API-08.

Engines it consumes. ENG-08, for business diagnostics informing readiness review.

05.6.11.1 A venture's stage advances only on recorded milestone evidence, never on elapsed time alone.

05.6.11.2 Investor reporting reflects the same underlying milestone and diagnostic records a founder sees; it is not a separately curated narrative (Codex 1 Article VI.7 spirit extended to venture reporting integrity).

Limits. Venture does not itself execute capital transfer; it records the investment relationship and its terms as reported to it.

Must never. Share one founder's venture detail with another founder or with an investor not party to that venture.

Status. Reserved.

05.7 Interfaces

05.7.1 Every engine's interface is published in the registry (ENG- entries) with its consumes/produces pair stated in canonical entity or engine-output terms, never in implementation terms (table names, function names).

05.7.2 Where an engine's interface is consumed by a division outside its own, that consumption happens through the API boundary layer (Chapter 07 §07.9), not through a special-cased internal call that bypasses the boundary's validation and authorization.

05.7.3 An engine interface change that is not backwards-compatible follows Codex 5's contract rule: version, migration window, decision record.

05.8 Invariants

05.8.1 Exactly one owning division per engine, permanently recorded in the registry.

05.8.2 No engine reads or writes another engine's private state directly.

05.8.3 Every recommendation, decision, or diagnostic an engine produces states the evidence basis behind it where a person or auditor could reasonably ask "why."

05.8.4 History inside an engine is additive; overwritten state is prohibited wherever the state represents a judgment, assessment, or measurement (Chapter 07 §07.10).

05.8.5 An engine fails closed on authorization uncertainty (§05.5.5).

05.9 Prohibitions

05.9.1 No engine optimizes for engagement, attention, or session metrics (Codex 1 Article V).

05.9.2 No engine trains a model on member data without explicit, revocable, purpose-specific consent (Codex 3, agent rules, extended here to engines that incorporate learned models).

05.9.3 No engine is forked by a division other than its owner to create a local, divergent copy.

05.9.4 No engine bypasses the knowledge graph's provenance requirement when the engine's output is itself later treated as evidence (for example, an Adaptive recommendation is never fed back into the graph as if it were demonstrated capability).

05.9.5 No engine ships a public table or state store without the grants and row-level policy required by Chapter 07 §07.12 in the same migration that creates it.

05.10 Open questions

05.10.1 Whether Goal (ENG-04) should support organizational, not only personal, goals — currently out of scope pending a decision record.

05.10.2 Whether Decision (ENG-06) should be mandatory in specific workflows (for example, all engagement-ending decisions) or remain optional tooling — reserved for Codex 9 review once ENG-10 is built.

05.10.3 The precise boundary between Adaptive (ENG-03) recommendation and Tutor Agent (AGT-02) explanation — both touch "what next," and the seam needs a decision record once both move past reserved status.

05.10.4 Whether Business (ENG-08) diagnostics should ever contribute to a cross-organization anonymized index published by Research — currently prohibited by §05.9's silo rule absent a documented derivation path.

05.11 Governing Codices

Codex 1 (Constitution, Articles V and VI); Codex 0 §5 and §16; Codex 3 (engine and agent doctrine); Codex 5 (data and API contract rules); Codex 7 (engineering doctrine); Chapter 06 (Knowledge Graph detail); Chapter 07 (data model detail); Chapter 08 (permissions detail).