The Third Umpire · Lesson 3 — The Specifics ← Course

The specifics — a sharper system prompt.

A briefing only helps if it is specific. Vague instructions give vague, unpredictable answers.

On the last page, swapping the briefing changed the umpire's manner. But a briefing only works as well as it is clear. Tell the umpire merely to “help with the cricket” and you have said almost nothing — so you get a different, often unhelpful answer each time.

The fix is to be specific. A sharp briefing pins down a handful of things: the role the model should play, the rules it should follow, the format its answer should take, the tone to use, and what to do when it is unsure. Each piece you pin down is one less thing left to chance.

It is the difference between telling an umpire “do your best” and handing them the match's playing conditions — exactly what to watch for, how to signal, how to handle a close call.

And consistency is the real prize. A vague briefing might give a fine answer once and a poor one the next time; a specific one makes the good answer the reliable one.

Sharpest of all is the piece that says what to do when the model cannot tell. Without it, an unclear appeal still draws a confident verdict; with it, the umpire is free to admit the doubt.

Start from a vague briefing and add one specific piece at a time. Watch the umpire go from a confident guess to an honest one.

A vague briefing — the umpire barely knows what you want. Add a piece.
Vague
the briefing · system prompt
+ ↓
the appeal · unchanged
the umpire's call

The same one argument — just sharper.

Nothing new in the code: it is still one system string. Being specific is not a feature you switch on — it is just a clearer briefing.


      

Vague in, vague out.

A briefing that just says “help with the cricket” leaves the model to guess — so it rambles, hedges, and answers differently every time. Each specific piece you add — a role, the rules to apply, the format to use, what to do when unsure, the tone — removes a guess and makes the next answer more predictable.

A good system prompt is not longer for its own sake; it is specific. Say who the model is, what to do, how to answer, and what to do when it is not sure.

Next: the examples →
Go deeper — writing a briefing that sticks optional

Specific beats long

More words is not the goal — a short, precise briefing beats a long, woolly one. Every line should remove a guess; if a sentence does not change what the model does, cut it (and save the tokens, from Lesson 2).

State the format you want

The quickest way to get a format is to ask for it plainly — “reply in one line: the verdict, then a reason” — so the model is not left to invent its own. There is a stronger move than spelling it out, which the next lesson takes up.

Plan for the unclear case

Most weak briefings only describe the easy path. Saying what to do when the evidence is thin — here, “say INCONCLUSIVE rather than guess” — gives the model a safe option it would not otherwise take. It is not, as a later lesson shows, a cure for confident invention.

Test it on the hard appeals

A briefing that works on the obvious edge may fall apart on a faint one or a freak delivery. Try it against the awkward cases, not just the easy one — the same instinct the course returns to much later, when it asks how you'd measure whether an umpire is any good at all.