Section 4
The Project Record
On this page
- 4.1 Sole system of record
- 4.2 Durable work, disposable Executor instances
- 4.3 One canonical source per concern
- 4.4 Machine-readable, checkable surfaces
- 4.5 Work Record
- 4.6 One binding Plan Document per Work Unit
- 4.7 Iteration discipline
- 4.8 Concurrent contributions merge through one role
- 4.9 Governance Documents are controlled artifacts
4.1 Sole system of record #
All state that governs work must exist as durable, versioned, human-readable artifacts inside the Project Record. This includes Plan Documents, progress, decisions, open issues, and verification outcomes. Agreements held only outside the Project Record (in conversation, message channels, Executor memory, etc.) have no governing force and must be written into the Project Record before they become binding. Completed Plan Documents must remain in the record as history. The depth and formality of these artifacts may scale with Project criticality, but their existence is required. [GP-01; GP-06]
4.2 Durable work, disposable Executor instances #
Executor instances are disposable; the work product is durable. All meaningful work product must exist as versioned artifacts in the Project Record. Shared decisions must be recorded append-only and must be read by every Executor before work where relevant. Progress must accumulate only in the Project Record, never solely in the memory or private context of an Executor. [GP-65; GP-01; GP-02]
4.3 One canonical source per concern #
For every concern, exactly one artifact is the canonical source of truth. The Project must declare, in a single place readable by every Executor, which artifact governs each concern and how those artifacts relate to one another. Any derived artifact (indexes, ledgers, summaries, compliance records, etc.) must be generated from its canonical source and must never be maintained in parallel with it. Conflicting sources for one concern are a defect and must be resolved by designating one source and demoting the others. [GP-59]
4.4 Machine-readable, checkable surfaces #
Every surface of the System on which an Executor is expected to act (documents, interfaces, structured records, declared instructions, etc.) must be machine-readable and checkable. The human owner must own the Contract and the top-level decomposition; Executors implement beneath. [GP-76]
4.5 Work Record #
Every Project must maintain one Work Record: a structured, queryable artifact kept under the same version control as the System description, capturing every Work Unit and the discoveries made during execution. Unstructured prose lists must not serve as the system of record. Where Work Units carry dependencies, those dependencies must be recorded as typed relations (at minimum: blocks, part-of, supersedes, etc.); a Work Unit is then eligible for execution only when every relation that blocks it is resolved, and completing a unit must release its dependents. [GP-04; GP-05]
4.6 One binding Plan Document per Work Unit #
Each Work Unit must be governed by one binding Plan Document, which the Executor follows in preference to any conversational instruction. The unchecked Acceptance Criteria in the document constitute the queue of remaining work. A conflict between the Plan Document and an instruction must be resolved in favor of the Plan Document or escalated to the human owner. The Plan Document itself must record its current progress and the decisions taken under it. [GP-03; GP-01]
4.7 Iteration discipline #
Each work iteration must proceed as follows:
- Read the current state from the Project Record.
- Complete exactly one Work Unit.
- Verify that unit against its Acceptance Criteria.
- Record the new state and the verification outcome before the next iteration begins.
The size of the Work Unit is governed by the sizing and Blast Radius rules in §5.5 and §5.6. [GP-02; VFE]
4.8 Concurrent contributions merge through one role #
Where more than one Executor contributes to the same shared artifact at the same time, their contributions must be prepared separately and merged into the canonical artifact by one named role. No Executor may write directly to a canonical artifact while a merge is pending. The named role may be a human or a declared process, and it must be recorded in the Project Record for the duration of the concurrent work. [GP-65]
4.9 Governance Documents are controlled artifacts #
Governance Documents (including reusable instructions given to AI Agents) must be versioned, reviewable, and checkable artifacts in the Project Record under direct human editing. Governance Document content hidden inside tools or frameworks is prohibited. [GP-66]