Before you hand work to software, write down the judgement calls it has to make.
Describe the task in observable terms
Name the trigger, the required inputs, and the output another person will use. “Improve reporting” is too broad. “Prepare a dated exception summary from approved data sources” gives the builder and reviewer something concrete to inspect.
Separate preparation from action
Collecting information, making a recommendation, and changing a live system have different consequences. Specify which steps can proceed automatically, which require review, and which should stop if evidence is incomplete.
Design the failure path
Inputs can arrive late, permissions can expire, and a source can change shape. Define what the workflow should do in each case. A useful failure message explains what stopped, what remains uncertain, and who should respond. Silent partial completion is difficult to trust.
Make handover part of acceptance
The work is not ready merely because it ran once. The owner should know how to rerun it, inspect its output, and recover from common failures. Include these behaviours in the acceptance review, alongside the business result.
Clarity → sequence → system → compounding.
Explore how this thinking becomes a named YERID output, or start with the Growth System Diagnostic.
