A probabilistic tool will do probabilistic things
You cannot make a language model deterministic. Nobody can. What you can do is make the boundary around it deterministic, and that distinction is the difference between a demonstration and a system a business can depend on.
The mistake
The common error is to deploy a model as though it were ordinary software, and then to be surprised when the same input produces a different answer in June than it produced in March.
That variability is not a defect waiting to be trained out. It is what the technology is. A probabilistic tool will do probabilistic things — that is the property that makes it useful for reading an ambiguous enquiry, and the same property that makes it unsuitable to be trusted unchecked.
Worse, nothing announces the change. A provider updates a model and behaviour shifts underneath a system that has not been touched. There is no deployment, no release note in your own change log, no failing test. Just gradually different output.
What a harness is
A harness is code that sits around the model and knows what a valid output looks like. It checks every result against that definition, and refuses to pass anything that fails.
The model stays probabilistic. The boundary does not.
This is not prompt engineering. A prompt is a request; a harness is an enforcement. The distinction matters because a prompt that enforces a rule today will quietly stop enforcing it after the next model update, and nothing will tell you. Code that rejects a malformed output will still reject it in a year.
What the harness checks
- Shape — is the output the structure it was required to be, with every field present and correctly typed?
- Facts — do the claims match a system of record, or has the model produced something plausible and untrue?
- Bounds — are the values within ranges that make sense for this business?
- Consistency — does the output contradict itself, or contradict what was produced yesterday?
Every one of these is a rule a person could state in a sentence, and every one is cheaper to enforce in code than to catch in review.
A refusal is a finding
When a harness refuses, that is not a failure of the system. It is the system working.
In our own publishing pipeline, a deterministic generator refused to emit malformed output and in doing so caught a live defect before it reached production. Without the harness, that would have been wrong information published to a live site and discovered weeks later by a customer — if it were discovered at all.
The refusal was visible, logged, timestamped and attributable. It cost nothing. The defect it prevented would have cost a good deal more.
A system that fails loudly is worth several that fail quietly.
Why this is the whole argument
Most of the disappointment with AI in business comes from deploying a probabilistic component into a process that assumed a deterministic one, and then discovering the mismatch through customer complaints rather than through tests.
The fix is not a better prompt or a larger model. It is accepting what the component is, and building the boundary that makes it safe to use.