Trigger, tools, validation, human approval

A workflow specification is four sentences long if you are disciplined about it. This page turns those four into a concrete example you can adapt.

Begin with the trigger. Suppose the run starts when a file named invoice-2026-Q4.csv appears in a watched folder. The trigger is not "when finance sends something" — it is a named file event with a defined polling interval. Write it that way in the specification and the reviewer can confirm the system will begin when and only when you intend.

Next, tools. For this illustrative example, the run may read the watched folder and write to a single output spreadsheet. It may not send email, may not touch a payment system, and may not modify the source file. Two tools, both enumerated. Any expansion requires a revision to the specification, not an edit in the code.

Validation follows. Each row parsed must have a vendor name, an amount, and a date in ISO format. A row missing any of those fails validation and is routed to a review list rather than silently dropped. The pass condition is observable: a count of valid rows equals a count of source rows, or the difference is explained by items on the review list.

Finally, the approval gate. Nothing leaves the machine until a person opens the output spreadsheet and confirms it. In this illustrative example the gate sits before the spreadsheet is shared with anyone else — sharing is the external side effect, so approval precedes it.

• Trigger — file named invoice-2026-Q4.csv appears in watched folder; poll every 15 minutes.
• Tools — read watched folder; write to output spreadsheet. No mail, no payment, no source edits.
• Validation — vendor, ISO date, and amount present on every row; failures route to a review list.
• Approval — person confirms output before it is shared; sharing is the external side effect.

Further reading

• Privacy and user review, no promise of employment
• Reliability, failure handling and acceptance criteria