6. Change, records and recovery

6.1 Change the source that governs the work

A decision should reach the artifact where its meaning takes effect. A product-wide requirement belongs in the product basis. A deliverable commitment belongs in its production contract. A technical realization belongs in the design material or the relevant implementation source.

The existing change record explains why the source changed and what consequences remain. Version history preserves earlier text. A separate append register is unnecessary when it repeats decisions already available through those sources.

A cross-cutting decision can affect several contribution owners. Establish one shared resolution within authority before conflicting repairs spread. Different contributions may need different implementations of the same decision. Verify adoption in their actual results.

Do not edit history to make an old result describe a new candidate. Preserve the earlier observation and record the current consequence where needed.

6.2 Distinguish kinds of change

A factual correction, implementation refinement, changed accepted commitment and new human priority require different treatment.

When you own authorized implementation, you can usually refine a design without renewed approval if the commitments and boundaries remain satisfied. A change to an acceptance criterion, reliance condition or out-of-scope interface may require another decision.

State the proposed effect before applying a reserved change. Which commitment changes? Which consumers rely on it? What existing evidence becomes inapplicable? Which work remains valid?

Apply already-authorized decisions directly. Do not ask the person to approve the same act again because it moved into another file or session. Equally, do not treat approval of a plan as acceptance of all future unknown content.

6.3 Give records a concrete purpose

Maintain a record when a concrete consumer needs it to decide, act, examine or recover, or when an acceptance requirement calls for it. Identify the consumer and the question the record answers. A test report, accepted qualification or operational instruction can serve these purposes. When a current source, query or change history already meets the need, prefer a link or query over another maintained copy.

Some records are product requirements. A model history, signed operational decision, user checkpoint or regulated record may be part of the product itself. Reducing development administration does not remove those obligations. No filename or record type is universally excluded; use the smallest representation that reliably serves the identified purpose.

6.4 Recover only what continuation needs

Begin with current artifacts, actual state and the latest steering. Use history to resolve relevant uncertainty. Do not rebuild a complete chronology simply because a session restarted.

Open work is usually recoverable from its own records: each open change's description states its exact version, the checks performed, what remains and the next step, and repeatable discovery re-establishes the wider state. Where those do not suffice, a replaceable recovery note can identify the current candidate, completed work, pending checks, active operations, local-only output, holds and next useful action. Its purpose is continuity, not an accumulating record of every session.

If an operation executed but confirmation was lost, inspect the actual state before repeating it. A duplicate write or release can be worse than a delayed confirmation. Preparation and execution must remain distinguishable.

When transferring ownership, establish the boundary of responsibility and the work retained. A new worker should not overwrite an active operation or discard an unmerged result merely because it was absent from the latest narrative.

6.5 Preserve history without keeping every working copy

Version control can preserve earlier committed work while the active tree contains only current sources. A recovery tag can identify an archived product or completed undertaking. Removing a working copy need not erase its history.

Untracked and ignored files require separate attention. Build caches can be reproducible; local notes, fixtures or session data may not be. Establish what needs preservation before removing a worktree or directory.

Retirement is a current decision about development and reliance. A frozen product can remain recoverable without occupying the active working surface or receiving routine verification. Restoring its files is not the same as reactivating its commitments or authorizing release.

Do not build new compatibility machinery solely to keep a retired consumer alive. Preserve a specific fixture, schema or contract if current work genuinely needs it. Give that artifact a maintained home and identifiable provenance.

6.6 Separate discovery from reliance

A versionless pointer is useful for finding the current edition of a document. It reduces obsolete links and gives a new participant a stable entry point.

That pointer is mutable. It cannot identify the exact content used in an earlier decision unless its revision and resolved target are also known. A project that depends on specific wording should identify the selected edition or source revision.

These uses can coexist. Human navigation can follow “current.” A reproducible comparison can use a particular edition at a commit. A later edition can be assessed for adoption without silently changing the earlier result.

Record exact identity where a real consumer needs it: an accepted basis, a content-bound test or a consequential comparison. Ordinary discovery does not require an elaborate receipt for each document read.