What if my needs change after handoff?

For 90 days after your builder acknowledges the first handoff, changes you approve are included. Each approved change makes a new version of the Build Specification, with a change report showing what it affects. After those 90 days, a major revision needs a new credit.

Needs change. The point is that every change is visible, approved by the right people, and traced through to what it touches.

When does the 90-day window start?

When the builder acknowledges receiving the first handoff, or 5 days after it's delivered if they haven't acknowledged it by then. It starts once. Handing a later version to the builder doesn't restart it.

How do I make a change?

As a change request in the project. Your team describes the change, and it waits for confirmation from the people who decide. When it touches the approved scope, the sponsor confirms it. Once it's confirmed, the change is worked into the specification the usual way, and the experts it affects check the result.

What does the builder get?

A new version of the specification and the build package, with a change report. The report is worked out by code from the two versions, not by AI, so the same two versions produce the same report every time. It lists:

• items changed, added and taken out;
• what depends on them, including their acceptance criteria and tests;
• decisions and assumptions that changed;
• changes to the data model, the approved scope and the ownership answers;
• one list of trace IDs for the builder to revisit.

The builder's tools can read the same report through the MCP server or API.

What isn't covered?

A change that adds a separately deployed system, or turns the project into a different application, isn't a change: it's a new application, and it needs its own credit. After the 90 days, change requests aren't taken in the project, and a bigger change becomes a new specification.

What about changes during the build?

When your builder finds something the specification doesn't answer, their tools can ask a question about that trace ID. It goes to the experts the item came from, and the answer becomes part of the record. That isn't a change request; it fills a gap.

How do I keep changes small?

Settle disagreements and decide what's out of scope before sign-off. A short "not in this version" list prevents many changes later. See how to avoid scope creep.