Corrections Are Signals, Not Failures
A support engineer gets a query about a client's configuration. The AI returns an answer, citing a configuration record. The engineer knows that record sits alongside two others — a JIRA ticket from an earlier migration and a note in the code documentation — that point in a different direction. The AI picked one. The engineer knows which one is right for this client, in this context.
She rewrites the response, closes the ticket, and moves on.
The sources that caused the ambiguity are still there, unchanged. The AI has no record of which one was wrong in this case, or why.
What the AI cannot see
The AI retrieved from sources that genuinely conflict. A configuration record says one thing. A JIRA ticket from a previous change implies another. A section of code documentation reflects a third state. The AI has no mechanism for resolving that conflict — it produces a confident answer regardless, collapsing the ambiguity into a single response without flagging that the ambiguity existed.
The assumption most operators hold when deploying an AI-assisted support tool is that this is a content problem. Clean up the sources, remove the contradictions, and the wrong answers stop appearing. Under that frame, ambiguous information is an editorial oversight — fixable with better source management.
That frame is wrong. In any live operational environment, ambiguity is not a temporary condition to be cleaned away. Client configuration accumulates exceptions. JIRA tickets record decisions that were later revisited, reversed, or worked around — often without the original ticket being closed or updated to reflect what actually happened. Code documentation reflects implementation choices that were correct at the time and have since been qualified. The sources will always contain records that are individually accurate but collectively ambiguous. That is not a failure of maintenance. It is the nature of operational documentation.
What the correction reveals
When an engineer corrects an answer, she is doing something the AI cannot: she is resolving the ambiguity from operational knowledge the sources do not contain. She knows which record applies in this context, for this client, given what has happened since. The resolution is precise. The reasoning is recoverable.
Neither gets back to the sources. The same ambiguity remains for the next engineer who encounters the same query.
The correction reveals something specific: that the AI encountered a conflict it could not resolve, produced an answer as if it had resolved it, and was wrong. Without a way to record which source combination produced the ambiguous output — and how it was resolved — the AI will produce the same confident answer from the same conflicting sources next time.
What this means for review
The sensible operational response is to check every answer before it reaches a client. Not because the AI is poor, but because there is no way to tell in advance which answers were produced from clear sources and which were produced by collapsing a conflict the AI did not flag.
When query volume is low, one engineer absorbs this quietly. As volume grows — more clients, more engineers, higher throughput — the checking distributes unevenly. Some answers get verified. Some do not. The client who receives the wrong answer is not always the one whose engineer knew how to resolve that particular conflict.
The constraint
The review labour does not disappear as the system is used more. It fragments.
Any system that produces answers from ambiguous operational sources, relies on human correction to resolve what it cannot, and does not record those resolutions has not reduced review labour. It has distributed it.