Servitor Task Design: Success Conditions and Stop Conditions
The task is the servitor. If the sentence is vague, the construction is vague, and no amount of feeding fixes it.
Table of Contents
The grammar of a task
A usable task sentence has a verb, an object, a deadline and a success condition. "Send five proposals to venues in Bogotá before 30 November" has all four. "Be more visible" has none.
Write it in the second person, as an instruction to the construction: "You find...". This makes the task a clause of the contract rather than a wish in the operator's head.
Keep it to one sentence. A task that needs three sentences is three tasks, and a servitor with three tasks is a committee you cannot close.
Measurable or observable
Some tasks have numbers: clients, sales, sessions, pages. Others have observable events: a door reported, a decision made, a conversation started.
Choose the observable form before you start, and write what would count as failure. A task with only a success condition will always be read as a success.
If the task is internal, count behaviour: sessions done, proposals sent, words written. Internal tasks are easier to verify and where servitors are most useful.
One task per servitor
A servitor with two tasks is fed by two anxieties. When one task completes, the other keeps the construction alive, and the contract becomes ambiguous.
If you need two jobs done, build two servitors with different names and different marks. The cost is more bookkeeping; the benefit is that each one can end.
For a first servitor, choose a task you can finish in two to four weeks. A short loop teaches more than a year-long project.
Stop conditions
Write three stops: success, failure and interruption. Success closes the servitor. Failure closes it too, and feeds the next design. Interruption covers a change in circumstances: the project is cancelled, the client leaves, the goal is no longer wanted.
The interruption clause is the one people forget. A servitor built for a job you no longer want will keep holding attention on it until you close it.
Write the exit method next to the stop conditions: absorb, destroy or put away. One sentence is enough.
Revising without lying
If the task changes, close the old servitor and build a new one. Do not silently rewrite the task in the same container, because the old clauses remain in the operator's memory and the log becomes useless.
If you must keep the name, write a revision entry with the date, the old task and the new one. This is the only honest way to reuse a container.
A revision means the task was wrong and you noticed before the end date.
Worked examples
Commercial: "You find three paying clients for the November cohort before 30 November; success is three payments; failure is fewer than one." Operator action: five proposals a week.
Internal: "You keep me at the desk for four writing sessions a week until 15 December; success is sixteen sessions; failure is fewer than eight." Operator action: calendar blocks.
Spatial: "You report anyone entering the front room between midnight and six, once per event; success is a report that matches an agreed test; failure is no report in three tests."
The moving goalpost
The most common failure in task design is a sentence that changes after the result arrives. Three clients become "three serious clients", then "three clients or one big one", and the experiment loses its shape.
The defence is a written success condition and a written failure condition, both dated. When the result arrives, you read the page, not your memory of the page.
A second defence is to keep the number small. A task with a count of three is easy to evaluate; a task with a count of thirty invites reinterpretation because the gap is uncomfortable.
If you genuinely need to change the task, close the servitor and open a new one with a new name. The old log stays closed. That is not bureaucracy; it is what makes the next design better than the last.
Three sentence templates
Commercial: "You find [number] [buyer type] for [offer] before [date]; success is [number] payments at [minimum price]; failure is fewer than [number]."
Internal: "You keep me at [activity] for [number] sessions a week until [date]; success is [number] sessions; failure is fewer than [number]." The observable is the session, not the mood.
Spatial: "You report [event] in [area] between [hours]; success is a report that matches [test]; failure is no report in [number] tests." The escalation limit goes on the next line.
Practical checklist
- One verb, one object, one date, one number.
- Write both the success and the failure condition.
- Keep the task small enough to finish in four weeks.
- Put the operator's weekly action next to the task.
- Close on the date, then design the next one from the log.
The review meeting
Set a fifteen-minute review at the midpoint and at the end. Read the task sentence aloud, read the operator's action, then read the log without interpreting it.
The meeting has three possible outcomes: continue unchanged, revise with a dated entry, or close. Anything else is drift. Write the outcome on the page before you leave the table.
FAQ
Can a task be open-ended?
It can, but then it is a long-term guardian rather than a servitor. If you want an end, write one.
What if the task is completed early?
Close it early. The end date is a limit, not a target.
Can I change the success condition mid-task?
Only by closing and rebuilding, or by writing a dated revision. Silent changes make the log meaningless.
How specific should the number be?
Specific enough that you can count it without interpreting. Three clients, sixteen sessions, one report.
What if the task succeeds for the wrong reason?
Record it. A result that arrived through an unrelated route is still a result, but it does not confirm the construction. The next experiment should isolate the variable.
References
- Carroll, P. J. Liber Null. 1978; Liber Kaos. 1992.
- Hine, P. Condensed Chaos. 1995.
- Spare, A. O. The Book of Pleasure. 1913.