Think of this as a review framework, not a fixed architecture. Identify what starts the work, how it is checked, which actions happen and what proves the result. AI is optional; validation and ownership are not.
What starts an automation?
The trigger starts a run: a message, a submitted form, a new file, a schedule or a deliberate click. A manually started process can still automate the steps that follow.
Choose the trigger around the workflow. Some tasks should start immediately; others should wait until a person confirms the input is ready. More automatic is not always more useful.
What decides whether a case continues?
The filter. It checks whether what arrived belongs in this process at all, and which of several paths it should take.
The filter prevents unrelated inputs entering the wrong process. For example, an invoice pipeline should not treat a job application as an invoice just because both arrive in the same mailbox.
Where does the actual work happen?
In the actions. Sending a message, writing a record, moving a file, producing a document. Most processes have several in sequence, each doing one thing.
Actions need careful design too. A retry must not create duplicate records or send the same message twice. Access permissions and recovery behaviour can be more important than the action’s visible simplicity.
What is the intelligence layer for?
Use interpretation where explicit rules are not sufficient: classifying varied messages, extracting proposed fields or preparing a draft. A model is one option, and its output still needs validation.
Models are not the only source of quiet errors. A wrong mapping, missing field or faulty calculation can also produce a plausible result. Validate each consequential step; use confidence scores only where their meaning has been tested.
Why does formatting get its own part?
Because data almost never arrives in the shape the next step needs. A date in the wrong order, a name with a title attached, an amount carrying a currency symbol, a paragraph that has to become one line in a table.
Make transformations visible in the specification and test them against expected outputs. Dates, decimal separators, currencies and identifiers deserve particular attention when several systems are involved.
What counts as the output?
The result might be a saved document, a prepared draft, an updated record or a confirmed decision to take no action. Define what evidence shows that the intended outcome actually happened.
Measure useful outcomes alongside errors, review effort and operating cost. Run counts describe activity; they do not establish that the process saved work or improved quality.
How do the six fit together in one case?
An email arrives: the trigger. The process checks the input and permitted sender: the filter. It proposes a property reference and document type: interpretation. It validates those fields and prepares the agreed filename: formatting and checks. After any required approval, it files the document and records the result: actions and output. An uncertain reference goes to review before anything is moved.
What should a proposal explain beyond the happy path?
Ask what happens when a tool is unavailable, an input is incomplete or a run is repeated. Specify who receives the exception, what may be retried and how an incorrect change can be reversed.
Walk one ordinary case and one difficult case through the proposed design. If the owner, stopping point or success evidence is unclear, settle that before expanding the build.
