The Video Assistant · 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 VAR's manner. But there is a catch: a briefing only works as well as it is clear. Tell the VAR merely to “help with the football” and you have said almost nothing — so you get a different, often unhelpful answer every time.

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

It is the difference between telling a VAR “do your best” and handing them the match's playing conditions — exactly what to watch for, how to signal, what to do in a close call. The more precisely the job is defined, the more consistent every decision becomes.

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

Sharpest of all is the piece that tells the model what to do when it cannot tell. Without it, an unclear check still gets a confident verdict; with it, the VAR is allowed to say so.

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

A vague briefing — the VAR barely knows what you want. Add a piece.
Vague
the briefing · system prompt
+ ↓
the incident · unchanged
↓
the VAR'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 football” 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.
      

      

        
Quick check

        
Two VARs get the same incident but give very different answers. The most likely cause?

        

          
          
          
        

        

      

      

        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 ON-FIELD DECISION STANDS 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 penalty may fall apart on a marginal one
          or a freak incident. 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 a VAR is any good at all.