Codex 0 · Chapter 19 — Glossary
Chapter 19 of the institutional specification.
- Authority rank
- 2
- Version
- v2.0
- Adopted
- unrecorded
- Held by
- Stewardship Office
- System
- SYS-10
Source · docs/codices/CODEX-0/19-glossary.md · registered by rule
The controlled vocabulary of this specification book: one definition per normative term, alphabetical, cited by chapter and clause.
19.0 Purpose
19.0.1 This glossary fixes the meaning of terms used normatively across Chapters 1–18 so that a clause can be written once and cited precisely thereafter.
19.0.2 This glossary is internal doctrine vocabulary, maintained for the people who write and interpret the Codices. It is distinct from SURF-06, the public glossary surface (/glossary), which is a member- and public-facing reading experience governed by Codex 6 and Codex 3's capability taxonomy. Where the two differ in emphasis, this glossary governs internal specification writing and SURF-06 governs what the public reads; neither overrides the other's audience.
19.1 Scope and non-scope
19.1.1 In scope: every term used normatively (as a defined, load-bearing word rather than plain English) anywhere in this book, with its point of definition and its likely confusion.
19.1.2 Out of scope: terms defined and used only within a single chapter and not referenced elsewhere; these are defined in place and not duplicated here. Financial, legal, and governance vocabulary specific to Codex 8 and Codex 9 is glossed there and only cross-referenced here where it also appears in Chapters 17–19.
19.2 Entries
Agent — A bounded AI system with a declared scope, permitted data set, required human checkpoint, and explainability obligation (Codex 0 §10, Codex 0-REGISTRY §6). Specified in Codex 0 §10 and Chapter 18 §18.5.3. Not to be confused with Engine: an engine is a deterministic capability module; an agent may use one or more engines but is never itself the system of record.
Artifact — A canonical entity (ENT-17) representing a person's submitted work product within a workflow (an assignment, a case, a defence submission). Specified in Codex 0 §7, §6 (workflow emissions). Not to be confused with Credential, which is the institution's issued attestation about an artifact's outcome, not the work itself.
Audit record / AuditRecord — The canonical entity (ENT-19) produced by every consequential action, carrying actor, subject, time, and reason, additive and immutable. Specified in Codex 1 Article VI.6; Chapter 17 §17.9. Not to be confused with a structured log (§17.9.1), which is operational and may be rotated or discarded; an audit record never is.
Boundary — A declared, stabilised interface (an API- entry) through which systems and third parties interact with institutional data; the only sanctioned path in or out. Specified in Codex 0 §11; Chapter 17 §17.5, §17.15. Not to be confused with Surface (a user-facing route) or Module boundary (an internal engineering separation, §17.3), though all three share the word "boundary."
Capability — A canonical entity (ENT-06) naming a discrete, demonstrable ability within the taxonomy the Research Institute maintains. Specified in Codex 0 §7, §5 (ENG-01 consumes it); Codex 3. Not to be confused with Credential (an issued attestation of demonstrated capability) or institutional capability (the eight strengths of Codex 1, Article IV), a different, higher-order sense of the same word.
Clause — A single numbered normative statement within a Codex 0 chapter, of the form NN.n.n, permanently citable. Specified in the system prompt governing this book's structure; exercised throughout Chapters 17–18. Not to be confused with a section (NN.n), which groups clauses under one heading.
Cohort — A canonical entity (ENT-11) grouping enrolled people for shared delivery, typically tied to an Organization. Specified in Codex 0 §6 (WF-05), §7. Not to be confused with Membership (an individual's standing relationship to the institution or an Organization), which a cohort does not replace.
Credential — A canonical entity (ENT-08) issued by the institution attesting that a person has demonstrated a capability to a stated standard, verifiable permanently through API-05. Specified in Codex 1 Article VI.7; Codex 0 §7, §11; Chapter 18 §18.6. Not to be confused with Capability (the thing demonstrated) or CapabilityAssessment (ENT-07, the record of the specific evaluation that led to the credential).
Debt (technical) — A deliberate, named tradeoff of long-term architecture for short-term delivery, permitted only when the trade, the reason, and the repayment condition are recorded. Specified in Codex 1 Article VII; Codex 7; Chapter 17 §17.14. Not to be confused with unnamed shortcuts, which this book classifies as defects, not debt.
Division — One of the institution's operating units, exactly one owner per registry entry (DIV-). Specified in Codex 0 §2, §3; Codex 2. Not to be confused with Office (Executive Office, Stewardship Office), which governs and directs divisions but does not itself deliver a division's product.
Elevation (elevated access) — A temporary, logged, reason-bearing grant of access to member content beyond a person's ordinary scope. Specified in Codex 0 §8; Chapter 17 §17.6.4. Not to be confused with a Role (a standing grant) or Membership (a standing relationship); elevation is always temporary and always audited.
Engagement — A canonical entity (ENT-12) representing an Advisory division relationship with an Organization or executive, from staffing through outcome. Specified in Codex 0 §6 (WF-02), §7; ENG-10. Not to be confused with engagement in the ordinary sense of member attention or activity — a sense this book explicitly rejects as an optimization target (Codex 1 Article V; Codex 6, "the acceptance test").
Engine — One of the eleven bounded, deterministic capability modules of CapabilityOS (ENG-), each with a declared interface, consumed by every division and forked by none. Specified in Codex 0 §5; Codex 3; Chapter 17 §17.3. Not to be confused with Agent, a non-deterministic AI system that may call one or more engines.
Entity — A canonical, normalized data object (ENT-) representing one real-world thing, with exactly one owning division and one row per real-world instance. Specified in Codex 0 §7; Codex 5. Not to be confused with a record in the general database sense; an entity is the type, a record is one instance of it.
Grant (role grant) — A row establishing that a specific Person holds a specific Role at a specific scope. Specified in Codex 0 §4, §8; Codex 4. Not to be confused with a database grant (a storage-layer permission on a table), though Chapter 17 §17.6 requires both to exist together and to agree.
Index — A canonical entity (ENT-14) representing a versioned, methodology-published measurement series produced by the Research Institute. Specified in Codex 0 §7, §14; Chapter 18 §18.8.3. Not to be confused with a database index (a storage-layer performance structure), an unrelated engineering term that also appears in Chapter 17.
Layer — One of the four architectural strata (presentation, application, domain, data) that every implemented system separates into. Specified in Chapter 17 §17.2. Not to be confused with Division or Office, which are organizational, not architectural, strata.
Membership — A canonical entity (ENT-04) representing a Person's standing relationship to the institution or to an Organization, from which Role grants and dashboard access derive. Specified in Codex 0 §4, §7; Codex 4. Not to be confused with a Role (what the membership permits) or an Engagement (a bounded relationship with a defined scope of work).
Module — A capability implemented with a declared interface and internal replaceability, used generically across engines, API boundaries, and tools. Specified in Chapter 17 §17.3. Not to be confused with a Layer; a module can span or sit within a single layer.
Person — The single canonical entity (ENT-01) representing one real human being, held for life, never duplicated to add a role. Specified in Codex 0 §1, §4, §7; Chapter 18 §18.2.1. Not to be confused with an Identity (ENT-02, the authentication credential(s) a Person uses to prove who they are) or a Membership (a Person's relationship to a specific context).
Provenance — The recorded origin of a piece of data or an assertion (which engine, agent, or person produced it, and when). Specified in Chapter 18 §18.7.4 (graph edges); implied throughout audit obligations (Chapter 17 §17.9). Not to be confused with Audit record, which records an action taken; provenance records where a piece of data came from, whether or not any consequential action was taken with it.
Registry entry — One row in Codex 0-REGISTRY, uniquely identified by a permanent ID, answering the eight-question record and carrying a status. Specified in Codex 0 §16; Codex 0-REGISTRY. Not to be confused with a Codex chapter, which is doctrine; a registry entry is the enumerated inventory doctrine governs.
Reserved / partial / built — The three statuses a registry entry may carry: reserved (name and seam defined, nothing implemented), partial (implemented in part, named gaps remain), built (implemented and in service). Specified in Codex 0-REGISTRY. Not to be confused with informal language like "coming soon" or "in progress," which this book does not use; only these three words carry status meaning.
Role — A row in a dedicated table (never a field on a profile) scoped to individual, cohort, organization, division, or institution, from which permissions derive. Specified in Codex 1 Article VI.5; Codex 0 §4, §8; Codex 4. Not to be confused with Membership (the relationship a role is granted within) or user type (Member, Scholar, Mentor, etc.), which is a descriptive category, not itself an authorization mechanism.
Scope — The boundary within which a Role, a grant, an Agent, or an Engagement operates (an individual, a cohort, an organization, a division, or the whole institution). Specified in Codex 0 §4, §8, §10; Codex 4. Not to be confused with the scope of a chapter's "17.1 Scope and non-scope" section, an unrelated editorial use of the same word confined to this book's own structure.
Status (registry) — See Reserved / partial / built.
Steward / Stewardship Office — The office and the individual role holding custody of the Codices, empowered with a written veto and the amendment record, distinct from day-to-day management. Specified in Codex 0 §3; Codex 9. Not to be confused with the Executive Office, which runs the institution but cannot amend doctrine.
Surface — A user-facing route (SURF-) defined by the question it answers or, if editorial, declared as such; owns no data itself. Specified in Codex 0 §9 (dashboards), Codex 0-REGISTRY §9; Codex 6. Not to be confused with Boundary (API-), the data-layer interface a surface reads through, or Dashboard (DASH-), a specific class of authenticated surface defined by the question it answers.
Workflow — A named, staged cross-division process (WF-) whose every stage names the data it emits. Specified in Codex 0 §6; Codex 0-REGISTRY §4. Not to be confused with a single engine's internal processing, which is not staged across divisions and does not carry a WF- ID.
19.3 Interfaces
19.3.1 A term entered here is citable as "Chapter 19, <Term>" from any other chapter; the entry itself cites the chapter and clause where the term is normatively specified.
19.3.2 Where a term used in Chapters 1–18 is absent from this glossary, its absence is a defect in this chapter, not license to redefine the term informally elsewhere; it is added at the next amendment.
19.4 Invariants
19.4.1 No term in this glossary carries two different normative meanings within this book.
19.4.2 No entry here contradicts its point of definition in the chapter it cites; if the two diverge, the chapter governs and this glossary is corrected.
19.5 Prohibitions
19.5.1 This glossary is not quoted as a public-facing definition of these terms; that function belongs to SURF-06 under Codex 6.
19.5.2 A term is not added here solely because it appears in code (src/) unless it is also used normatively in doctrine.
19.6 Open questions
19.6.1 Whether this glossary should be regenerated in part from Codex 0-REGISTRY IDs automatically, to prevent drift as new entries are added, is deferred to a decision record.
19.7 Governing Codices
19.7.1 Codex 0 (Master Blueprint) and Codex 0-REGISTRY, as the source of every registry-class term.
19.7.2 Codex 6 (Experience Doctrine), for the relationship between this glossary and SURF-06.
19.7.3 Chapters 17 and 18 of this book, whose vocabulary this chapter fixes.