Write the stop condition before extending the pilot

“We will review progress later” leaves the pilot’s continuation rule unclear. A useful stop condition identifies what would cause the owner to pause, narrow or end the work.

Begin with the decision the pilot is meant to inform. If the question is whether a support-drafting workflow reduces total handling effort, define what evidence would answer it: baseline effort, drafting effort, review effort and exception work for a comparable set of cases.

Name a decision owner and the evidence they need. State the boundary of the pilot: users, data, workload and allowed actions. Then write the trigger. It might be an unacceptable failure pattern, missing evidence, costs above a stated limit or a useful result that appears only for a narrower set of cases. Use thresholds appropriate to the real work; do not copy a fictional example as policy.

A narrow decision is still a decision. The outcome can be to fund a bounded next step, restrict the use case, defer until a missing dependency is resolved, or stop. Recording the alternative and its reason makes the next discussion more useful than treating every pilot as a commitment to scale.