Governance Documents and Layout

14.1 One governing-principles document #

One human-authored Governance Document must state the Project's durable principles, quality bars, and Invariants. It must be bound in the Path Map (§14.8), versioned, and created before detailed work begins. Every later artifact and every Executor, in-house or external, is checked against it. [GP-68]

14.2 Governance content discipline #

Governance Documents must contain only what an Executor cannot discover from the System itself: hard Invariants, safety and security boundaries, non-obvious Constraints, and non-obvious procedures, etc. Overviews, standard conventions, and restatements of discoverable content are prohibited. Each Governance Document must stay under a declared size ceiling, must reference other artifacts instead of copying their content, must separate concerns into purpose-named documents, and must mark which Specifications describe not-yet-realized work. [GP-69]

14.3 One Entry Point into a versioned tree #

The Project must expose one short Entry Point document that serves as the root descriptor of the Project Record: a map, not an encyclopedia. The full knowledge base must live in a structured, versioned documentation tree that the Entry Point indexes. Executors start at the Entry Point and are directed to deeper sources as needed. The tree must be checkable for currency, cross-linking, and structure (§16).

Exactly one Entry Point exists per Project. Because the Path Map it carries (§14.8) binds every other Entity, the Entry Point is the one Entity whose own location this Specification fixes: it must be named INDEX and reside at the root of the Project Record, with the extension determined by its serialization format. No other Entity location is fixed by this Specification.

The Entry Point must declare all of the following, and nothing else is required of it:

• the Path Map (§14.8): every required Entity bound to its concrete location pattern and serialization format, including the internal layout of the Realization;
• the set of Stability Classes in use and their order (§6.12);
• the significance test for Decision Records (§11.3);
• the Baseline levels in use and the Gate at which each is locked (§9.1);
• the set of dimensions against which a proposed change is classified (§9.2).

[GP-70]

14.4 Governance binds to Component boundaries #

Governance Documents must bind to Component boundaries: a Component may carry its own Governance Document, and within that Component the nearest document governs. Global governance applies wherever no local document overrides it. Humans must author and control all Governance Documents at every level. [GP-71]

14.5 Placement and naming are declared structure #

Placement and naming of artifacts are part of the declared structure and carry meaning for every Executor. The location of an artifact must declare its role. The meaning assigned to placement and naming must be declared in the Governance Documents wherever that meaning cannot be derived by inspecting the System. The Path Map (§14.8) must not be restated in a Governance Document. [GP-72]

14.6 Documentation lives on the artifact it governs #

Documentation must live on the artifact it documents, as close to the governed element as possible. Critical Constraints must be visible at the point where the governed action happens. Documentation that governs one element lives on that element; documentation that spans elements (Specifications, Decision Records, Plan Documents, design documents, etc.) lives in the documentation tree and is reached from the Entry Point. Documentation separated from the artifact it governs drifts and must be treated as suspect. [GP-73]

14.7 One Registry; unregistered does not exist #

One machine-readable Registry must register every Component and content item of the System with its identity. Each entry's location must be derived from the Project Record, never authored in parallel with it (§4.3, §10.1), and must resolve within the pattern the Path Map (§14.8) binds for that Entity. An item that is not registered does not exist in the System. Adding or removing an item must update its Registry identity in the same change; relocating an item requires no Registry edit, since location is derived. [GP-78]

14.8 Required entities and the Path Map #

A Project must hold every Entity listed in Appendix A, at the multiplicity stated there. Every Entity except the Realization resides in the Project Record; the Realization resides wherever the Path Map binds it. This Specification defines the Entities, their required content, and their relationships; it does not fix their storage.

Storage is fixed by the Project's Path Map (§2), which must be stated in full in the Entry Point (§14.3). The Path Map must not resolve by reference to any document outside the Project Record (§4.1).

A location pattern is a path, a directory, or a glob pattern that covers every instance of its Entity. A serialization format is any format the Project's tooling can parse: Markdown, YAML, JSON, a domain-native model format, etc.

The Path Map must satisfy the following rules:

• Every required Entity carries exactly one binding rule. That rule may bind more than one pattern where Appendix A states more than one placement for the Entity.
• The binding is deterministic: for any artifact in the Project Record, the Entity it instantiates must be unambiguously resolvable from the Path Map.
• Singleton Entities must resolve to exactly one artifact. Multi-instance Entities must resolve through a pattern that covers every instance.
• An Entity whose multiplicity permits zero instances is bound by a pattern that currently matches nothing; the binding is still required.
• The Path Map must declare the internal layout of the Realization, which this Specification does not prescribe.
• Normative Checks resolve Entity locations through the Path Map alone (§16.1).

The required Entity set is the minimum: a Project may bind additional artifacts and extend its layout, but it must not leave a required Entity unbound except through §1.5. [GP-70; GP-72; GP-78; Goal DR1]