Fictional workflow QA demo —

Fictional workflow QA demo — five failure cases

Invented input, created with AI assistance and reviewed before publication. This is not paid client work. The expected outcomes below are proposed acceptance criteria, not executed test results.

The six-step example: receive a request → validate fields → classify it → log it → email an acknowledgement → notify the owner. In this deliberately flawed version, invalid input has no route, the log continues after failure, acknowledgement is recorded before sending, and IDs come from timestamps.

Five checks:

Missing email: retain a NEEDS_REVIEW record and alert the owner; send no acknowledgement.

Logging failure: stop before emailing a reference that was never stored.

Uncertain email send: mark UNCERTAIN and reconcile delivery status. Never blindly retry after a timeout.

Repeated event: use a stable provider event ID or explicit idempotency key. A matching email/text hash only flags a possible duplicate; it must not silently merge valid new requests.

Unknown category: route to owner review instead of silently guessing support/normal.

The correction: explicit request and acknowledgement states, success-only transitions, and one review path with reason codes. Agree retention and collision handling before implementation.

Static review only: no n8n execution, production-system testing or measured delivery-time claim.

My small offline review service covers one redacted export, up to 10 steps, five failure-case instructions and a findings report. Start with invented or redacted data and an intended outcome: https://contra.com/s/E2XARkom-offline-workflow-review-five-failure-cases