The model never does the sums

Ask a language model to multiply two long numbers and it will usually be right. Ask it to weight eight comparables, take a percentile and round to the cent, and "usually" is not good enough for an invoice. Here, no model is ever asked. The sums are code.

There is no language model inside this engine. The only model it loads is the embedder that turns text into vectors for matching, and that model never adds anything up. Every number the engine returns was produced by plain arithmetic over rows it read from your records — no random element, no fitting, no sampling. Given the same file and the same question, every figure reproduces exactly.

That is a design choice, not a shortfall. A figure that came out of a model can be plausible and wrong at once, and there is no way to tell from the outside. A figure that came out of a short function can be re-run by hand. The doctrine across the whole system is one sentence: the model reads and retrieves; it never does the arithmetic.

The estimator is held to one worked example, taken from the founder's own historic job record — a bore of 376 metres priced at $834.95 a metre. It is not a customer's job; there are no customers yet. It is the case the code must reproduce before any other output is trusted: total equals length times rate, to the cent.

Multiply it yourself. That is the test, and it is the whole point: an estimate you can check with a calculator is a different kind of object from an estimate you have to take on trust.

When you ask for an estimate, the code opens your jobs ledger — a spreadsheet of past bores with diameter, length, ground conditions and the rate per metre actually charged. Rows without a usable rate are skipped; a comparable with no price cannot price anything. Rows the ledger itself marks as context rather than comparable are honoured and left out.

Each remaining row is measured for distance from the job you described: the difference in diameter and in length, both taken in log space so that going from a 2-inch to a 4-inch bore counts the same as going from 12 to 24, plus a small penalty if the ground or method does not match. The eight nearest rows are kept and weighted by closeness — an exact twin dominates, a distant one barely counts.

The likely rate is the weighted mean of those eight. The low and the high are the weighted 15th and 85th percentiles — and they are always one of the real historical rates, never a figure interpolated between two. The likely total is length times the likely rate, rounded to the cent. Every comparable used comes back with its document id, its rate, its weight and its citation, so the estimate can be traced row by row to the records it stands on.

A number on this site, or out of the engine, is one of three things. Actual means counted, or read directly from a record. [Model] ± means derived — the estimator's band is this kind, and it says so in its own basis field, "from your history ±". External means somebody else's figure, attributed. The estimate above is a [model] ± number built entirely from actual ones, and it never pretends to be more.