The evaluation harness is the product

There is a predictable shape to failed industrial AI projects. A model is trained on a curated extract, demonstrated on a laptop to appreciative stakeholders, and approved for a pilot. Six months later it is quietly switched off — not because it was wrong, but because nobody could tell whether it was right on any given Tuesday.

The missing artefact is almost never a better architecture. It is the harness.

What the harness actually is

An evaluation harness is the apparatus that answers one question on demand: is this system currently good enough to act on? Concretely, that means four things existing as code rather than as a slide:

1. A held-out set that reflects reality, including the awkward regions — the night shift, the changeover, the supplier whose material behaves differently, the camera that was bumped.
2. Metrics tied to the decision, not to the model. Precision on a defect class matters only insofar as it maps to scrap cost, false rejects and operator trust.
3. A slice breakdown, because an aggregate score hides exactly the failures that destroy confidence. A system at 96% overall and 61% on one product variant is a system that will be distrusted, correctly.
4. A gate, wired into the pipeline, that refuses a promotion when a slice regresses beyond an agreed tolerance.

Why it has to come first

Building the harness before the model feels backwards and is not. The act of constructing it forces the conversations that otherwise surface late and expensively: what is ground truth here, who adjudicates disagreement, what does the current human process actually achieve, and what improvement would justify the change.

We have had engagements where the harness alone changed the decision. In one, establishing the baseline honestly revealed that the incumbent manual process was materially better than the number everyone quoted. The useful project turned out to be a different one — and finding that out in week three rather than quarter three is worth more than any model.

Online, not just offline

Offline evaluation tells you about the past. Production tells you about now, and production drifts: sensors age, materials change, a line is re-tooled, an operator finds a workaround. So the harness extends into the running system:

• Shadow scoring on live traffic before the model influences anything.
• Drift monitors on inputs, not just outputs, because input drift precedes output degradation.
• A sampled human-adjudication loop that keeps producing fresh labelled data at a known rate.
• A kill switch with a documented, rehearsed fallback to the previous behaviour.

None of this is exotic. All of it is routinely skipped, because it produces no demo.

The uncomfortable implication

If the harness is the product, then a good chunk of an AI budget should be spent on measurement infrastructure rather than modelling. That is a hard sell in a room that came to hear about models. It is also the difference between a system that gets switched off and one that becomes load-bearing.

Our rule of thumb: if you cannot answer “how would we know if this got worse?” in one sentence, pointing at something that runs automatically, you do not yet have a production AI system. You have a promising prototype and an unbudgeted liability.