In the last piece I argued that the most useful control over an AI workflow is a maintained evaluation harness. A set of representative inputs, with a defined view of what a good answer looks like, that can be run every time the model changes. Several people asked the obvious next question. How do you actually build one.
The engineering is the easy part. The hard part is knowing what to put in the harness. That knowledge comes from a place most AI conversations skip past.
The harness is the design, made executable
A test is a precise statement of what you expect to happen. To write one, you have to say exactly what the system should produce for a given input. That looks like testing. It is really design. You have not finalised what a feature should do until you can describe what a wrong output looks like. Before that point the design is still an intention. The complete specification only exists once you can define the answers you would reject. This was true long before GenAI appeared. But the consequences of getting it wrong in AI-enabled solutions are far more amplified, and far more invisible, than before.
This is why I now treat the design of a solution and the design of its harness as one activity. The harness is the design intent, made executable. When you cannot write the test, the vision is still vague, and no amount of engineering will settle it for you.
The scarce skill is judgment
The instinct is to hand the harness to engineers, because it has the look of a technical task. Engineers build the harness. They are rarely the right people to decide what belongs in it. That decision needs someone who understands the problem well enough to know what matters, which cases are rare, and where a sensible-looking output would quietly do damage.
That understanding is borne out of breadth of experience. It comes from having watched the work go wrong in real settings, often enough to know the patterns by sight. A model cannot supply it. A gifted engineer who has never lived the use case cannot supply it alone either.
There is a second ingredient, and it is particular to AI. You need a feel for how these systems fail. They fail by being persuasive. They produce answers that read well and happen to be wrong, and they shift their behaviour after every model update. Know the domain but not this, and you will trust a fluent answer too readily. Know the failure modes but not the domain, and you will test for the wrong things. The pairing is rarer than either, and it is the thing worth having.
The revealing part is the negative space
The most telling part of any harness is the negative space. Listing what a system should do is easy. It takes real experience to set down what it must never do, which is the solution boundary. This boundary can only be articulated by defining the outcomes that are not acceptable. Two examples from my own work show what I mean.
We have a feature that finds duplicate records in an item catalogue. That is foundational data, the sort that sits under systems such as an ERP. Early on it marked two items as the same because their descriptions were almost identical. One was an M12 bolt. The other was an M16. To the software that calculates probability and delivers a judgment, the text was a near-perfect match so the duplicate call looked right. To anyone who has run a parts catalogue, a 12mm and a 16mm bolt are different components. You cannot swap one for the other, and merging them corrupts the catalogue and every order that flows from it. The software had no way to know that the size was the whole point. So we taught it to recognise a specification. A thread size, a grade, a dimension. Take that out and then decide whether two items are genuinely the same. The knowledge that produced the rule was knowledge of bolts.
The second case is quieter. A feature that sorts spending into categories would, whenever it was unsure, reach for a broad and comfortable heading. General. Miscellaneous. IT. Each looked like a reasonable answer. In truth the system was reaching for cover, because it had run out of genuine classification. Those tidy headings are where the spend you most need to see goes to hide. Anyone who has done procurement analysis has learned to be wary of a large miscellaneous line. So we taught the system to be wary of its own comfortable defaults, and to pass an uncertain payment to a person as unclassified, rather than let a neat label stand.
Each of these was a piece of hard-won judgment, written down as a rule so the software would carry it every time it ran.
Beyond what we have built
What I have described is a start. Our harness is partly built, and it will keep evolving. I would rather say that plainly. A future version goes further in a few directions.
It sets a clear pass mark for each kind of output, so a model change becomes a measured event. You run the new model against the same inputs and see whether it still clears the bar. The test set grows well past a handful of illustrative cases, into a labelled body large enough to trust. Deliberately awkward inputs go in, the ones built to trip the system. And live output is watched for slippage, because a model that passed last quarter can drift this one.
None of that needs a large team. It needs someone who owns the problem and keeps asking what a wrong answer would look like.
Where this leaves you
I keep returning to one idea. The harness is the least glamorous thing we build. It is also the most invisible and the most decisive. It is where the vision becomes something the software can be held to. It belongs to whoever understands the problem. That is seldom the person who writes the code.
There is a quieter benefit too. When judgment is written into a harness, it outlives the people who first held it. The experience of your best person stays in the system after they have moved on.
The model can tell you what is plausible. Only experience can tell you what is plausible and wrong. The harness is where you write down the difference.
Ari Das-Purkayastha advises organisations on delivering and managing technology-led transformation.