How do you know an AI failure was actually fixed?

We keep a ledger of every non-trivial failure our AI systems hit in production. As of 7 November it holds 4,308 records, each with a root cause and, nearly always, a prevention rule.

There are two ways a record gets marked closed. A structured field, set by the tool that resolves an error. And a written resolution section, typed by whoever actually fixed it.

2,443 records carry the field. 121 carry the written resolution. Six carry both.

6

Two numbers that cannot both be the answer

Read the field and 57 percent of our failures are closed. Read the prose and 3 percent are. The two signals are not a strict subset of one another, they are very nearly disjoint, and whichever you pick you are wrong by roughly twenty times in one direction or the other.

This is not a rounding problem. It is two populations of people recording the same fact in two incompatible places.

The history explains it without excusing it. In version 1.0 of this study the structured field was broken. The endpoint that wrote it returned a parse error on every call for eleven days, so operators gave up on it and appended a written section by hand. At that point the field understated closure: 6 records carried it against 71 with written resolutions.

The endpoint got fixed. Closure moved into the field, and the writing stopped. 2,440 of the 2,443 field-closed records have fix text but no written resolution. The ratio did not improve, it inverted.

Why the field is the weaker record

A field is a checkbox. It records that somebody pressed something. A written resolution records what was changed, and it is the only one of the two that a person reading the note a month later can act on.

We can see the difference in what sits next to each signal. Of the 2,443 field-closed records, 1,458 are typed check-added and 952 prevention-rule, which are real categories pointing at real work. But 1,861 records carry no resolution type at all, and 1,750 carry neither closure signal.

So the honest summary of our own ledger is this. Something was recorded as done on 2,558 records. On 1,750 nothing was. And on only 121 did anyone write down what the fix was in a form another person could use.

This is a measurement problem before it is a discipline problem

The tempting conclusion is that people got lazy once the button worked again. We do not think that is it, or at least not most of it.

A structured field is cheap and a written paragraph is expensive. When both exist, and only one is required to clear the record from a queue, the cheap one wins every time. That is not laziness, it is the system doing what it was built to do. We built a path of least resistance and then were surprised that people took it.

The fix is not to ask people to write more. It is to stop treating the field as sufficient. A record that is marked closed with no written resolution should not count as closed in any number we report, including internally.

What to ask about any AI system in production

If a vendor tells you their agent failures get fixed, the number is close to meaningless on its own. Ask instead:

What counts as closed in your system, and who or what sets it? If it is a field, ask how often the field is set without a written fix beside it.

How many of your recorded failures have a prevention rule that is actually enforced, rather than a note saying what someone should remember to do?

How many have neither? In ours that number is 1,750 of 4,308, and we would rather publish it than discover later that we had been quoting the flattering half.

The full dataset, the method and the limits are in the Agent Failure Index. Every figure in this post is computed from the published rows, not typed by hand.