The Correction Layer

Why AI oversight that exists on paper keeps failing in operations, and what regulated environments already know about fixing it

Most regulated AI programs can point to their human oversight requirement. Few can point to a logged correction from last month.

That gap is where this series lived. The requirement sits in a governance document, reviewed, approved, and signed. The function, the actual machinery that catches a wrong output and turns it into a better system, is missing from the operation. And the systems being deployed today fail in a particular way. They are not wrong loudly. They are confidently wrong, which means the error travels until something designed catches it.

In my experience, that something has a consistent shape. I have watched it get built in every regulated or high-consequence environment I have worked in, decades before anyone called it AI oversight. And while this series was running, the missing version of it backed my own car into a pillar. This article walks through the argument in five parts.

The correction layer is not an AI idea

In 2012, I was accountable for operations at a Scandinavian insurance group where we automated car glass claims. A claimant uploaded a photo. If the image was clear, the timestamp and location checked out, and the details matched the policy, the claim came back approved, with suggested times at a repair shop. If the criteria were not met, the claimant was told why. A blurry photo got specific feedback, not a rejection letter.

One rule was non-negotiable. Multiple claims from the same customer within a set window went to a human, every time. The system could approve a windshield. It was never allowed to judge a pattern.

We did not design it that way because we distrusted the technology. We designed it that way because a regulated decision needs a defensible path from "the system decided" to "a person is accountable." The automation earned the simple yes. The pattern call stayed human, by design, before go-live.

Fourteen years later, AI systems are being deployed into far more complex regulated decisions, often with less designed oversight than a windshield claim had.

The four functions

Earlier this year I hit the other side of that design gap, as a user. A frontier AI product blocked my request, repeatedly. Controls exist for good reasons, and control systems produce false positives. That part is normal. The problem was what the system gave me to work with: nothing.

The flag pointed at no cause, so I did what users do. I rewrote the prompt, again and again. Every version was safe, and every version was flagged, at a cost in tokens and time. The actual cause was a reference image generated earlier in the same workflow, by the same product, where one background element tripped the control. I replaced the image. The generation worked. The system had generated the contamination, blamed my input, and charged me for the diagnosis.

That experience is what a missing correction layer feels like from the outside. A working one performs four functions.

• Attribution. Which input tripped the control: the prompt, an uploaded asset, or a generated one. A correction starts with knowing where to look.

• Explanation. What to change, in terms the user can act on.

• Escalation. A dispute reaches a human who owns it, end to end.

• Logged resolution. The outcome is recorded, so the control improves.

None of this is new machinery. I ran network operations centers in the early 2000s on the same four functions. It worked then. It needs to be built around AI now.

A product decision, not a compliance requirement

A correction layer sounds like compliance. I would argue it is a product decision.

The claimant with the blurry photo did not experience our feedback rule as governance. They experienced it as the product working. I saw the same pattern running a cloud communications platform at 99.999 percent availability across more than forty regulated markets. Customers did not renew because the demo was impressive. They renewed because the service told them what was happening, escalated when it mattered, and improved after every incident. The product made the promise. The service kept it.

A seasoned AI leader sharpened this point in response to the series: correction is not a safety net after failure, it is part of building a product people can trust, improve, and rely on over time. The framing matters because the two stories get funded differently. A safety net is budgeted as insurance, and insurance gets trimmed when money tightens. A flywheel is budgeted as growth.

The flywheel is the mechanism. Every logged correction is evidence of where the product and reality disagree. Reviewed on a cadence, the log becomes roadmap input, and the rules that trigger human review stay matched to what the operation actually catches. The service improves the product, and each loop compounds trust.

A product is bought once. A service is chosen every day.

The terms are not a correction layer

While I was writing this series, the pattern parked itself in my garage. My car backed into a pillar during an automated parking maneuver it had handled many times before. I was in the driver's seat, not driving. Low speed, cosmetic damage, nobody hurt.

The company behind the system takes no responsibility. I agreed to that when I enabled the feature. Full accountability sits with me, the user. The correction layer was not designed into the product. It was written into the terms.

Legally, that works. Operationally, it does not. The real cost was not the repair. The real cost is that I trusted the system, it failed, and I will not hand it the keys again for a while. Trust took months to build and one scrape to lose. The vendor kept the liability off their books and lost the usage instead.

The discussion that followed sharpened the point. Elaine Barsoom observed that trust in AI systems is built through how failures are handled, not just how capabilities are marketed. And several readers spotted the same asymmetry I keep returning to: the system almost certainly logged more about that maneuver than I was given, so a correction flywheel likely exists. The user who carries the liability is just not in it.

You can transfer responsibility with a contract. You cannot transfer correction. When the correction layer is missing, the user builds one themselves, and the first thing they correct is how much they use your product.

The oldest correction layer I know

The first correction layer I worked in had no dashboard. It had a room, a whiteboard, and a rule.

In the Swedish Army, every exercise ended the same way. We went through what happened, why it happened, and what we would change, whether the exercise went well or badly. That was the point. It was not punishment for failure. It was the assumption that somewhere, something had gone differently than planned, and finding it was everyone's job.

I have carried that rhythm through every environment that worked since: the claims desk, the network operations centers, the five-nines platform. The technology changed every time. The rhythm did not.

It also produces a usable diagnostic. Three signs oversight is a checkbox, not a function:

• No owner. The requirement is in the policy, but no person has it in their job.

• No evidence. Nobody can point to one recent correction the process caught and recorded.

• No movement. The rules for when a human must review are the same as day one.

In my experience, programs that pass all three are rare. Programs that fix even one tend to feel it within a quarter.

The function is the work

Regulation will keep requiring human oversight, and it should. But a requirement needs a signature, while a function needs an owner, a log, and a path from "this output is wrong" to "the system got better." The distance between those two is not closed by policy language or by better models. It is closed by design decisions made before go-live, the same decisions regulated operations have been making for decades.

If your AI program can show me the requirement but not last month's corrections log, that distance is the work I do.