How to Change AI Project Requirements Without Losing the Thread

What is requirement change control for AI work?

Requirement change control is a way to keep one product rule and its effects together. It records what changed, why it changed, who accepted it, and which work must now be reviewed.

This starts after a requirement already exists. A source-of-truth process owns the first request. Change control begins when the team wants to replace part of that accepted truth.

Think of a paper card for the cancellation rule. The card has one permanent number. It shows the current rule, its owner, and the check that proves the rule works. Tasks and checks point back to that number.

When the rule changes, the team keeps the old version for history. It adds a change record, reviews the effects, and marks the new version as current. The permanent number stays the same.

That stable number matters because wording is easy to copy. A named record is easier to find and update. Engineers may call the record a requirement node. The saved links between records form a requirements graph. You do not need a graph database. A small table with dependable links is enough.

This control does not own the whole workflow. It does not define every task field or prove that a test passed. It answers a narrower question: what must stop or change when an accepted product rule changes?

What should one requirement record hold?

Start with fields that help someone make a decision. A large template creates busywork if nobody uses it.

The smallest useful record gives the rule one stable name, keeps its reason close, and points to the work and check that depend on it.

NASA's systems engineering guidance includes a requirement ID, rationale, owner, source links, and a verification method in its requirement metadata. A small product team can use the same logic with fewer fields.

The table below is the small version for the cancellation rule.

A link is a pointer, not proof. It gives the reviewer a place to inspect. It does not prove that every affected item is linked or that the linked item is correct.

The owner should also be current. A dead link to a former owner is a hidden blank. Confirm the owner and source before the team acts on a serious change.

How do you trace the change before work continues?

Do not erase the old sentence. Save it beside the proposed one.

A change record is a short record for the proposal and its decision. It should name the requirement, old wording, proposed wording, reason, requester, decision owner, affected records, and next action.

The old version becomes superseded after approval. That means it stays in history but is no longer the rule people should follow.

Traceability means you can walk from the changed rule to each known task and check. An impact link is the saved pointer that makes this walk possible.

Microsoft's current Azure DevOps guidance says teams should examine dependencies, current work, planned work, and the risks of accepting or rejecting a change. It also supports lightweight change-control forms. A small team does not need a committee, but it still needs a visible decision.

For the cancellation rule, the review should look like this before anyone keeps building.

Approval is not the last step. Each affected record needs an owner and a visible result. If the product lead accepts the new rule but nobody updates the task or check, the team has approved drift.

How do you block work that still follows the old rule?

A drift gate is a check that can stop known stale work. It reads the current requirement, open change records, and the links to affected work.

The gate should be honest about what it knows. It can block a linked task that still follows the old rule. It cannot claim that an unlinked file is safe.

Use three outcomes.

Do not turn WARN into quiet approval. It means the map has a gap. The right response may still be to stop, but that decision belongs to the team unless the policy makes this warning a block.

A useful block explains the repair path. It should name the open change, affected record, old version, owner, and next check. A red light without a repair path just moves the confusion into another tool.

The cancellation change can clear only after the current requirement is accepted, each known task and product surface is updated, and the old check is replaced.

Change control marks the old proof stale. Completion evidence decides whether the new proof is good enough.

What happened when I tested the change gate?

I tested this rule against a frozen public version of WarpOS, my agentic operating-system project for long-running AI work.

The experiment used a disposable copy of commit 8b083d78948263c998134ac5d34947c383e17a85. It created one made-up feature, two made-up requirements, and one made-up change record. It made no network call and did not read or change live WarpOS work.

The actual frozen graph builder and gate handled three cases.

The second result has an important detail. The stale requirement was linked to its open change record, so the stale-coverage check was green. A separate rule blocked the unresolved Class C change. Recording the change made it visible. It did not make the decision complete.

The third result stayed a warning. The frozen gate found the unmatched file but did not treat it as a red block. The JSON result still reported ok: true. The article keeps that limit instead of claiming the graph prevents every kind of drift.

The experiment proves only these three synthetic control paths at the frozen commit. It does not prove universal links from intent to code or tests. It does not test production reliability, safety, concurrency, release policy, approval quality, or human judgment.

What did WarpOS reveal about requirements control?

WarpOS already had a serious requirements lane at that frozen commit.

Its graph builder read named stories, dependencies, acceptance criteria, and implementation paths. It built reverse links from files to requirements. It also saved hashes for three main specification files so the gate could spot a graph built from older text.

The gate checked that the graph existed, its counts matched its contents, and those saved hashes were current. It blocked an open Class C change. It also blocked a stale requirement with no open change record that named it.

Those are real controls.

The gaps are just as useful. The graph builder left feature-level test links empty. The staged-file check treated an unmatched JavaScript or TypeScript file as a warning. A marker could also allow that warning. The separate goal_verification lane could connect acceptance checks to named tests, but it applied only when a plan opted in.

The frozen result can be summarized without pretending it is complete.

The design lesson is simple. A rich map is still a claim about coverage. State what the map reads, what the gate blocks, and what remains a warning.

How can your team control one change this week?

Choose one change that can alter active work or a final check. Do not begin with the whole product.

Give the current requirement a stable ID. Save the old and proposed wording. Name who requested the change and who can accept it.

List the known task, product surface, customer copy, check, and release decision that depend on the rule. Give each one an owner.

Place the gate where work really moves forward. A prompt can draft the records. It cannot stop a task, merge, or release unless a real workflow check reads them.

Plant three tests before trusting the control. A complete current graph should pass. An open important change with known stale work should block. Unmatched work should warn and name the gap.

Use the prompt below to draft the records and verdicts. A person still needs to confirm the facts, accept the product decision, and connect the gate to the real workflow.