B MASHINA and the Goal Servitor: Turning a Wish Into a Countable Action

A goal-achievement construct is the most requested thing in this catalogue and the least specified, and the reason is a single word. A goal cannot be reviewed. Nothing in the world is obliged to register whether a goal was achieved, so a construct specified to achieve one has been given a job with no completion condition, which is the description of a practice that cannot be assessed and therefore cannot be improved. The machine metaphor in the name is the most honest instrument in the whole servitor catalogue, because a machine has a yield, a maintenance interval and a failure mode, and all three of those are things you can write down.

A goal is a wish, and a wish has no review

The substitution this article is built around is small and does all the work. Keep the goal. Replace the function. A goal named as a function, such as getting healthier or being successful, is a state of the world, and states of the world arrive from the world. A function named as an action, such as three sessions a week, or one email a morning, is something a construct can be pointed at and a person can be counted against. The goal stays as the reason. The action is what gets specified.

This is the same substitution that makes any working reviewable, and it is the reason a spec you cannot count is a spec you cannot run. A construct running three sessions a week has a yield you can count at the end of the month. A construct running get healthier has nothing, and a practitioner who cannot count will conclude the practice failed, when in fact the practice was never given a test.

The five fields, and the two that carry the whole practice

Function, written in the imperative, one sentence, naming the action and the frequency. Refusal. Trigger. Sign. Cost. Four of those five are instrumentation and two of them are the practice, and the two are the function and the refusal. Everything after that is bookkeeping, and the amount of time spent on bookkeeping is inversely related to how clearly the function was written.

A worked example, written in the shape you should use. Function: run, on three scheduled days each week, the twenty minutes of work named in the specification, and stop when the timer ends. Refusal: it does not choose the days, it does not add days when a week is missed, and it does not substitute a different activity for the one named. Trigger: a fixed weekday morning, twenty minutes, before any message is read. Sign: one line in a paper log, dated, with a tick or a cross. Cost: twenty minutes a day and a piece of paper. Note what is absent. There is no mention of the goal, of progress toward the goal, or of whether the goal is being achieved. The goal is what the twenty minutes are for.

Why the machine metaphor is the honest one

A machine is specified, it produces an output on a schedule, and it fails in identifiable ways, and none of those properties require anyone to believe anything. A machine also has three properties people forget when they anthropomorphise one. It has a yield, which is lower than its theoretical maximum and predictable once you have measured it. It has a maintenance interval, and skipping maintenance shows up as a change in yield rather than as a sudden failure, which is why the month-end count matters more than the daily impression. And it has a failure mode, which is a specific known shape rather than a mood.

The useful consequence is that the machine framing tells you what to log. You do not log how the machine felt. You log units out, over a period, which is exactly the number a workshop tracks. Once you have three months of units out you know your yield, and once you know your yield you can decide whether the machine needs a better fuel or a smaller job.

What a machine cannot do, and the temptation that arrives anyway

A machine does not decide what to work on. This is the single most common failure in the goal category, and it presents as an increase in activity rather than as a problem. The practitioner cannot decide which task the construct should prioritise, adds a third session, feels busier, and has in fact replaced a decision with a schedule. The refusal clause is what prevents it: it does not choose the days. A construct that can choose its own work is a construct that has acquired the job you were avoiding, and it will perform that job with great diligence.

The second temptation is counting the wrong thing. The machine's output is the action, not the outcome. Counting the action is uncomfortable because a month of ticks can coexist with a goal that has not moved, and the discomfort is the point: it separates the part you control from the part you were hoping to control, and the ratio between them is the honest scorecard for a thirty-day run.

A test that can fail, run before you build

For one week before the construct exists, do the twenty minutes on the scheduled days and log it the way the construct would require. Three of seven is a realistic week for most people starting something, and three of seven with no construct at all is the baseline you will be comparing against. If you get five of seven with nothing built, the construct is unlikely to show you anything in a month, and the honest conclusion is that the specification needs to be smaller rather than that the practice is broken.

Write the expected count down before the week starts, not after. A prediction recorded afterwards fits whatever happened, and the whole point of a test is that the number could have come out differently. One week is enough to catch a specification that is too large, which is the failure that ends most of these before they begin.

Five ways a goal construct goes wrong

The unspecifiable function, where the field names a state rather than an action, and the month-end review then has nothing to record. The action that was already happening, where the chosen twenty minutes duplicates something the practitioner does anyway, so the count looks healthy and the construct has added nothing. The sign that is the existing habit, where the mark is drawn somewhere already looked at, and the retrieval cue is therefore worthless because the day already retrieves it. The outcome substitution, where a month of actions is judged by whether the goal moved, and a correct practice is declared a failure. And the construct-as-justification, where having built something for the goal makes starting feel like the remaining step, and the count is zero for three weeks because the machinery was mistaken for the work.

What thirty days should cost, and what the expensive path is really selling

A notebook, a pen, and twenty minutes a day. A moon-phase app is unnecessary, because the schedule is a weekday and the weekday does not move. That is worth stating plainly because the goal category is where expensive apparatus is most often sold, and the reason it is sold here is specific: a device makes the practice feel like it has progressed past the point where you would otherwise have to start the twenty minutes.

If you buy anything, buy it after the first month-end count, and only if the count says the practice is going to continue. The right question about any purchase in this category is whether it changes the number at the end of the month. A tool that does not change the number is a subscription on a practice that has not been shown to work, and the first month is the cheapest possible time to find that out.

Frequently Asked Questions

How do I write a goal servitor function?

Name an action and a frequency, in the imperative, with no outcome in the sentence. Run the twenty minutes named in the specification, three days a week is the most common first size, and stop when the timer ends. If the sentence could be satisfied by having a good week, it is a goal, and a goal cannot be reviewed. If it can only be satisfied by having done the thing the number of times you said, it is a function.

Should a servitor be able to choose what I work on?

No, and the refusal clause that stops it is the most useful line in the specification. A construct allowed to choose its own work will take on the decision you were avoiding, and it will take it with real diligence, which is what makes the substitution so easy to miss. You choose the work. The construct runs the machine you specified.

I did everything for a month and nothing in my life changed. Did the practice fail?

Almost certainly not, and the reason is the substitution the whole article rests on. The count you kept was actions, and actions were the thing the construct was built to produce. A month of actions is a successful run of the practice and a separate question about the goal, and the second question was never inside the specification. Most disappointing results in this category come from judging a correct construct against a promise it was never given.

How many goals should I run constructs for at once?

One, and the reason is not focus, it is bookkeeping. A construct is four fields plus a monthly count, and two constructs competing for the same twenty minutes will both underperform in a way that looks like failure rather than like a scheduling problem. Finish the month-end count on the first one before a second is specified. Once the routine is boring, a second becomes cheap.

Is a goal servitor worth the cost of building?

The build costs twenty minutes and a sheet of paper, so the honest question is not whether it is worth the cost but whether you will do twenty minutes a day for a month. Most practitioners who abandon these did not abandon them at the construct, they abandoned them in week three, and nothing purchased changes that. Run the one-week baseline first and the answer arrives before any money is spent.