A stopping condition is part of the design

Plans usually describe how work moves forward.

They are less likely to state what must stop it.

That omission turns a target date, a polished interface, or a green subset of checks into implied permission to promote. The team may know important work is unfinished, but the plan contains no named condition with enough authority to hold the boundary.

A stopping condition makes that boundary part of the design.

Promotion is a claim about evidence

“Ready” is not one state.

A system may be:

• designed in accepted architecture records;
• implemented in a branch;
• statically validated;
• exercised locally;
• deployed into an environment;
• tested through recovery and negative cases; or
• operated over time with real users and failures.

Each level supports different claims. Moving between them should require evidence appropriate to the risk being accepted.

This matters most when the visible product is ahead of its foundations. A clean interface can make fictional fallback data look authoritative. A successful Terraform validation can make a missing production-configuration authority feel like a delivery detail. A static status page can make fixture data look live.

The promotion gate must follow the least mature load-bearing dependency, not the most convincing surface.

Pause when authority is missing

RS Platform removed complete Terraform configuration documents from CI secrets because they were not reviewable authority. The replacement design is accepted, but normal plan and apply remain paused until exact-plan delivery, protected provenance, recovery, and negative tests exist.

That pause is not an inability to write Terraform. It is a refusal to let valid source code imply a safe production change path.

The condition is specific enough to be useful: implement the private configuration authority, bind configuration and source to the reviewed plan, prove apply cannot substitute another plan, and rehearse recovery without an operator-local file.

“Needs more work” cannot guide a decision. A named missing authority can.

Stop a release when the product can invent success

In a separate assessment product, release review exposed two load-bearing data integrity failures. Autosave could report success for an older snapshot while newer answers remained unsaved, and a failed report path could fall back to fictional sample output.

Neither defect was cosmetic. One made persistence status unreliable; the other made the product capable of presenting an invented result at the moment a real result failed.

Brand consistency, form completion, partial test coverage, and a working happy path could not compensate for those failures. The correct release state was blocked until the latest snapshot and non-fictional failure behaviour could be proven.

This is the useful test for a stopping condition: does the missing evidence sit under the promise the product makes? If it does, promotion waits.

Label an honest prototype

Not every incomplete system needs to stop being shown.

The public platform page can use fixture-backed data when the page clearly labels it as editorial rather than live telemetry. A static site can describe future identity and API boundaries without shipping authentication or operator controls.

The stopping condition applies to the claim, not necessarily the artifact.

A prototype may be ready to demonstrate a visual direction while remaining unready to represent production state. A design may be ready for discussion while remaining unready for implementation. Clear labels preserve useful progress without borrowing maturity from the intended end state.

Stop when more effort cannot change the conclusion

Stopping conditions also protect resources from a technically interesting dead end.

In the lottery forecasting project, model complexity could continue increasing, but the available data did not contain a viable predictive signal. Additional tuning could improve a loss curve without changing that conclusion.

The useful work moved to the surrounding system: leakage-aware evaluation, repeatable training, failure visibility, artifact lineage, cost control, and an honest account of what was and was not operated.

Stopping the original product premise preserved the engineering that remained valuable. Continuing to tune would have consumed attention without creating new decision evidence.

Incident response needs a second stopping condition

Restoring service ends the immediate outage. It does not automatically complete the recovery work.

After the production website incident, the record separated successful restoration from permanent fixes that still lived on a repair branch and from follow-up work that remained open. That prevents “the site is back” from silently becoming “the recovery path is now repeatable.”

The first stopping condition protects availability: do not leave the service down while pursuing an ideal cleanup. The second protects reliability: do not close the incident as structurally resolved until the fixes, runbooks, and recovery checks reach their intended authority.

Write the gate before the pressure arrives

A useful stopping condition names four things:

1. the claim or promotion it blocks;
2. the missing evidence or unsafe failure mode;
3. the test, decision, or authority that can unblock it; and
4. the person or system allowed to accept the residual risk.

Written early, those conditions reduce negotiation during a deadline. They make it possible to cut scope while protecting the core promise. They also help a decision-maker stop investing when new work is no longer capable of changing the outcome.

Progress is not the absence of pauses. It is the ability to explain why the next step is authorized—and why, in some cases, it is not.