Workflow-Success vs Business-Validity Gap
Anti-pattern: a terminal success status from the agent or its workflow engine is read as proof the deliverable is business-correct, when it certifies only technical completion.
Problem
Technical completion and business validity are two different properties, and the exit signal only measures the first. A run that finishes without error has proven that the steps executed, not that the deliverable is right for its purpose: a generated article can be on-format, on-length, and on-time yet factually wrong, off-brand, or unpublishable. When the green status is trusted as a quality verdict, business-invalid output flows downstream unreviewed and is discovered only by a customer, an auditor, or a regulator, long after the run was marked done.
Solution
The remedy is to split the two signals and never collapse them. Keep the workflow's terminal status as a statement about execution only, and add an explicit business-validation step that scores the deliverable against the rules that decide whether it can ship: factual grounding, brand and policy conformance, completeness against the brief, and any domain checks the format alone cannot express. A run that exits cleanly enters a held state pending that validation rather than a published state. Surface the two outcomes separately on the dashboard, so a green execution status with a failing business check is visible as a problem rather than hidden behind a single tick.
When to use
- A workflow or agent harness publishes a terminal success status when a run finishes.
- A controller, dashboard, or operator decides what to ship based on that status.
- The deliverable has business-correctness rules that a clean exit and a valid format do not capture.
Open the full interactive page →
Diagram, neighbourhood map, code examples, related patterns and full provenance.