Why I Keep the Model on a Short Leash

This is a sample article that ships with the template — replace it with your own writing. The text below is here so you can see how a finished post reads: the layout, the pull of the first paragraph, and how long a post feels at the default reading speed.

When I first wired a language model into Quillboard, I did what everyone does: I wrote a long, polite prompt and trusted it. It worked in the demo. It also, on the third day, answered a question about a document that had never been uploaded, with total confidence.

The fix was not a better prompt. It was a smaller job for the model. Retrieval happens first, in ordinary code, and returns a handful of passages with their sources. The model is handed only those passages and one instruction: answer from them or say there is nothing relevant. Then a second, equally ordinary step checks that every quoted phrase in the answer really appears in the passages it cites, and drops the ones that do not.

None of that is clever. That is the point. Code is good at counting, matching and refusing; models are good at reading, summarising and phrasing. Letting each do its own job meant the failures became boring and findable, which is the best thing a failure can be.

Two habits came out of this. First, write the guarantee down as a test before you write the prompt: "an answer never cites a source that was not retrieved" is a test you can run on every change. Second, keep a small file of real questions that once went wrong and replay it whenever anything upstream changes — the model, the chunking, the prompt.

If you take one thing from this sample: decide what must always be true, and then put it somewhere a model cannot argue with it.