“Completed” usually answers the wrong question.
A runtime can reach a terminal branch, exhaust a loop, emit a final message, or stop after a tool call and still label the run completed. That label may be internally consistent while the user-visible output is wrong, incomplete, malformed, stale, or delivered to the wrong destination.
The operational fix is to record terminal state and acceptance state separately. Completion should describe what the workflow engine did. Acceptance should describe whether an explicit validator approved the outcome.
A useful state model keeps the distinction visible.
- Requested. The system accepted a task request.
- Started. Execution began with a recorded configuration and input identity.
- Terminated. Execution stopped, with an explicit exit reason such as success branch, error, timeout, cancellation, or configured limit.
- Acceptance checked. A named validator evaluated the resulting artifact or side effect.
- Accepted or rejected. The validator recorded a result and evidence. Unknown remains different from either.
97 completed labels contained a 39-run ambiguity.
In an August 2026 internal workflow sample, all 97 sampled runs were labeled completed. Of those same 97 runs, 39 also recorded exit_reason=max_iterations.
This does not mean 39 runs failed. The 39 records are a subset of the same 97, not a second denominator and not a measured failure rate. The metadata alone could not establish whether each result satisfied its intended acceptance criteria.
That is the finding: the status field could describe termination, but it could not independently prove correctness. This metadata-only sample used no customer data and is not evidence of customer outcomes or future performance.
Define acceptance at the boundary the user cares about.
An acceptance rule should be deterministic where possible and explicit where judgment remains. Depending on the workflow, it can test:
- Artifact presence: the required file, record, or message exists at the expected destination;
- Schema validity: required fields and types are present and malformed output is rejected;
- Semantic constraints: the answer addresses the requested entity, time range, or business rule;
- Side effects: the intended external action occurred exactly once and is tied to the run;
- Freshness and provenance: the result uses the required source revision or data snapshot;
- Safety gates: a protected action received the required human approval.
run.status = "terminated"
run.exit_reason = "max_iterations"
run.acceptance = validator.check(result, expected)
if run.acceptance.passed:
run.outcome = "accepted"
else:
run.outcome = "rejected"Illustrative state model, not framework-specific production code.
Report completion and acceptance as different metrics.
- Termination distribution: success branch, errors, timeouts, cancellations, and configured limits.
- Acceptance coverage: how many runs had a valid acceptance check, with unknown kept visible.
- Accepted-task rate: accepted outcomes divided by the defined evaluated population.
- Repair burden: retries and operator interventions needed before acceptance.
- Cost per accepted task: attributable cost divided by accepted outcomes, with missing cost evidence disclosed.
A dashboard can show both fields side by side. It should not convert missing acceptance evidence into success, and it should not convert a run-limit exit into failure unless the acceptance rule says the result was rejected.