Component Specifications and Contracts

6.1 Component Specifications #

The Project must maintain a set of atomic Component Specifications: one Component Specification per Component, each a discrete, separately addressable artifact of the Project Record. Each Component Specification defines one coherent unit of responsibility. These are the primary documents that humans and AI Agents implement against. If a Component grows too large to keep its Required Behaviors and Acceptance Criteria consistent, it must be decomposed further. Component Specifications are written in System terms. User-story language is never the primary framing; it may appear only as optional context inside the Rationale section of a truly end-user-facing Component. [COD; SaC]

6.2 Required sections, linted #

Every Component Specification must contain these sections, checked by Normative Checks (§16):

• Rationale: why this Component must exist. May contain one to a few short user-story statements if the Component is end-user facing.
• Required Behaviors: precise description of what the Component must do, in System terms.
• Acceptance Criteria: testable conditions that define "done".
• Constraints: hard limits (performance, safety, resources, etc.).
• Dependencies & Interfaces: explicit declaration of relationships: the Components or interfaces this one requires; the interfaces or Contracts this one provides; and any containment ("part of") relationship.

[COD; SaC; VFE]

6.3 Public Contract, private Design #

Each Component Specification splits into a public Contract and a private Design. The Contract comprises the five required sections listed in §6.2 and is visible to the Executors of every Component that has a declared interface or dependency relationship with it. The Design is visible only to the Executor(s) implementing that Component. Every other Component must rely on the Contract alone. An Executor working on a Component must receive that Component's full Specification and the Contracts of the Components with which it has declared interface or dependency relationships, not the whole System description. [GP-27]

6.4 The Specification is the durable alignment artifact #

The Realization is derived from and governed by the Specification. Where a Realization can be regenerated, it must be regenerated from the Specification rather than edited independently; where it cannot, the Specification remains the governing description and any divergence between the two is a defect in the Realization. Alignment, discussion, and versioning must occur at the Specification level. Specifications must be human-readable, versioned, maintained with a changelog, and open to contribution from any relevant discipline. [GP-19; SaC]

6.5 Obligation statements #

Obligations in Required Behaviors and Constraints must be expressed as unique, quantitative, verifiable statements. Each statement must name exactly one commitment in a fixed structure: the condition under which it holds, the subject that must act, the action, the object, and the constraint on the action. Ambiguous or compound statements must be rewritten until each statement is independently checkable. [GP-20; GP-21]

6.6 Obligation attributes #

Every Obligation must carry fixed attributes: identifier, owner, type, priority, source, rationale, status, and verification method. Obligations are organized in levels that mirror the decomposition: from the expectations of the parties the System serves (customers, users, regulators, etc.), through the Operational Concept (§6.17), down to Component Obligations. The type of an Obligation (what it constrains) governs which verification method is admissible for it. Attribute rigor scales with Criticality Class (§7.10). [GP-22; GP-39]

6.7 Named owner for every Obligation #

Every Obligation must be owned by one named human, never by a department or a role. The owner is the person who can be asked why the Obligation exists. An Obligation without a named human owner is not valid. [GP-23]

6.8 Constraint provenance #

Every Constraint must be marked as externally imposed (contract, regulation, physics, etc.) or internally owned. Externally imposed Constraints are fixed for the Project. Internally owned Constraints may be questioned and renegotiated through their named owner. [GP-24]

6.9 Verification method assigned at authoring #

The verification method for an Obligation must be assigned when the Obligation is authored, not after design is underway. An Obligation without a verification method must not enter a Baseline (§9.1). Verification Procedures must run continuously as the design develops, not only at a late Gate. [GP-25; VFE]

6.10 Interface declarations #

Every interface between Components must be captured through one fixed lens that contains four elements: description, responsibility and change authority, reference frames with units and tolerances, and a checklist of the interaction categories and environments that apply. An interface is not declared until change authority over it is named. An interface declaration lives in the Dependencies & Interfaces section of the Specifications it connects; an interface that spans several Components lives in one declared interface document, referenced from those Specifications. [GP-26]

6.11 The graph is the single source of truth #

Relationships between Components form a graph. The Dependencies & Interfaces section of each Component Specification is the source of truth for all links: the Components or interfaces this one requires, the interfaces or Contracts this one provides, and any containment ("part of") relationship. Any grouping imposed by the concrete layout is organizational only and carries no authority; the graph remains the authority. The graph must be acyclic; a dependency cycle is a defect. [COD; GP-55]

6.12 Stability rules #

Every Component Specification must declare the Stability Class of the Component it defines. The set of Stability Classes and their order must be declared once in the Entry Point (§14.3). A Component may depend only on Components of equal or higher Stability Class. Configuration values and parameters that belong to Components of lower Stability Class must be kept explicit and external, never buried in the design or logic of Components of higher Stability Class. [LSA]

6.13 Specification-first Gate #

Before any significant change is made to the canonical Realization or System description, a durable, self-contained Contract must exist. It must name the Components and interfaces affected, state what is out of scope, and define the end-to-end Verification Procedures that prove completion. Authoring the Contract and executing the corresponding Production Work Unit must remain separate efforts.

Execution of a Production Work Unit must be gated on a human-approved Plan Document. Until that approval is recorded, Executors may examine the System but must not modify it. The human owner must be able to edit the Plan Document before approval.

When the necessary Contract or design parameters are unknown, an Executor may operate inside an Exploratory Work Unit (§5.7). Exploratory execution must:

• run in an isolated environment with read-only access to the Project Record;
• log all runs, parameter sweeps, and empirical results into the location bound to Records of Exploratory Work Units in the Path Map (§14.8);
• conclude with a structured experimental record that summarizes findings against the research objective.

Artifacts produced during exploratory execution have no governing force and must not be incorporated directly into the canonical Realization or System description. Once the resulting Contract and Verification Procedures receive human approval, validated exploratory assets may be ingested and hardened under a standard Production Work Unit. [GP-17; GP-18; SaC]

6.14 Adversarial expansion before acceptance #

A Contract must be treated as incomplete by default. Before acceptance, cases intended to expose gaps or weaknesses in the Contract (corner cases, misuse, hostile conditions, etc.) must be deliberately generated, and the Contract must be expanded to cover them. The expanded Contract becomes binding only after human approval. [GP-28]

6.15 Co-update of Specification and Realization #

A change to a Component must update its Specification and its Realization together, or the change must not be accepted. [GP-27]

6.16 Protection of other Contracts #

An internal change must not alter the Contract of any other Component. This bounds the Blast Radius of change. [GP-27]

6.17 Operational Concept #

The top-level System Specification must state the Operational Concept: how the System will be operated and sustained. The Operational Concept sits as an Obligation level between the expectations of the parties the System serves (customers, users, regulators, etc.) and the Component Obligations. [GP-22]

6.18 Key Design Parameters #

A small set of Key Design Parameters that govern System success must be named, owned, and tracked down to Component level in a dedicated register of the Project Record. A trade-off that moves a Key Design Parameter requires a Decision Record (§11). The tracked Key Design Parameters replace coordination machinery whose only function is routing information or re-approving what a named human owner already owns. The structure must not grow coordination roles or boards whose only purpose is that kind of routing or re-approval. This rule does not displace the controlled change Gate (§9.2) or any review body required by regulation or contract. [GP-29]

6.19 Design and planning documents use one skeleton #

Every design document, and every document that describes work spanning more than one Work Unit, must use one skeleton: Why (motivation, success criteria, requirements, scope); What/How (method, framing, validation strategy, and the points at which human judgment is required); How (realization, integration, cost and resource commitment, and risks); plus an Alternatives section. The Alternatives section identifies the options rejected and points to the Decision Records that hold their trade-offs and rationale, rather than restating them. [GP-79]