Codex 0 · Chapter 14 — Internal Tooling

This chapter specifies the internal tools staff use to run the institution and binds them to the same API boundaries external surfaces use, so no privileged private path around doctrine ever exists.

14.0 Purpose

14.0.1 Internal tooling is how the institution's own people run curricula, review work, issue credentials, staff engagements, manage ventures, publish research, and audit access. It exists so that operators — Academy staff, editors, advisors, administrators — can do their jobs at scale without ad hoc scripts, direct database access, or a second, undocumented system growing up beside the doctrine-governed one.

14.0.2 This chapter binds eleven internal tools (TOOL-01 through TOOL-11, Codex 0 Part II §8) to the workflows they serve, the API boundaries they use, and the audit obligations they carry.

14.1 Scope and non-scope

14.1.1 In scope: the no-privileged-path rule, the full specification of TOOL-01 through TOOL-11, operator experience rules, and the build-versus-buy rule.

14.1.2 Out of scope: the underlying API boundary contracts (Codex 5), the engines tools call into (Codex 3), and the general engineering standards tools must meet as software (Codex 7). This chapter names which tool does what and through which boundary; those chapters govern the boundary and the code.

14.1.3 Applies to every internal-facing system built or commissioned by any division, regardless of whether it is customer-facing in appearance. A console used only by staff is still bound by this chapter if it reads or writes canonical entities (Codex 5 ENT-).

14.2 The no-privileged-path rule

14.2 Statement

14.2.1 Internal tooling is built on the same API boundaries external surfaces use. A curriculum authoring tool writes curriculum through API-03 exactly as a partner integration would; a credential issuance console writes through API-05 exactly as the public verification surface reads through it. There is no second, unpublished contract that only staff tools may call.

14.2.2 The rule exists for three reasons: it forces every boundary to be correct and complete rather than papered over by an internal shortcut; it means a permission or audit rule enforced at the boundary cannot be silently bypassed by an internal caller; and it means a tool can be rebuilt, replaced, or opened to a partner without discovering hidden coupling to a private path.

14.2.3 A staff operator's elevated capability (e.g., issuing a credential, revoking access) comes from an elevated role and permission, evaluated at the same API boundary a lower-privileged caller hits, never from a tool that talks to the database directly or via a bypass endpoint.

14.2.4 Where a boundary does not yet exist to support a needed tool capability, the boundary is built first (Codex 7 §"API before integration") — the tool does not get a temporary direct path "until the API is ready." A temporary direct path becomes a permanent undocumented liability.

14.2.5 Exception process: none. There is no standing exception to 14.2.1. A proposed exception is a proposal to change this chapter, requiring the amendment procedure of Codex 9, not an engineering judgment call made in the course of a sprint.

14.3 Operator experience rules

14.3 Confirmation and reversibility

14.3.1 Every destructive action available in an internal tool (revoke, delete, unpublish, deactivate, override) requires an explicit confirmation step naming what will change and for whom.

14.3.2 Where technically possible, a destructive action is reversible: a revoked credential can be reinstated with its history intact; an unpublished piece of research can be republished; a deactivated role grant can be restored. Where an action is genuinely irreversible (e.g., permanent deletion of a person's data under a legal erasure request), the tool says so explicitly before the operator confirms, and the action is logged as irreversible in the audit record.

14.3.3 A tool never silently degrades a destructive action into a "soft" one, or vice versa, without the operator being told which behaviour is in effect. Ambiguity between "hidden" and "deleted" is a defect.

14.4 Elevated reads

14.4.1 Every elevated read of member content by an operator — viewing a scholar's assessment history from an admin console, viewing a member's financial inputs to resolve a support ticket, viewing another person's engagement notes to cover a colleague's absence — is logged with a stated reason at the time of the read, not reconstructed after the fact.

14.4.2 The reason is a short, specific string tied to the operator's task ("resolving support ticket #4021"), not a generic placeholder ("review"). A tool that allows an elevated read without requiring a reason field to be populated is non-compliant.

14.4.3 Elevated-read logs feed the Access & Audit Console (TOOL-11) and are reviewable by the subject of the read on request, consistent with the transparency rights of Chapter 16 §16.4.

14.4.4 A pattern of elevated reads inconsistent with an operator's stated role or a spike in elevated-read volume is a trigger for review by TOOL-11's operators, not something the originating tool need itself police beyond correct logging.

14.5 General operator experience standards

14.5.1 An internal tool exposes only the actions its operator's role permits; a control the operator cannot legally use is not shown greyed out with false hope, it is omitted, consistent with server-side enforcement (Codex 1, Article VI.5).

14.5.2 Bulk operations (bulk credential issuance, bulk role grants) require the same per-item confirmation and audit trail as a single operation performed many times — batching for operator convenience never batches away accountability.

14.5.3 Every internal tool meets the same accessibility standard as a public surface (Codex 6) — staff are not a population doctrine exempts.

14.6 Build-versus-buy rule

14.6.1 A third-party tool may be adopted in place of building one of TOOL-01..TOOL-11 only if it can be integrated through the same API boundary rule of §14.2 — meaning the institution's canonical data stays in its own systems of record and the third-party tool consumes and writes through published boundaries, not by becoming a second source of truth.

14.6.2 A third-party tool that requires exporting canonical member data into its own proprietary store, with no path to keep that data suFButubject to the institution's access, audit, and retention rules, is refused regardless of cost or convenience.

14.6.3 Build-versus-buy is a Codex 8 §"feature evaluation" decision (seven axes, Chapter 15 §15.9) like any other system investment: a bought tool still carries maintenance cost (contract, integration, vendor risk) and is evaluated on the same footing as a built one.

14.6.4 Where a bought tool is adopted, the decision and its integration boundary are recorded (Codex 9), and the tool's registry entry (TOOL- ID) states plainly that it is externally sourced and through which API it integrates.

14.7 The eleven tools

Each entry states purpose, operator roles, workflows served, boundaries used, entities written, audit obligations, and status.

14.7 TOOL-01 — Curriculum Authoring

14.7.1 Purpose. Author and version the curriculum hierarchy — school, program, course, module, lesson — as data rather than as hand-edited code.

14.7.2 Operator roles. Faculty, curriculum lead, Academy division staff.

14.7.3 Workflows served. WF-01 (Enrolment to credential), WF-03 (Research to curriculum) as the receiving side of a curriculum revision request.

14.7.4 Boundaries used. API-03 Curriculum.

14.7.5 Entities written. ENT-09 Curriculum, and version history of same.

14.7.6 Audit obligations. Every publish or revision of a live curriculum unit is logged with author, timestamp, and diff summary, because a curriculum change affects every scholar enrolled against it.

14.7.7 Status. Reserved; curriculum is currently authored directly in code, which is a named gap this tool closes.

14.8 TOOL-02 — Assessment & Review Console

14.8.1 Purpose. Conduct peer and faculty review of submitted work, record oral defence outcomes, and route AGT-04 Reviewer first-pass feedback to a human reviewer.

14.8.2 Operator roles. Faculty, peer reviewer, Scholar (submitting side, via SURF-19).

14.8.3 Workflows served. WF-01.

14.8.4 Boundaries used. API-04 Progress & Assessment.

14.8.5 Entities written. ENT-07 CapabilityAssessment, ENT-17 Artifact review state.

14.8.6 Audit obligations. Every recorded assessment names the reviewer, the rubric applied, and whether AI first-pass feedback (AGT-04) was involved, per Chapter 13 §13.15.

14.8.7 Status. Partial.

14.9 TOOL-03 — Credential Issuance

14.9.1 Purpose. Issue, revoke, and support verification of credentials.

14.9.2 Operator roles. Academy administrator, credential authority (a role distinct from the authority to define a credential standard, per Codex 0 §8).

14.9.3 Workflows served. WF-01.

14.9.4 Boundaries used. API-05 Credential & Verification.

14.9.5 Entities written. ENT-08 Credential.

14.9.6 Audit obligations. Issuance and revocation are both logged permanently; a revocation never deletes the historical issuance record, it appends a revocation state, so verification remains truthful about what once existed.

14.9.7 Status. Reserved.

14.10 TOOL-04 — Admissions & Intake

14.10.1 Purpose. Process applications, run capability baselines, and place applicants into programs or venture tracks.

14.10.2 Operator roles. Admissions staff, Academy and Ventures division staff.

14.10.3 Workflows served. WF-01 (intake stage), WF-04 (founder intake stage).

14.10.4 Boundaries used. API-02 Person & Membership, API-04 Progress & Assessment.

14.10.5 Entities written. ENT-01 Person (initial record), ENT-10 Enrolment, baseline assessment records under ENT-07.

14.10.6 Audit obligations. Placement decisions are logged with the baseline evidence relied upon, so a rejected or waitlisted applicant's file can be reviewed on appeal.

14.10.7 Status. Reserved.

14.11 TOOL-05 — Editorial Pipeline

14.11.1 Purpose. Manage drafts, sources, methodology registration, and editorial review through to publication.

14.11.2 Operator roles. Researcher, Editor.

14.11.3 Workflows served. WF-03.

14.11.4 Boundaries used. API-07 Publication & Index.

14.11.5 Entities written. ENT-13 Publication (draft and published states).

14.11.6 Audit obligations. Every publication logs its methodology registration and the editor who approved it, satisfying the provenance obligation carried by AGT-03 outputs (Chapter 13 §13.14).

14.11.7 Status. Reserved.

14.12 TOOL-06 — Index Management

14.12.1 Purpose. Maintain versioned measurement series with published methodology.

14.12.2 Operator roles. Researcher, Research Institute division staff.

14.12.3 Workflows served. WF-03, WF-07 (annual accounting).

14.12.4 Boundaries used. API-07.

14.12.5 Entities written. ENT-14 Index.

14.12.6 Audit obligations. Every new index version is logged with what changed in methodology from the prior version, per Chapter 16 §16.3's correction-procedure requirement.

14.12.7 Status. Reserved.

14.13 TOOL-07 — Engagement Management

14.13.1 Purpose. Staff, deliver, and track advisory engagements, commitments, and risks.

14.13.2 Operator roles. Advisor, Advisory division lead.

14.13.3 Workflows served. WF-02.

14.13.4 Boundaries used. API-06 Engagement.

14.13.5 Entities written. ENT-12 Engagement.

14.13.6 Audit obligations. Commitments made to a client are logged as they are made, so DASH-04's "what have I committed to, and what is at risk" question has an accurate source.

14.13.7 Status. Reserved.

14.14 TOOL-08 — Venture Pipeline

14.14.1 Purpose. Track venture stages, milestones, and investor reporting.

14.14.2 Operator roles. Ventures division staff, Founder (own-venture view).

14.14.3 Workflows served. WF-04.

14.14.4 Boundaries used. API-08 Venture & Capital.

14.14.5 Entities written. ENT-15 Venture, ENT-16 Investment.

14.14.6 Audit obligations. Milestone assessments and investment-readiness reviews are logged with the evaluator and evidence relied upon.

14.14.7 Status. Reserved.

14.15 TOOL-09 — Partner & Enterprise Console

14.15.1 Purpose. Manage partner and enterprise organizations, cohorts, and the agreed reporting scope for each.

14.15.2 Operator roles. Academy and Advisory division staff serving enterprise or partner-institution accounts.

14.15.3 Workflows served. WF-05.

14.15.4 Boundaries used. API-02, API-03, API-10.

14.15.5 Entities written. ENT-03 Organization, ENT-11 Cohort, the agreed reporting-scope record consumed by Chapter 16 §16.5.

14.15.6 Audit obligations. Any change to a partner's agreed reporting scope is logged and requires the counterpart's acknowledgement, since it governs what aggregate data that partner may later see.

14.15.7 Status. Reserved.

14.16 TOOL-10 — Reporting Studio

14.16.1 Purpose. Produce institutional and enterprise reporting: the annual report, capability metrics, indexes, trust metrics, and enterprise-scoped aggregate reports.

14.16.2 Operator roles. Executive Office, Stewardship Office, Technology division reporting staff.

14.16.3 Workflows served. WF-07.

14.16.4 Boundaries used. API-10 Reporting & Analytics.

14.16.5 Entities written. Report artefacts and index-linked publications; reads but does not write most canonical entities.

14.16.6 Audit obligations. Every published report version is retained with the aggregation rules and thresholds applied, so a later correction (Chapter 16 §16.3.4) can be traced to what was known at the time.

14.16.7 Status. Reserved.

14.17 TOOL-11 — Access & Audit Console

14.17.1 Purpose. Manage role grants and review elevated-access activity across every other tool and surface.

14.17.2 Operator roles. Administrator, Stewardship Office (review capacity).

14.17.3 Workflows served. Cuts across all workflows as the audit backstop; not owned by a single WF- stage.

14.17.4 Boundaries used. API-01 Identity & Access, API-11 Audit.

14.17.5 Entities written. ENT-05 Role (grant and revocation), reads ENT-19 AuditRecord.

14.17.6 Audit obligations. This tool is the audit obligation for every other tool: it is where the elevated-read logs required by §14.4 are reviewed, and where a role grant's expiry (Codex 0 §8) is enforced.

14.17.7 Status. Reserved.

14.18 Interfaces

14.18.1 Every TOOL- entry's "boundaries used" column is the authoritative interface list; a tool may not call an API- boundary not listed in its registry entry without a registry update.

14.18.2 Tools that must interoperate (e.g., TOOL-04 Admissions feeding TOOL-01 Curriculum placement) do so through the shared entities each boundary exposes, never through a private handoff between the two tools' internals.

14.19 Invariants

14.19.1 No internal tool has a data path that bypasses a published API boundary.

14.19.2 Every destructive action is confirmed; every reversible action states that it is reversible, and every irreversible one says so before it is taken.

14.19.3 Every elevated read of member content is logged with a stated, specific reason at the time of the read.

14.19.4 A bought tool is subject to the same API-boundary and audit rules as a built one.

14.20 Prohibitions

14.20.1 No tool writes directly to a data store, bypassing the API boundary that governs that entity.

14.20.2 No destructive bulk operation ships without per-item audit records.

14.20.3 No third-party tool becomes a second source of truth for a canonical entity.

14.20.4 No tool exposes a control to an operator whose role does not permit the underlying action, even in a disabled state that reveals its existence in a security-sensitive context.

14.21 Open questions

14.21.1 Which of TOOL-01..TOOL-09 will be built in-house versus adopted per §14.6 is undecided and depends on each owning division reaching partial status on its core workflow.

14.21.2 The mechanism by which TOOL-11 flags anomalous elevated-read patterns (§14.4.4) — threshold-based or model-assisted — is reserved pending a Chapter 13-governed evaluation if AI assistance is proposed for that flagging.

14.22 Governing Codices

14.22.1 Codex 7 (engineering standards tools must meet). Codex 5 (API boundary contracts and entity ownership). Codex 4 (role and permission model tools enforce). Codex 1, Article VI.5–VI.6 (server-side enforcement, auditability). Chapter 15 of this Codex (build-versus-buy as a feature-evaluation instance). Chapter 16 of this Codex (Reporting Studio's outputs).