01Three real levers, not one
Instruction modules for behaviour, golden examples bound to a task's schema, and retrieval tuning — each one measured, not guessed at.
The first two weeks felt like magic. Then it plateaued, and the only lever anyone has left is rewriting the prompt until this week's failing case passes — with no way to check what else just broke.
A reviewer's correction on finding F-03 becomes a bound golden example and an eval case in the same click. The eval suite score across five releases — 74% to 96% — is the same 36 cases run every time, not an impression.
The first two weeks felt like magic. Then accuracy plateaued around 80% and every attempt to push past it either does nothing or breaks something that used to work.
Someone rewrites the prompt to fix a case that came up in a demo. Three other cases that used to pass now fail, and nobody notices until a customer does.
A human corrects a wrong output every day. The correction fixes that one instance and teaches the system nothing — the same mistake shows up again next week.
Changing wording until this week's failing case passes, with no way to check what else moved. Improvement becomes indistinguishable from luck, because nothing is measured before or after.
A stronger model narrows a capability gap. It does nothing for a retrieval gap or a missing example — and design-notes.md's own finding is that most real failures are exactly that, not model capability.
Needs labelled volume most deployments don't have yet, adds serving cost and latency, and bakes behaviour into weights nobody can inspect — which directly contradicts the auditability the rest of this platform sells.
Corrections get logged somewhere, reviewed by nobody, and never make it back into the system. The knowledge that a human caught a mistake evaporates the moment they close the tab.
Instruction modules for behaviour, golden examples bound to a task's schema, and retrieval tuning — each one measured, not guessed at.
A reviewer's fix doesn't just patch one output — it's promoted into a bound example the next release trains against and an eval case that gates it.
Not a vibe check — a fixed set of acceptance cases, run every release, so "did this actually get better" has a number instead of an impression.
74% to 96% isn't a claim — it's the same 36 acceptance cases run against every version, so the trend line is measured, not asserted.
Golden examples come from your real corrected cases, tenant-scoped — not a generic library that teaches the model about someone else's documents.
A change that fixes today's complaint but breaks yesterday's fix fails the eval suite before it ships, instead of surfacing in next week's support ticket.
Every correction has somewhere to go — a golden example, a regression test — so the work of the person who caught the mistake compounds instead of evaporating.