AI-assisted workflows are very good at continuing. A model can generate another version, add another check, respond to the latest critique, and discover one more improvement. That ability is useful until the workflow no longer knows why it is still running.
I encountered this while building content and product workflows with AI. Individual outputs often improved, yet the process could drift because every new observation looked like a reason to reopen the current stage. A local fix might make one paragraph smoother while weakening a claim boundary. A downstream layout issue might send the system back toward research. The work was active, but its state was unclear.
The practical answer was to define “done” for each stage. A stage is done when it achieves its specific goal, passes its required checks, resolves or escalates material blockers, and reaches an explicit stop condition. It does not need to be incapable of future improvement.
This is not a generic Scrum definition-of-done template. It is a control method for AI-assisted work, where generation, audit, and revision can otherwise continue without a natural endpoint.
Start with the stage, not the final aspiration
“Create an excellent bilingual article” is a useful aspiration and a weak stage contract. It combines research, evidence, drafting, editing, localization, implementation, publication, and performance into one open-ended instruction.
Each part needs a narrower responsibility.
- Research should establish a usable evidence set and its boundaries.
- A Content Brief should define the article promise, structure, claims, and exclusions.
- English production should create a candidate that passes brief, claim, and humanization checks.
- Chinese production should create native writing that preserves the English facts and evidence boundaries.
- Website implementation should preserve the approved content and pass build, rendering, SEO, accessibility, and draft-safety checks.
- Publication should happen only after explicit authorization.
- Outcome observation should begin only after there is something live to observe.
These stages are connected, but they are not interchangeable. A successful build does not prove the article is editorially sound. A polished English draft does not prove the Chinese version is factually aligned. A published page does not prove SEO or GEO performance.
Defining done at stage level lets the workflow preserve those distinctions.
Five parts of a useful done contract
A practical contract needs more than a checklist. I use five connected parts.
1. A single stage goal
State the outcome this stage owns. The goal should be specific enough to exclude work that belongs elsewhere.
For an evidence stage, the goal might be: establish the sources and first-party records allowed to support the article’s central claims. It is not “write the most comprehensive article possible.”
2. Required acceptance criteria
List the conditions that must be true before the output can move forward. Criteria should be observable: a source plan exists, every material claim has a support class, the Chinese candidate preserves every measurement exclusion, or all website routes remain unpublished.
Avoid replacing judgment with a vague score. An automated rating can point to a possible issue. Acceptance criteria explain why the issue matters and what passing means.
3. Material checks
Checks test the acceptance criteria from different angles. A brief audit asks whether the planned article fulfils its promise. A claim audit asks whether statements stay within the evidence. A factual regression asks whether another language or implementation changed meaning.
The checks should match the stage. Running every available audit everywhere creates noise and increases the chance that two tools argue about unrelated preferences.
4. A finite repair policy
When a material check fails, the workflow needs permission to repair the problem and a limit on how long it may continue.
In the low-touch Blog workflow I built for HuiyangXie.ca, one material blocker can receive at most two targeted automated repairs. A normal article cycle can use at most four material automated repair actions in total. If the blocker remains, the workflow stops for an owner decision.
The exact numbers are a workflow choice, not a universal law. Their purpose is to make escalation predictable. They prevent the system from hiding uncertainty behind endless revision.
5. An explicit stop condition
Define the state that proves the stage has ended: a locked artifact and hash, a passed audit set, a preview candidate, or an exception package. State what may happen next and what remains prohibited.
Without that line, “done” can quietly expand. A draft that passed editorial checks may drift into publication work. A preview issue may reopen a locked source. A successful production run may be mislabeled as a performance result.
Done is different from better
AI-assisted work repeatedly exposes the difference between stage completion and local optimization.
Imagine an English article that satisfies the brief, uses supported claims, and reads naturally. An audit suggests replacing three ordinary verbs with more varied choices. The change might make the prose marginally better. It does not automatically mean the stage is incomplete.
Now imagine the same audit finds that a confident sentence presents an unmeasured result as fact. That issue is material because it violates the evidence boundary. The stage cannot close until the claim is corrected or escalated.
Materiality keeps the workflow focused on the promise of the stage. A blocker threatens facts, evidence, privacy, safety, usability, routing, publication control, or another defined requirement. Optional polish can be noted without consuming a repair cycle.
This distinction is especially important when models produce detailed critiques. The quantity of feedback is not the same as the severity of feedback.
Prevent audit and repair from becoming a loop
An automated workflow can fall into ping-pong when one repair pleases one audit and triggers another. It shortens a sentence for humanization, then a brief check says the explanation is incomplete. It adds detail, then a style check calls the section repetitive. The system alternates instead of converging.
I use four rules to interrupt this pattern:
- Give each blocker a stable failure signature so the same issue is recognized across runs.
- Count actual mutations, not audit executions, against the repair budget.
- Before changing an artifact, identify which previously passing checks the change could affect.
- Escalate if the same blocker survives two targeted attempts, a repair reverses an earlier repair, or the cycle makes no net progress.
The purpose is not to make every audit agree about style. It is to resolve material conflicts while preserving facts and accepted strategy.
Downstream failure should not erase upstream completion
State boundaries protect completed work.
Suppose research has been validated, stored, and locked. Later, the website build fails because a component cannot render a table. That is an implementation problem. Repeating keyword discovery or a paid provider call would not fix it.
The same principle applies across the workflow. A Chinese phrasing issue should not reopen English research. A broken preview route should not rewrite a locked article. A deployment failure should not regenerate content. Only the dependencies affected by a change should be invalidated.
This is why durable artifacts matter. The workflow needs to know which exact input passed, what state it reached, and which downstream outputs depend on it. Completion cannot live only in a terminal buffer or the memory of a chat.
Backlog new findings without denying them
A clear stop condition does not require ignoring useful feedback. It requires routing it correctly.
When a non-material improvement appears after a stage passes, record it in a quality, editorial, implementation, or observation backlog. Include enough context to decide later whether the finding deserves a versioned change. Do not silently discard it, and do not automatically hold the current cycle open.
This allows a product or workflow to learn without treating every learning as an emergency. The current version can close on evidence. The next version can begin with a better informed starting point.
A compact stage template
The following template is usually enough:
| Field | Question |
|---|---|
| Stage goal | What specific outcome does this stage own? |
| Inputs | Which canonical artifacts and permissions may it use? |
| Acceptance criteria | What observable conditions must pass? |
| Audits | Which checks test those conditions? |
| Repair budget | How many targeted mutations are allowed, and what counts as material? |
| Stop state | What artifact or state proves completion or exception? |
| Next authority | What may happen next, and who can authorize it? |
The template is deliberately small. Its value comes from enforcing boundaries, not from producing more paperwork.
Define done before the workflow starts moving
The best time to set a stop condition is before an audit finds a problem. Otherwise the workflow is tempted to redefine success around whatever it has already produced.
For every stage, decide what it owns, what must pass, how much repair is allowed, what requires escalation, and where new non-blocking findings will go. Then persist the artifact and state that demonstrate completion.
AI can help a workflow move quickly. A definition of done makes sure that movement accumulates into reliable progress.