Less variation. Optimize to a standard.

Note · KBMill · value · consistency

Demo day worked. The question that keeps people awake is whether it still works next week — after a different folder, a different operator, or a different lucky retrieve.

We do not make the model smarter. We make the corpus stable enough that your stack can be optimized against it.

What “just ask the dump” actually varies

Point a capable model at a raw share — or at a one-shot extract of that share — and the failure modes swing. Today the wrong neighbor wins. Tomorrow an outdated procedure answers a new question. Next week a broken table cell looks like a number. None of that is mysterious. It is high variation in what the system is allowed to treat as fact.

You cannot tune a standard against luck. Prompt tweaks and retriever knobs help at the margin. They do not freeze the material underneath. If the package changes shape every time someone re-dumps the drive, “quality” is a coin flip with better lighting.

What consistency means here

Consistency is not “the model always says the same sentence.” It is less uncontrolled variation in the corpus the model is allowed to use — so the people who own the deployment can set a standard and improve against it.

In ordinary program language: fewer wild swings between demo and production; a package you can regression-test; a leave-behind a partner can put in a handoff without hoping the next ingest invents a new failure class.

That is why the people who write the estimates care. The week after go-live is their problem when document preparation was left off the estimate.

Therefore we freeze a package, not a vibe

A residual-honest brick — a clean, bounded, portable data package with clear limits — cuts variation in a concrete way:

Same mute list — junk taken off the answer path and listed, so “what may be quoted” does not silently drift
Same bounded unit — one curatable package, not an unbounded melt that reshuffles neighbors every rebuild (see bricks, not monoliths and the melted index)
Re-runnable checks — you can open the ZIP, compare cards, and re-run retrieval demos on a fixed artifact instead of arguing with a moving share

The model can still be swapped. The retrieval stack can still be yours. What stops thrashing is the corpus contract: a package stable enough to optimize against.

Open a public brick and a retrieval eval if you want evidence over adjectives — shelf · HF eval.

What we are not claiming

We are not claiming zero errors, identical answers on every prompt, or that consistency replaces good models and good retrieval. We are not claiming a published “variance score” we do not measure. The claim is mechanistic: freeze a residual-honest package and the wild swing of dump-and-hope drops enough that a team can hold a standard.

Better parsers and multimodal readers help with messy files. They still do not invent a stable leave-behind or a listed mute policy by themselves. Without that, you are optimizing prompts against a moving floor.

Door

If you approve on-prem spend, ask whether the plan includes a corpus package stable enough to trust after demo day — not only host, model, and “we’ll wire RAG.” If you build those plans, put document preparation on the estimate as its own line. If you have a pile now, the mill is a pilot with intentional caps: drop the bin, keep the ZIP, pay only if we produce.