Terminology

The terms below are defined once and used consistently throughout this Specification.

• Acceptance Criteria: the checkable statements that define "done" for a unit.
• AI Agent: an Executor that is an AI system rather than a human.
• Baseline: an approved, frozen snapshot of the description of the System or of its Realization, at a defined level.
• Baseline Ledger: the register that records every approved Baseline: the artifacts it governs, its snapshot identifier, its status, and the named human who accepted the lock (§9.1).
• Blast Radius: the set of System elements that a given change or failure can affect.
• Capability: a function the System delivers to its users or operators. A Capability may span several Components.
• Component: a bounded unit of responsibility with explicit interfaces, Contracts, and Acceptance Criteria.
• Component Specification: the normative document that defines one Component (Rationale, Required Behaviors, Acceptance Criteria, Constraints, Dependencies & Interfaces, plus its private Design).
• Constraint: an Obligation that limits how a need may be met rather than stating what must be achieved.
• Contract: the human-approved part of a Specification that other Components may rely on. It primarily contains the Obligations, interfaces, Invariants, and Acceptance Criteria.
• Criticality Class: the recorded class assigned to a Component or a Capability that determines the Obligations and the verification rigor applying to it.
• Criticality Record: the register that holds the Criticality Class assigned to each Component and Capability, together with the tailoring decisions and rationales that other clauses direct into it (§7.10).
• Decision Record: a numbered, immutable record of one binding decision.
• Design: how a Component satisfies its Contract. Visible only to the Component’s implementer; binds no other Component.
• Deviation Matrix: the register that records every deviation from this Specification, naming what is waived, why, and which named human accepted the risk (§9.4).
• Entity: a class of element required by this Specification, of which a Project holds one or more instances. Appendix A lists every required Entity; the Path Map (§14.8) binds each Entity to concrete storage.
• Entry Point: the single short document that serves as the starting map of the Project Record. Every Executor begins here and is directed from it to the deeper artifacts relevant to their work. It declares the Path Map that binds every required Entity to its concrete location (§14.3, §14.8).
• Exploratory Work Unit: a bounded, time- or resource-capped Work Unit executed in an isolated workspace to investigate candidate questions (feasibility, empirical models, candidate Specifications, etc.). Its completion is defined by meeting declared stopping criteria and producing structured findings recorded in the Project Record, not by modifying the canonical Realization or System description.
• Executor: a human or an AI system performing work under a bounded mandate.
• Gate: a controlled passage between Phases, closed only by a human decision recorded as a Decision Record (§11).
• Governance Document: a human-authored standing directive (principles, rules, instructions, etc.) addressed to Executors.
• Invariant: a property that must always hold and that no Executor may weaken without human authorization.
• Key Design Parameter: one of a small named set of parameters that govern System success.
• Normative Check: a mechanically executable rule that verifies whether Project artifacts comply with a structural requirement of this Specification.
• Obligation: one verifiable requirement statement.
• Operational Concept: the statement of how the System will be operated and sustained.
• Path Map: the deterministic declaration, held in the Entry Point, that binds every required Entity of this Specification to a concrete location pattern and a serialization format (§14.8).
• Phase: a bounded stage of work that produces at least one durable artifact and is entered and left through a Gate.
• Plan Document: the binding document that governs one Work Unit, stating its scope, its Acceptance Criteria, its progress, and the decisions taken under it. It is the artifact an Executor follows in preference to any conversational instruction.
• Production Work Unit: a Work Unit that modifies the canonical Realization or System description under an approved Specification and an approved Plan Document.
• Project: the bounded endeavor that produces and sustains one System, governed by one Project Record.
• Project Record: the versioned set of durable artifacts that constitutes the system of record for the Project.
• Realization: the actual built System or Component, as distinct from its description.
• Reference Realization: a maintained instance that embodies the current interpretation of a Contract, against which the governed element is compared to detect drift (§7.17). Distinct from a Verification Reference State.
• Registry: the machine-readable index of every Component and content item in the System.
• Risk Register: the register that records every identified risk with its owner, analysis, mitigation plan, tracking method, and closure (§12.1).
• Specification: the normative description of a Component or an effort. It consists of the Contract plus the Design.
• Stability Class: the classification of an element by expected rate of change. Dependencies must point only toward elements of equal or higher Stability Class.
• Status Ledger: the register that records the status and history of every change, deviation, waiver, and audit outcome (§9.3).
• Subsystem: a Component that is also a System at a lower level of decomposition. It contains interacting Components and must satisfy the Contract of its containing System.
• System: the engineered artifact under construction, in any domain.
• Verification Artifact: the durable record that an Acceptance Criterion was checked, including the outcome.
• Verification Plan: the governing document that fixes the scope, responsibilities, resources, and completion criteria of verification for the Project.
• Verification Procedure: a concrete procedure that can be executed to determine whether one or more Acceptance Criteria are satisfied. The durable record of running a Verification Procedure is a Verification Artifact.
• Verification Reference State: the recorded outcome of executing whatever verification exists immediately before a change begins, used as the comparison point for that change. Distinct from a Baseline (§9.1).
• Vision Document: the human-authored statement of the System's purpose, problem, desired future state, and long-term goals.
• Work Record: the single structured, queryable artifact that records every Work Unit, any typed relations between Work Units, and the discoveries made during their execution.
• Work Unit: a bounded unit of work with declared scope, an assigned Executor, and Acceptance Criteria.