When Is an AI System Ready for Real Use?

The demonstration went well. The build is green. It is deployed behind a flag. Someone asks whether it can go live, and the room agrees that it basically works.

None of those things is the answer to the question being asked.

Deployment is not readiness

Deployment means the software is running. Readiness means there is enough evidence and control to justify exposing it to its intended use.

They come apart constantly, and in both directions. A system can be live and not justified. A system can be justified for a narrow use and still be sitting undeployed.

The words that get offered in place of readiness are each worth something and none of them settles it. Tested says something passed the checks that were written. Approved says somebody said yes. Deployed says it is running. Observable says you could investigate a failure. Governed says rules are enforced somewhere. Each is a contribution. A system that has all five can still be the wrong thing to put in front of its users.

That is the check worth applying to every one of these words, including the ones on this page: a thing labelled validated or production or release is telling you what someone called it, not what is true of it. Find what was actually checked.

Ready for what

A system is not ready in general. It is ready, or not, for a particular exposure to a particular use.

So the first question is not whether to ship. It is what exposure is being requested. Which users, doing what, with what riding on the result, under what conditions, with what limit on how far the output travels.

The same system can be appropriate for a team reviewing its output internally and not appropriate for customers acting on it unsupervised. It can be appropriate where it advises and not where it acts. These are different exposures, and they are not rungs on a ladder that every system climbs. A workflow may stay internal permanently because that is where it belongs.

Naming the exposure precisely is what converts an unanswerable question into one that has an answer.

What the demonstration established

A demonstration is persuasive because it compresses the system. One user, one goal, a selected input or a narrow input range, one path through, and little at stake if it fails.

That compression is useful, because a demonstration is testing a narrower question: whether this is possible at all.

The readiness question is different. It asks about conditions the demonstration may never have exercised: input that arrives malformed or incomplete, a user with a goal the design did not anticipate, the upstream system being slow or wrong, and the cases where failing is expensive. The gap between those two questions is not evidence that the demonstration was misleading. It is evidence that it answered a narrower question than the one now being asked.

What would matter if it went wrong

Keep this concrete and specific to the system in front of you. What failure would actually matter here? Who or what is affected when it happens? Can the effect be undone, and by whom? Does the system act, or does it produce something a person acts on? What does it do when the context it needs is missing?

That last one carries more weight than it looks like it should. A system that degrades quietly when its inputs are thin is a different proposition from one that stops, and the difference is invisible until it matters.

Whether a given action may proceed at all is a separate mechanism with its own page. A system can enforce its authorization rules correctly, on every call, and still not be something you should expose.

The evidence, and what it does not cover

Readiness consumes evaluation results. It does not produce them, and this page does not explain how to produce them: what counts as good behaviour, how to check it, and what a fixed set of past failures is for belong to evaluation.

What the readiness decision adds is a question about coverage. Given the failure modes just named, which of them does the existing evidence actually speak to? An evaluation set assembled from the cases somebody thought of will be silent about the ones nobody did. That silence is not a pass.

Where a question cannot be answered, the honest move is to record that it cannot. Absence of evidence has a way of being read as evidence of absence, particularly when adjacent artifacts exist: a monitoring dashboard does not establish that anyone would notice this failure, and a rollback procedure elsewhere does not establish that this change can be undone.

The release criterion

Define an explicit release criterion against an evaluation set appropriate to the intended use and its failure consequences, before exposure rather than after.

Before matters for a specific reason. If the release criterion is chosen after inspecting the same results used to justify release, the rule can be fitted to those results rather than serving as an independent release condition. Exploratory evidence can perfectly well inform a criterion, provided the criterion is then tested against evidence it did not come from.

There is no universal number to put in it. A sample size, a percentage, a pass rate or a confidence threshold carried over from another system is a borrowed answer to a question about this one. What the criterion has to be is specific and decidable: this behaviour did not fail anywhere in the set we chose; these known failure classes stayed inside the boundary we agreed; this category always goes to a person; this integration path was verified against the real system rather than a stub.

A criterion may combine several of those. What it cannot do is stand in for the judgment about whether they are enough, which is the part that belongs here:

• evaluation asks whether the workflow met the expectation that was set
• the release decision asks whether meeting it is sufficient to justify this exposure

A result can be methodologically sound and still not answer the second question, because sufficiency depends on who is exposed and what it costs when the system is wrong.

Controls that limit the consequence

Evidence is one half. The other is what constrains the damage when the evidence turns out to have been incomplete.

This repository carries a small worked example. In this repository a draft is checked before it can be placed into the published content collection, and when the checks that run after placement fail, the previous state of the affected files is restored. The checks are structural: whether the declared frontmatter is valid, whether the body has the required shape, and for pages declaring the current contract, whether every consequential claim maps to the prose and whether the prose passes the house rules. Placement into the collection is conditional on those passing. A further set runs across the whole collection afterwards, and failure there restores the previous article and its cover rather than leaving a half-applied change.

By default the publishing script opens a pull request without merging it, and when a flag is supplied it can instead arm an automatic squash merge once the required conditions pass. Both paths exist in the code, and describing either one as the whole mechanism would be wrong.

What that example does not establish is more instructive than what it does. The gates confirm declared structure. They do not confirm that the writing is any good, that a cited source supports the claim drawn from it, or that the page should be published at all. The restoration covers two specific file paths when a specific set of checks fails; it is not a general undo for anything that has been published. And nothing in the code records who judged the exposure justified. An implemented control is evidence that a control is implemented. Readiness is a separate judgment that the control is enough.

When the system should not continue

The old advice here was to route to a human when the model reports low confidence. Both halves of that are worth discarding. A confidence value, where a system exposes one, is one workflow-specific signal, and it does not by itself establish readiness or define when a result should go to a person. A person is also one option among several rather than the default destination for everything a system cannot handle.

The useful question is narrower: when this system should not continue normally, what safe alternative actually exists? Stopping and saying so. Declining. Leaving the prior state in place. Returning to the manual process the system replaced. Queueing the case for later. Restricting what the system will attempt. Handing it to a person. Which of these is available depends on the workflow, and some workflows genuinely have only one.

Routing to a person is also not free of its own requirement. Whether that person can actually judge what they are being shown is its own design problem, and a queue nobody can act on is not a fallback.

What can actually be undone

Rollback gets treated as universal and is not. Some effects cannot be reversed: a message sent, a decision communicated, a payment made, a file deleted downstream. An advisory system may have nothing to roll back, because its output was already acted on by somebody else.

So the question is not whether there is a rollback procedure. It is what can be stopped, reversed, corrected or contained if this exposure produces a result you cannot accept. Those are four different answers with four different costs, and a system where the honest answer is contained, not reversed is not thereby unready. It is a system whose exposure should be set with that in mind.

Who decides, and who answers

Two roles need names before exposure, and they are easy to assume rather than assign. Somebody owns the decision to expose. Somebody owns the response when the system behaves outside the conditions that decision assumed.

These belong to people and teams. A runtime can enforce a rule and a script can block a change, and neither of them is accountable for a judgment. Where nobody can be named for either role, that is itself a finding about readiness rather than an administrative gap to tidy up later.

Can the intended users work with it

A workflow can satisfy every technical check and still be the wrong thing to hand to the people expected to use it.

The questions worth asking are about fit rather than attitude. Does the workflow add work to the job it was meant to help with? Can the intended users tell what they are being asked to do with the output? Do they have a way to know when it should be relied on and when it should not? Does a workable alternative remain when the system cannot continue? Is the intended use compatible with the process actually running around it?

Those are answered by looking at the work and asking the people doing it, which makes them evidence. What they are not is a theory about why people accept or reject software, and readiness reasoning does not need one.

The decision, and its expiry

The outcome is not restricted to yes or no. It can be to expose as proposed, to narrow who or what is exposed, to keep it internal, to require another control first, to gather the missing evidence, to defer, or to stop. Reaching for one of the middle answers is usually a sign the reasoning is working, because it means the exposure is being matched to the evidence rather than the other way round.

None of this means the failure has been designed out. The decision is whether the uncertainty that remains is acceptable for this exposure, given what is known and what limits the damage. Readiness is a judgment about acceptable remaining uncertainty for an intended exposure, not proof that failure is impossible, and no score establishes otherwise.

The decision also has a shelf life. A change to the model, the instructions, the retrieved corpus, a tool, a policy, the workflow, the intended users or what it costs to be wrong can undermine part of the basis the decision rested on. Not every change requires starting again. The standing obligation is narrower: when the assumptions that supported the release stop holding, the release basis is what needs revisiting, and re-establishing the evidence is a separate job with its own methods.

What this changes

Stop asking whether the system is ready. Ask what exposure is being requested, and what would have to be true to justify it.

Then answer three things in writing. What evidence exists against the failures that would actually matter here. What limits the damage when that evidence turns out to be incomplete. Who owns the decision, and who answers when it goes wrong.

If those three can be answered, the decision has what it needs. If they cannot, the honest finding is not that the system is unready. It is that nobody is currently in a position to say either way, which is a different problem and a more fixable one.