Section 1
Purpose, Scope, and Compliance
On this page
1.1 Authority #
This Specification defines the required structure of every Project built under the Framework for Keeping Complex Work Coherent Across Time: the required artifacts, their content rules, their directional relationships, and the Normative Checks that enforce them. It is the structural reference for humans and AI Agents alike. Concrete storage of the artifacts is declared by each Project's Path Map (§1.8, §14.8). [Goal §6.2; SaC]
1.2 Domain of application #
This Specification is intended to support engineered Systems of high complexity across domains, including software platforms, robotic Systems, and floating cities. Its core clauses avoid domain-specific assumptions. Domain practice adds the methods and controls required by each field, with any structural deviation recorded under §1.5. [Goal P3; GP-16]
1.3 Human authority #
Purpose, Invariants, risk acceptance, and the definition of done belong to the human owner. AI Agents may draft, propose, and implement; they may not enact changes to purpose, Contracts, Acceptance Criteria, or risk acceptance. Every clause of this Specification preserves this division. [Goal P4; Goal §5; VFE; SaC]
1.4 Completeness of structure #
The Project structure must cover four recursive process groups at every level of the System:
- Agreement: formal commitments with external parties (customers, users, partners, regulators, vendors, contractors, etc.).
- Project-enabling: the supporting work that makes the Project possible (tooling, configuration, quality infrastructure, shared services, etc.).
- Technical management: planning, monitoring, decision-making, risk handling, control of the work, etc.
- Technical: the actual engineering work (defining, designing, realizing, verifying, etc.) of the System.
These groups classify required coverage. They do not prescribe any particular life-cycle model. No level of the System may omit the agreement processes or the verification processes. [GP-16]
1.5 Compliance and deviation #
Every clause of this Specification is binding. A deviation is allowed only when it is recorded as an explicit entry in the Deviation Matrix (§9.4). Each entry must name:
- what is being waived,
- why the waiver is needed, and
- which named human accepted the risk.
The matrix starts empty. Most Projects will have few or no entries. Implicit or unspoken deviation is prohibited. The purpose of this rule is transparency and human accountability, not bureaucracy. [GP-53; SaC]
1.6 Formality scales with risk; every required Entity must exist #
No Entity required by this Specification may be omitted; only the depth of its instances may be adjusted.
The amount of detail, documentation, and review applied to each artifact scales with two factors:
- the Criticality Class of the Component or Capability it governs (see §7.10), and
- the overall risk and complexity of the Project.
Low-criticality work may use lightweight versions of the required artifacts. High-criticality or safety-relevant work must use fuller, more rigorous versions. The decision to use a lighter or fuller version must be recorded with a short rationale in the Criticality Record (§7.10).
This clause governs the depth of a required artifact only; it does not override §1.5. Omission of a required Entity remains possible solely as an entry in the Deviation Matrix (§9.4). [GP-39; VFE]
1.7 This Specification is high-stability #
Individual Projects must not create their own versions of this Specification. If a Project needs to deviate from any clause, it must do so explicitly using the deviation process in §1.5.
The Specification may be changed only by a human decision recorded as a Decision Record (§11) that states the reason for the change and its consequences. [LSA; SaC]
1.8 Abstract information model, concrete storage #
This Specification defines an abstract information architecture: the required Entities, their required content, their directional relationships, and the Gates that bind them. It does not prescribe concrete storage. Filesystem paths, directory trees, file names, and serialization formats (Markdown, YAML, JSON, domain-native model formats, etc.) are declared by each Project in its Path Map (§14.8).
This separation is deliberate, for four reasons:
- No ontological mismatch. A standard defines requirements and an information model. Hardcoded storage paths would conflate the meta-model of the architecture with one storage implementation of it.
- Domain-native tooling. Domains work in different native formats: declarative interface schemas, structured data files, parametric models, tabular mass-property data, etc. Forcing one serialization on every domain creates friction between the System description and the tools that produce and check it.
- Checkable serialization. Human-readable prose formats are fragile for the automated parsing of relational data (dependency graphs, ledger entries, Obligation matrices, etc.). The serialization format of each Entity is therefore a declared Project choice, so that Normative Checks can parse each Entity in a format suited to mechanical verification.
- Composability. A concrete layout that serves one domain well can be reused by other Projects in that domain. Ready-made layout guides for particular domains may exist outside this Specification. They are not part of it and bind nothing: a Project's Path Map governs, whatever its bindings were modelled on.