We wrote six acceptance tests. Did our automation actually pass any of them?
Writing a good acceptance plan is useful. Seeing a green workflow execution is useful. Neither is the same as demonstrating that the customer's intended result was completed, and neither authorizes the developer to sign off for the customer.
Original fictional experiment · No client data
The practical problem isn't generating six more test cases. It's connecting the before (what the owner said should happen) to the after (which source, execution and downstream records were actually inspected) without claiming a result that the records cannot prove.
Before: specify the business result, not a green node
A fictional small shop wants new booking requests to create exactly one accepted sandbox CRM request within five minutes. The scope describes a source form, a stable pseudonymous request key, a destination lookup, a duplicate rule, a safe failure policy and an approving role. Moruneva's free Automation Scope to Acceptance can turn that draft into six proposed checks: expected path, missing arrival, green run with no result, duplicate arrival, timeout or partial side effect, and client acceptance.
Those checks are all NOT TESTED when the plan is generated. The existence of a test plan is not evidence that its test happened.
After: three independent snapshots
Suppose an authorized operator later exports pseudonymous CSV excerpts. The fictional data used by the lab are:
Webhook observations: 5 supplied rows Workflow executions: 6 supplied rows Downstream receipts: 5 supplied rows Expected source events: 6 supplied rows
The existing Webhook Delivery ID Audit sees one repeated delivery observation and one merchant event correlated across different delivery IDs. These are not automatically two merchant orders or two successful CRM writes.
The existing Outcome Reconciler sees two supplied success-status rows without matching receipts, one expected source without an execution, a receipt without a matching execution and other conflicting or incomplete evidence. These categories can overlap; adding them would falsely inflate the number of supposedly lost orders. The lab deliberately does not join the independent webhook log to CRM records.
Side by side: proposed test vs what the snapshots can support
| Proposed scenario | What the fictional snapshots show | What still needs a human |
|---|---|---|
| Expected path | Execution and receipt row totals exist. | Verify a specific eligible request reached the correct business destination before the deadline. |
| Missing arrival | A source-without-execution category was flagged. | Check complete windows, source filters and original logs; do not call one count a lost order. |
| Green run, missing result | Two success-without-receipt matches were flagged. | Query the actual CRM with authorization; the supplied receipt file could be incomplete. |
| Duplicate arrival | One repeated webhook observation was seen. | Review the agreed idempotency scope and independent destination writes. |
| Timeout / partial side effect | Some unsuccessful states or unmatched receipts may exist. | Inspect durable writes before attempting any replay; require permission. |
| Client acceptance | No record of customer sign-off was supplied. | Ask the authorized reviewer to accept, reject or request more evidence. |
Crucial distinction: even when the tool flags no issue in one category, that is only not flagged in the supplied snapshot. It is never a PASS. Missing records, stale exports and unverified time windows remain possible.
Run four reusable blocks, not four rounds of copying and pasting
The free Acceptance vs Observation Workbench loads an unverified Acceptance draft (the same JSON exported by the planning tool) and authorized, pseudonymous CSV records. In one local calculation it calls the existing Acceptance Builder, Webhook ID Audit, Outcome Reconciler and Workflow Handoff Pack. It presents six scenario-specific questions and downloads a redacted JSON or readable TXT for the next reviewer.
The exported report contains fixed categories, counts, missing field names and requested follow-up checks; it does not export the original planning descriptions, raw webhook records, customer IDs or CRM keys. The original Acceptance Builder JSON, by contrast, does include the user's descriptions, so sharing that source file requires separate review.
The program rejects forged approval fields and mismatched generated acceptance checks, but it cannot cryptographically prove that the original planning text was not edited. A machine or Agent may supply a draft, but the software cannot treat a source-channel label as authorization, nor can it grant itself a right to retry payments or write to a live CRM.
When this is unnecessary
For a one-off small workflow with reliable native logs, a straightforward spreadsheet and an accountable reviewer are often sufficient. Shopify's webhook troubleshooting and signature verification guidance, delivery troubleshooting and n8n's executions view remain authoritative starting points. Use your actual destination system to establish the result. Moruneva has no access to these external accounts and cannot recover missing customer records itself.
The paid-product hypothesis is narrower: some repeat operators may want authorized connections, recurring checks, maintained evidence windows, reviewer assignments and historical approval records. That is not yet proven demand. A local four-block experiment is a way to learn whether this handoff saves work, not a claim of existing customers or subscription revenue.
Try the fictional four-block review →
Source references are public official documentation; internal example and all numerical observations are synthetic. Updated October 29, 2026. No automated sign-off, real client, released payment, recovered revenue or independent compliance certification is claimed.