Unit 02.04: Writing the task so someone else could check it
The task definition is the artefact a reviewer reads. It should be complete enough that they can check the run against it.
Goal, inputs, instructions, output shape, ceilings, outcomes
Six sections, each one a decision someone can disagree with.
Below is a task and runs five structural checks against it.
{
"goal": "decide whether INV-1187 is inside the 30-day payment window",
"inputs": [
"the invoice record",
"the contract payment terms"
],
"instructions": [
"use only the two inputs above",
"if either is missing, stop and name which",
"never estimate a date that is not written down"
],
"output": {
"decision": "inside|outside|unknown",
"days_elapsed": "int",
"terms_quoted": "str"
},
"stopping_rules": {
"max_steps": 8,
"max_minutes": 5,
"max_actions": 3
},
"outcomes": [
"success",
"escalate",
"failure"
],
"escalate_when": [
"either input missing",
"terms and invoice disagree"
]
}
OK goal names a decision
OK every instruction rules something out
OK output is a shape, not prose
OK stopping rules exist
OK there is a third outcome
The output field is a shape rather than a description. That is what lets a check run automatically - decision must be one of three values, days_elapsed must be an integer - instead of a person reading prose and forming an opinion.
The five checks are worth running on any task definition, including ones you inherit. A task missing its stopping rules or its third outcome will behave in ways nobody specified, and the checks find that in seconds.
The mistake this prevents
The mistake is writing the task as a paragraph of prose. It reads fine, it cannot be checked, and the missing pieces - the ceilings, the escalation condition - are invisible because prose does not have empty fields.
Takeaway
Write the task as structured fields and run the structural checks. A paragraph hides its own gaps; a field that is missing is obvious.
