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.

The first version of Ledgerly stored a balance on each user. It was fast and simple, and it drifted: a retried request here, a half-finished settlement there, and soon the numbers no longer added up to zero, which in a shared-expense app is the one thing they must do.

The second version stores only facts. Every expense and every payment is a row in an append-only ledger, and a balance is simply the sum of the rows that mention you. There is nothing to drift, because there is nothing to keep in sync. If two sums disagree, one of them is wrong in a way you can find.

Idempotency came along for free once there was a ledger. Every write carries a client-generated key, and a unique index on that key means a double-tap, a flaky connection and an impatient retry all collapse into one row. The settlement screen can be as eager as it likes.

The cost is that reads do more work. For a household of six this is irrelevant; for a trip of sixty with a year of history it is not, so there is a materialised summary that is rebuilt from the ledger and can always be thrown away and rebuilt. The ledger is the truth; everything else is a cache.

The lesson is general. When you can choose between storing a conclusion and storing the evidence for it, store the evidence.

Harbor Kit started as a collection of components I kept rewriting. The thing that made it a library rather than a folder was deciding that every component would come with a behaviour contract: what happens on Tab, on Escape, on arrow keys, and what a screen reader hears when it opens.

Writing the contract first changed the code. A dialog is not a div with a backdrop; it is a place focus moves to, stays inside, and returns from. Once that sentence is written down, it becomes a handful of tests, and the tests keep working long after you have forgotten why the code looks the way it does.

Reduced motion got the same treatment. Instead of sprinkling checks through the animations, the library exposes one setting that every animated component reads, so a visitor who asks for less movement gets less movement everywhere, including in places I would have forgotten.

The unexpected benefit was speed. Components with clear contracts are easier to compose, easier to review and easier to hand to someone else. Accessibility did not slow the work down; it was the specification the work had been missing.