Practical AI
Give every automation a visible receipt.
A scheduled task needs evidence that the intended result happened, plus a clear route for exceptions.
An automation can appear to be running while the useful part of the job has stopped. A report may be generated but never delivered. An enquiry may be captured but never assigned. Before making a recurring task part of normal operations, decide what evidence will show that its purpose was achieved.
Define the result, not just the activity
Start with a sentence that describes the business outcome. For a hypothetical weekly stock report, “the job ran” is weaker than “the current report reached the agreed location and the operations owner can open it”. The second version gives you something concrete to check.
Separate the stages if different things can fail. Creation, delivery and access are different checks. A successful first stage must not conceal an unsuccessful last one. Keep the evidence proportionate: a timestamp, destination and result reference may be enough. Avoid copying sensitive report contents into monitoring logs.
Make missing results noticeable
An automation that has been disabled cannot reliably send its own failure message. Use a separate check where the consequence of silence warrants it. That check should compare the expected result with the latest recorded result, rather than simply reading whether the task is switched on.
Allow for normal variation. If a task intentionally skips days with nothing to process, record that as an expected outcome. Agree a sensible delay before alerting so an unusually long run does not immediately become an incident. Choose the checking frequency to suit the business consequence.
- What result should exist, and by when?
- Which evidence distinguishes completion from a partial result?
- Who receives an exception, and what can they do?
- How will an intentional skip differ from an unexplained gap?
Recover without repeating the action
Before retrying, inspect what actually happened. A delivery receipt may be missing even though the destination received the item. Give each intended action a stable reference so the recovery process can check for an existing result before sending, creating or publishing another copy.
Test this with harmless sample data: stop one stage, observe the alert, then recover. Check that the owner understands the message and that recovery produces one intended result. A monitoring rule that nobody can act on is unfinished work.
Choose one existing automation this week. Write down its expected result, evidence and exception owner. If you cannot identify its last confirmed outcome, start there before adding another automated step.