Normative Checks

16.1 Encode Invariants as Normative Checks #

Every Invariant and structural rule of this Specification that can be checked mechanically must be encoded as a Normative Check and run continuously. Failure messages must tell the Executor how to remediate. Rules that require judgment remain as prose and are enforced by review. [GP-63]

16.2 Minimum Normative Check set #

The following Normative Checks are mandatory at minimum. A Project may add Normative Checks; it may not remove these except through §1.5.

• Every Component Specification contains the five required sections (§6.2).
• Every Component is registered in the Registry, and every Registry entry resolves to an artifact in the Project Record (§14.7).
• Every Obligation carries an identifier, a named human owner, and a verification method; and every Constraint additionally carries a provenance marking (§6.5 to §6.9).
• The Component dependency graph is acyclic, and every dependency points toward an element of equal or higher Stability Class (§6.11, §6.12).
• Every Acceptance Criterion is linked to at least one Verification Procedure, and every Verification Procedure is linked to a Contract clause (§7.13).
• Traceability is complete in both directions: no Obligation lacks a parent path to the Vision Document or a child path to Realization elements and Verification Procedures (§10.2).
• Every Decision Record carries a valid status, and every supersession pointer resolves (§11.2).
• Every Gate closure has a Decision Record with discrepancy disposition (§8.4).
• The Verification Plan records a Reference Realization designation, with rationale, and a comparison interval for every designated Contract (§7.17).
• Every Baseline level declared in the Entry Point has a corresponding entry in the Baseline Ledger, and every entry carries a status from the fixed vocabulary (§9.1, §14.3).
• Every snapshot identifier in the Baseline Ledger resolves within the Project Record (§9.1).
• Every Baseline whose status is locked has a Gate-closure Decision Record (§8.4, §9.1).
• Every Status Ledger entry recording a change to a locked Baseline names the re-issued Baseline snapshot, an approving named human owner, a change class from the fixed vocabulary, and a structural-or-behavioral classification; and every entry whose class is not "contained" carries a Decision Record reference that resolves (§9.2, §9.3, §9.5).
• The Entry Point is named INDEX and resides at the root of the Project Record (§14.3).
• Every required Entity of Appendix A is bound exactly once in the Path Map, every binding resolves to artifacts in the declared format, and the Entity of every artifact in the Project Record is unambiguously resolvable (§14.8).
• Governance Documents are under their size ceiling, and all Entry Point links resolve (§14.2, §14.3).

[GP-20; GP-21; GP-22; GP-23; GP-24; GP-25; GP-42; GP-47; GP-49; GP-50; GP-51; GP-52; GP-54; GP-55; GP-56; GP-60; GP-63; GP-69; GP-70; GP-78; COD; LSA; SaC; VFE]

16.3 Normative Check outcomes must be recorded #

The outcome of every Normative Check run must be recorded as a durable artifact in the Project Record. A Normative Check whose outcome is not recorded has not run. [GP-48; VFE]