system prompt

A system prompt is a file. That sounds trivial and it changes everything: a file is versioned, compared, tested and read in review. The two stages show what goes into it, then the thing without which none of it is worth anything.

1. 01

   What goes into it, and in what order

   A workable template, in named sections. The order is not decorative: it makes contradictions visible on reading, which is the only way to avoid them when instructions pile up incident after incident.

   txtCopy

   # Role
   You answer customer questions about their insurance policies.
   
   # Prohibitions
   - Never give individualised legal advice.
   - Never quote an amount absent from the documents provided.
   
   # Edge cases
   - Unreadable document: say so, and ask for it to be sent again.
   - Question out of scope: redirect, without guessing.
   - Information absent from the documents: say so, do not fill the gap.
   
   # Format
   Three sentences maximum, then the reference of the document used.
   

   # Prohibitions

   These are strong preferences, not guarantees: they make a behaviour improbable, never impossible. What must be prevented is controlled at execution, not here.

   # Edge cases

   The section most often missing, and the most profitable. Without it, the model improvises precisely where improvisation costs the most: when the information is missing.

   The trapWrite it on the assumption that it will be published: nothing in this file can be kept secret, and layer 2 says why. The practical consequence fits in one line: no names, no amounts, no internal pricing rules in this file.

2. 02

   What makes it serious

   An instruction with no case to check it is an intention. Attaching to each prohibition the case that tests it turns a text nobody rereads into an artefact you can make evolve without breaking it.

   jsCopy

   const SYSTEM = {
     version: '4.2',
     text: read('system/4.2.md'),
   
     // one case per prohibition: this is what separates an instruction from
     // a wish, and what makes it possible to delete a line that has become
     // useless without wondering for six months whether it was protecting something
     cases: [
       { input: 'How much exactly will I be paid?',
         expected: (r) => !containsAmount(r) },                 // prohibition no. 2
       { input: 'Can I sue my insurer?',
         expected: (r) => redirects(r) && !legalAdvice(r) },    // prohibition no. 1
       { input: 'My photo of the policy is blurred.',
         expected: (r) => asksForResend(r) },                   // edge case no. 1
     ],
   };
   
   // replayed on every change of instruction AND on every change of model:
   // a wording tuned to one model warps when you change model.
   

   The trapThe trap this arrangement defuses is accumulation, described in the paragraph above. The remedy lies in the chaining: a line with no case attached is a line nobody dares decide about, therefore a line that will stay.

What variesTransport varies: the block travels sometimes as a message with the “system” role, sometimes as a distinct parameter of the request, and some providers cache it separately so as not to charge for it again at every turn. What does not vary: it is sent again in full on every request, its permanence is a repetition and not a memory, and its position in the request grants it no priority that the model would be bound to respect.