Baselines and Change Control

9.1 Approved Baselines at declared levels #

The description of the System, and the description of its Realization, must be frozen as approved Baselines recorded in the Baseline Ledger. What is frozen is always a description held in the Project Record, never the Realization itself.

The Baseline levels in use and the Gate (§8.3) at which each is locked must be declared in the Entry Point (§14.3). The declaration must cover, at minimum, what the System must do (functional) and what each Component must do (allocated). Where the Realization is separately fabricated, configured, or deployed, as-built and as-deployed levels must additionally be declared. Any level that does not apply must be recorded as not applicable, with a short rationale, in the Criticality Record (§7.10).

Each Baseline entry must record:

• the artifacts it governs,
• a snapshot identifier that resolves within the version-controlled Project Record,
• its status, drawn from one fixed vocabulary: draft, locked, superseded, retired, and
• the named human who accepted the lock.

Snapshot identifiers must be derived from the version control system of the Project Record, never maintained by hand (§4.3, §10.1).

A Baseline is locked by human review at its declared Gate, and its closure is recorded as a Decision Record (§8.4). After lock, change is possible only through the controlled change Gate (§9.2). The human named on a locked entry is a record of who accepted that lock; authority over subsequent change belongs to the current named human owner (§15.1). [GP-50]

9.2 One controlled change Gate #

Change to any locked Baseline (§9.1), or to any artifact it governs, must pass through one controlled change Gate.

Each proposed change must be classified against the set of dimensions declared in the Entry Point (§14.3), which must include, at minimum: its impact on the Baseline, its cost, its safety consequence, and its compatibility with existing Contracts.

Every change must re-issue the affected Baseline entry and must be recorded in the Status Ledger (§9.3). To re-issue an entry is to record a new snapshot identifier against it; the entry retains its locked status and its original Gate-closure Decision Record, and no new Gate is held. An unrecorded change to a locked Baseline is a defect.

Authority to pass the Gate scales with the Blast Radius of the change (§15.3):

• Changes that alter a Contract, an Invariant, an Acceptance Criterion, or an artifact placed under direct human acceptance (§7.19) require human authorization recorded in a Decision Record (§11).
• Changes confined strictly within already-accepted Contracts, Invariants, and Acceptance Criteria require the approval of the named human owner (§15.1) recorded in the Status Ledger, which may be given directly or through human-approved automated Verification Procedures (§7.19).

The Vision Document passes through this Gate and requires a Decision Record in all cases (§3.2).

Exceptions must be recorded as explicit waivers and never absorbed silently. [GP-51; GP-27; GP-39]

9.3 One Status Ledger #

One Status Ledger must record the status and history of every change, deviation, waiver, and audit outcome.

Each entry recording a change to a locked Baseline must record:

• the affected and re-issued Baseline snapshot,
• the approving named human owner (§15.1),
• the change class, drawn from one fixed vocabulary: Contract, Invariant, Acceptance Criterion, human-acceptance artifact (§7.19), or contained (the change altered none of the preceding),
• whether the change is structural or behavioral (§9.5), and
• the governing Decision Record, which is required for every class except contained (§9.2).

Where approval was given through a human-approved automated Verification Procedure, the entry must additionally name the owner whose standing approval governs it and the procedure that executed it (§9.2). [GP-52]

9.4 Explicit Deviation Matrix #

Every deviation from this Specification must be explicit, and consolidated into a single auditable Deviation Matrix. Implicit deviation is prohibited. Each deviation must name what is waived, why, and which named human accepted the risk. [GP-53]

9.5 Separate structural and behavioral change #

Every change must be classified as structural (rearrangement without changed behavior) or behavioral (changed behavior). A single change must never mix the two. The classification must be recorded with the change: in the Status Ledger (§9.3) where the change is to a locked Baseline, and otherwise in the Plan Document governing the Work Unit that makes it (§4.6). The classification keeps every change legible for human review and bounds the review's scope. [GP-54]

9.6 Numbered generations #

Major redesigns of a Component must be bounded as numbered generations. Each generation must be defined by a step-change in a small declared set of tracked Key Design Parameters (§6.18). Changes within a generation must remain minor and must not redefine the generation's identity. [GP-15]