Quality Is No Longer Binary

You built something that works. You ask the same question again and get a different answer. Not wrong, necessarily. But not identical either. You have a quality problem your quality tools cannot see. They were built for one question: does it work, yes or no? That question no longer has a meaningful answer.

The first instinct is to call it a weakness — something models will improve at over time. That's the wrong diagnosis. Non-determinism isn't a defect to fix; it's a property of a certain kind of system. And our entire apparatus for assessing quality assumes the opposite. Green or red. Pass or fail. Works or doesn't. Those categories no longer describe what's happening.

The question has changed. It's no longer "does it work?" but "how often, under what conditions, with what margin?" Tolerances replace absolutes. Spectrum replaces binary. It is a fundamentally different way of thinking about quality — and it requires a fundamentally different way of measuring it.

The uncomfortable part is that the answer depends on context. Ninety-five percent correct can be excellent in a recommendation engine and unacceptable in a medical diagnosis. Where the line falls is not a technical question. It is a question of what is at stake — and it cannot be answered by whoever builds the system alone. It requires someone who understands the user, the risk, and the business. The definition of quality has become a product decision.

When functional and non-functional collapse

Traditional software engineering separated functional requirements (does login work?) from non-functional requirements (how fast, how available, how reliable?). FRs were binary; NFRs were probabilistic. You verified the former with assertions and the latter with statistics. The distinction was more than taxonomy — it defined how requirements were written, how tests were designed, and how roles were divided.

That distinction is collapsing. "The system can summarise a document" looks like a functional requirement. But the moment you try to verify it, you discover it only works some of the time. Correctness itself becomes probabilistic. FRs and NFRs merge into a single class of requirements that must be specified with probabilities, contexts, and thresholds.

This is not a notational change. It's a fundamental shift in how software is specified, tested, and accepted. The roles built around the old distinction — requirements engineers, test engineers, quality assurance specialists — are operating with frameworks that no longer match the reality they're supposed to govern. Their work is expanding in ways the titles don't yet capture.

Non-determinism is an architectural choice

But the decisions don't stop there. Where the system should be probabilistic — and where it must not be — is an architectural decision. It is rarely framed that way. Non-determinism is usually described as a fate you must accept. That is not true. The same system can be built so that it is non-deterministic where it can be, and deterministic where it must be. Recommendations may interpret. Payment flows may not guess. Hallucinations are not a model error — they are a symptom of architecture that didn't make that choice deliberately. Responsibility shifts from "the model hallucinates sometimes" to "we didn't build deliberately".

What contracts can actually promise

It also changes what can be contractually guaranteed. How do you write requirements for something that gives a different answer each time it's queried? When is a delivery "done" if there isn't a single correct answer — only better or worse, more often or less often? The answers determine who bears the risk when something fails in production.

Traditional SLAs promise uptime, response time, error rates. Probabilistic systems require new kinds of commitments: expected accuracy within defined tolerances, behaviour bounded by explicit thresholds, failure modes that are documented rather than assumed. The contract form itself needs to evolve. Organisations that don't recognise this are signing obligations they cannot meet — or, more often, refusing to sign any at all, and losing the business.

Validation is now continuous

There is one more shift embedded in probabilistic quality that deterministic systems never required: validation becomes continuous, not episodic. You don't certify a probabilistic system once and forget it. Its behaviour drifts as inputs evolve, as models are retrained, as the contexts it operates in shift. Quality assurance becomes an ongoing operation, not a gate passed at release.

This has an unglamorous but consequential implication: the cost of quality moves from the pre-release phase to the runtime phase. Monitoring, observability, and continuous evaluation become line items they weren't before. Organisations that haven't absorbed this keep building quality systems that look complete and aren't.

What doesn't change

Our entire industry built its identity on precision. On knowing. On controlling. It turns out the most important ability is no longer verifying that something is correct — but judging whether it is good enough. That sounds like a diminishment. It is the opposite. It is an acknowledgment that reality was always more complex than our test cases — and that the ability to handle that complexity is human. Precision suffices as long as answers are binary. When they become a spectrum, judgment is what decides.