Last updated September 18, 2026
4 min read
A fictional logistics feature is halfway built when operations changes the cancellation window from 30 minutes to two hours. Freezing the original rule would ship known-wrong behavior. Editing the file in place would make old tests look as if they proved the new decision. Versioned change control avoids both failures. This is an explicitly fictional composite, not a customer result.
In this article
A baseline creates a fair comparison
The baseline answers a narrow question: what behavior is this implementation currently trying to prove? It is not a promise that requirements will never change. A stable comparison target prevents the code and tests from moving the goal together.
NIST AI RMF Core bounds this claim. Voluntary risk guidance, not certification or product proof.
| Evidence point | Interpretation |
|---|---|
| 1 | v1: 30-minute window |
| 2 | v2: two-hour window |
| 3 | Receipt: reason and owner |
| 4 | Evidence: rerun affected criteria |
Treat the table as a working diagnostic. Replace illustrative labels with repository evidence before making a budget, staffing, or release decision.
Change receipts protect evidence meaning
A change receipt records old value, new value, reason, decision owner, timestamp, affected criteria, and the evidence that must run again. This gives the team a reviewable bridge instead of a rewritten document with no history.
Order matters because later checks inherit the intent and scope established earlier. A skipped step does not remove uncertainty. It hands that uncertainty to a reviewer under time pressure.
Not every edit invalidates every check
Changing the cancellation window invalidates time-bound tests and user documentation. It may not invalidate unrelated authorization evidence. Mark impact at criterion and artifact level so the team reruns what matters without pretending every result is stale.
Lee and See on trust in automation adds a second evidence boundary. General human-factors guidance, not coding-specific prevalence.
A procedural fix can be inspected, rehearsed, and improved. A warning without an owner or artifact usually disappears during the next busy sprint.
Resume only against the approved version
Before an agent resumes, it should verify the approved specification version, repository revision, and open change receipt. If any mismatch remains, return to planning or pause for a human. Guessing at the newest intent defeats the baseline.
paqad-ai v1.67.0 was the current public release when this article was checked on July 21, 2026. Its repository describes risk routing, specialist roles, structured state, deterministic checks, documentation sync, and local audit records. These are product mechanisms, not independent outcome proof.
Use the AI workflow audit guide to map current practice, compare the bar with production-ready AI code, and use the AI coding consultant guide when the team needs outside ownership.
Decision rule: If intent changes the meaning of a criterion, issue a new approved baseline and invalidate only the evidence affected by that change.
Run the specification change-receipt template in a 45-minute working review with the product owner, module owner, and final reviewer. Do not turn it into a score. Read the decision rule aloud: If intent changes the meaning of a criterion, issue a new approved baseline and invalidate only the evidence affected by that change. Record disagreements, missing evidence, and the person responsible for the next action. Repeat the review after one real feature so the team can compare whether the artifact reduced ambiguity or only added paperwork.
Frequently Asked Questions
Does baselining stop agile product changes?
No. It makes changes visible at the moment they affect code and evidence. Teams can change direction quickly while retaining who decided, why, and what must be checked again.
When should the version number change?
Change it when intended behavior, invariants, scope, or proof expectations change. Editorial clarification that preserves meaning can remain in the same version with a small edit note.
What happens to old evidence?
Keep it as historical evidence for the old baseline. Mark affected items stale for the new version, then rerun or replace them. Do not delete the record that explains the transition.
What next?
Apply the specification change-receipt template to one current feature. If the repository cannot answer the questions it exposes, install paqad-ai and test a governed workflow with local evidence and explicit human authority.