Make it repeatable

The situation

It is Thursday. The brief that has run clean since Tuesday comes back with three blocks instead of four, and a paragraph of advice at the bottom that you explicitly ruled out. Nothing changed at your end. Same three files, same message.

Then someone who saw Tuesday's output asks you to send them the instruction. You go looking. It is inside a message, seventeen replies down, in a thread you have since renamed. You find a version of it. You are not certain it is the version that worked.

Two ordinary Thursday problems, one cause. The instruction that produced a good result on Tuesday was never treated as something you own.

The principle

An instruction is proven repeatable only when it returns the same output shape from inputs it was not written against.

One good run proves almost nothing. You wrote the instruction while looking at Monday's file, so Monday's file is the one set of inputs it is guaranteed to handle — every rule was fitted to rows you could see. The real tests are the quiet week where three of the four blocks are empty, and the morning the export arrives with a column missing.

Three runs against inputs you did not have in front of you is the cheapest proof available, and two of the three should be awkward. If the shape holds, you have an instruction. If it held once, you have a result.

Worked example

Shown here in Gemini.

The fix for both Thursday problems is the same four lines, sitting above the instruction text.

# ops-brief — v3 — 2026-08-04
# Changed: added "print the heading even when the block is empty".
# Reason: v2 dropped the AT RISK block on a quiet Wednesday.
# Ran against: Mon 07-27 normal · Wed 07-29 quiet · Fri 07-31 short export

A name, a number, a date, and the one line that changed with the reason it changed. Ninety seconds of typing. Now the instruction is sendable — a colleague gets ops-brief v3, not a screenshot of a good day — and drift is diagnosable: you can see which edit you are living with.

The three runs underneath it are the proof. Logged plainly:

Run  Input                     All 4 blocks?     Lines traceable?   Verdict
1    Mon 07-27, normal day     yes               6 of 6             pass
2    Wed 07-29, quiet day      no — AT RISK gone 4 of 4             fail
3    Fri 07-31, short export   yes               5 of 7             fail

Run 2 broke the shape: on a day with nothing at risk, the block disappeared instead of printing "None". Run 3 kept the shape but broke the standard — two lines named quote numbers that were not in the export, which is what happens when a truncated file is treated as a complete one.

Both got fixed by editing the instruction, not by asking again. That distinction is the whole lesson: a retry gives you a different sentence from the same instruction, a version gives you a different instruction. Run 2 produced v3. Run 3 produced v4, which added one line — if a quote number appears in one file and not the other, list it under what you could not read.

Keep the numbered text somewhere plain that you control. Name it for the job it does: ops-brief is findable in six months, final-brief-new is not.

In your tool

Every one of these holds exactly one current version. What matters is what happens to the previous wording when you save a change.

Product surfaces checked 2026-08-04.

Four tools, one answer: the old wording is gone. That is why the numbered history sits in a file you control. Where the current version lives is Unit 2's job.

Try it

Take the brief you built for your Unit 0 task. Give it a name and v1, and put the four header lines above it: name, version, date, and what you ran it against.

Then run it twice more on last week's file. First unchanged. Then on a copy with one column deleted and three rows removed — you do not have to wait for a bad week to arrive, you can make one in ninety seconds.

You are done when you can name which run broke the shape and the single line you added to the standard because of it. The quiet week is the third test and cannot be manufactured — write it into the version log as a run still owed.

Common failures

• Calling a retry a version. The output disappoints, you send the same instruction again, the second answer is better, you move on. Nothing has been fixed. The next person to run it gets the first answer, and so do you next Thursday.
• Editing by feel. Every disappointing output triggers a small rewrite, and after a month nobody can say what the instruction guarantees. One line per version, the reason above it, and stop once the shape holds three times.
• Testing on the easy week. Repeat runs against well-behaved inputs only prove that well-behaved inputs behave. The runs that teach you something are the broken file, which you can make at your desk, and the quiet day, which you have to wait for and then remember to use.