Normative Structural Specification
Normative Structural Specification for Complex Engineering Projects
On this page
This is the structural document of the Framework for Keeping Complex Work Coherent Across Time. It states what an adopting Project must contain, how the elements relate, and which rules bind them. Where each element lives is declared by each Project's Path Map, not by this Specification (§1.8, §14.8). It operationalizes the five core principles of the Governing Principles: Component-Oriented Decomposition (COD), Layered System Architecture (LSA), Integrated Modularity First (IMF), Verification-First Engineering (VFE), and Specifications as Contracts (SaC).
Every normative clause is traceable to one or more of the 79 Adopted structural forms (GP-01 to GP-79) in Generalized Patterns or to a frozen principle. Each clause ends with a traceability bracket naming its grounds. Appendix B gives the complete mapping. Where this Specification and any other framework document conflict on structure, this Specification governs.
Scope of application
This Specification defines the structural foundation for Projects that adopt the Framework for Keeping Complex Work Coherent Across Time. Its clauses bind an adopting Project, and a deviation is allowed only as recorded in the Deviation Matrix (§1.5, §9.4). Not every clause is equally relevant to every Project. The core sections apply to all adopting Projects. The depth and formality with which each required artifact is produced scale with the Criticality Class of the Component or Capability it governs and with the overall risk and complexity of the Project, as defined in §1.6 and §7.10.
Sections
- 1 Purpose, Scope, and Compliance Authority · Domain of application · Human authority · Completeness of structure · Compliance and deviation · Formality scales with risk; every required Entity must exist · This Specification is high-stability · Abstract information model, concrete storage
- 2 Terminology The terms below are defined once and used consistently throughout this Specification.
- 3 Purpose One Vision Document · Highest stability · Hierarchy of intent
- 4 The Project Record Sole system of record · Durable work, disposable Executor instances · One canonical source per concern · Machine-readable, checkable surfaces · Work Record · One binding Plan Document per Work Unit · Iteration discipline · Concurrent contributions merge through one role · Governance Documents are controlled artifacts
- 5 Decomposition and Work Units Deliverable-anchored decomposition · Purpose-defined Components · System level before Component detail · Integrated modularity first · Sizing · Work Units bounded by Blast Radius · Work Units must be verifiable · Nested levels of intent · Work Units for long-horizon work · Reusable task definitions
- 6 Component Specifications and Contracts Component Specifications · Required sections, linted · Public Contract, private Design · The Specification is the durable alignment artifact · Obligation statements · Obligation attributes · Named owner for every Obligation · Constraint provenance · Verification method assigned at authoring · Interface declarations · The graph is the single source of truth · Stability rules · Specification-first Gate · Adversarial expansion before acceptance · Co-update of Specification and Realization · Protection of other Contracts · Operational Concept · Key Design Parameters · Design and planning documents use one skeleton
- 7 Verification and Acceptance Done is a checkable criterion · The verification loop · Verifiability governs delegation · Verification Procedures are authored before the Work Unit · Verification Reference State before change · Durable corpus of Verification Procedures · Layered verification · Verification correspondence · Governing Verification Plan · Criticality Classes · Independent verification · Acceptance Criteria must not be weakened · Every Contract clause is linked to its Verification Procedures · Structured outputs for verification · Linked stage Verification Procedures across production · Model-based verification before costly Realization · Reference Realization and drift detection · Durable execution records · Human acceptance by class
- 8 Phases and Gates Artifact-gated Phase sequence · Evidence before, verification after · Event-based Gates · Gate closure is recorded · Durable human breakpoints
- 9 Baselines and Change Control Approved Baselines at declared levels · One controlled change Gate · One Status Ledger · Explicit Deviation Matrix · Separate structural and behavioral change · Numbered generations
- 10 Traceability and Lineage Traceability is structural · Bidirectional traceability · Versioned input lineage · The realization system is traced like the System
- 11 Decision Records Format and storage · Fixed status vocabulary · Significance test · Consultation and single home
- 12 Risk and Failure Continuous Risk Register · Failure closure by numbered corrective actions
- 13 Executor Boundaries Declared Executor scope · Boundaries are structural, not prose · Delegated work stays isolated
- 14 Governance Documents and Layout One governing-principles document · Governance content discipline · One Entry Point into a versioned tree · Governance binds to Component boundaries · Placement and naming are declared structure · Documentation lives on the artifact it governs · One Registry; unregistered does not exist · Required entities and the Path Map
- 16 Normative Checks Encode Invariants as Normative Checks · Minimum Normative Check set · Normative Check outcomes must be recorded
Appendices
- A Required Entity Set The Entity and Multiplicity columns are normative: §14.8 requires every Entity below, at the multiplicity stated, and §16.2 checks that each is bound in the Path Map. The Clause…
- B Traceability of the 79 Adopted Forms Non-normative mapping. It shows where each Adopted form of Generalized Patterns is realized in this Specification. Clauses cited by number refer to sections of this document.