One model cannot answer an inspection question

Ask a computer vision team to find damaged crossarms and you will get a detector. Ask a utility inspector the same thing and you get a question back: which crossarm, on which pole, in which of the eleven images of that structure, and how sure do I have to be before I send a crew?

That gap is the whole problem. The inspection question on the form is not a classification label. It is a small chain of decisions, and a model trained on the last link in the chain will look excellent in evaluation and disappoint in the field.

What the chain actually contains

Take the crossarm question above. Before a condition assessment means anything, four other things have to be true.

Something has to be detected. This is the part everyone builds. It is also the part that is close to solved for common components in good imagery.

The right subject has to be chosen. A drone image of a distribution pole frequently contains two or three other poles: the next one down the line, one behind it, one across the road. The question is about the structure this inspection is for, not whichever pole the model liked best. Getting this wrong produces an answer that is confidently about the wrong asset, which is worse than no answer, because it is not obviously wrong to the person reading it.

The component has to be associated with that subject. A crossarm in frame is not necessarily a crossarm on this pole.

The condition has to be visible in this image at all. Splitting along the grain, a loose bolt, corrosion at a connection point: these are sometimes present in the world and absent from the pixels. A system that always answers will answer these too.

Only then does the assessment happen. And a fifth decision sits across all of it: the system has to be able to say that this image cannot support an answer. Abstention is a feature, not a failure mode.

Why decomposition is not just engineering hygiene

The reason to split this into separate steps is not tidiness. It is that a wrong answer has to be attributable to something.

When a monolithic model gets an answer wrong, all you learn is that it was wrong. You can add data and try again, which is a slow loop with weak feedback. When a chain of steps gets an answer wrong, you can see that the detection was right, the subject selection picked the pole behind the one being inspected, and everything downstream was therefore reasoning about the wrong object. That is a specific, fixable defect in one component, and fixing it does not put the rest of the system at risk.

This is also what makes the difference between a demo and a product. A demo needs to be right often enough to be impressive. A product needs to be wrong in ways somebody can diagnose on a Tuesday afternoon.

The measurement trap

There is a second, quieter reason this matters, and it took me longer to internalise than it should have.

Object detection has good, standard metrics. Mean average precision over a labelled set is a real number that goes up as your model improves, and it is genuinely useful for model selection. It is also not the thing anybody is buying.

An inspection program cares whether the answer to question 14 on the form is right, for this structure, at a rate a qualified reviewer would accept. You can raise mAP by two points and move that number not at all, because the errors that survive are not detection errors. They are subject selection errors, association errors, and answers given where an abstention was correct. I have watched a model improve on paper and produce an identical number of usable answers.

So the useful discipline is to evaluate at the level of the question, against what a qualified inspector said about the same images, and to treat the component metrics as diagnostics rather than as the score. That inversion changes what you work on next, which is the only real test of whether a metric is any good.

Where the language models fit, and where they do not

Vision language models are extraordinarily useful in this chain and dangerous in one specific way. They are good at the assessment step, at describing what a condition looks like, at handling the long tail of phrasing that inspection forms contain, and at reasoning over several pieces of information at once.

What they should not be asked to do is invent spatial facts. If a model is asked where the damage is and it produces coordinates, those coordinates are a plausible guess unless something actually grounded them. The fix is unglamorous: get the location from a model whose job is location, and let the language model reason over what was found rather than about what it imagines. The answer then comes with a box that points at real pixels, and an inspector can disagree with a specific thing.

That leads directly into what I think is the more important argument, which is that a confidence score is not evidence. I have written about that separately.

What this means if you are buying

If you are evaluating AI for asset inspection, the questions that separate a system that will work from one that will not are mostly about decomposition:

• When the answer is wrong, can you tell me which step was wrong?
• How does the system decide which structure the question is about?
• What happens when the condition is not visible in the image? Show me an abstention.
• What is the accuracy of the answer to one specific question on my form, measured against my own inspectors, on my own imagery?
• If I disagree with an answer, where does that correction go?

None of those are questions about model architecture, and all of them predict whether the thing will survive contact with a real inspection program.

Our own products are organised around exactly this split: Vision answers the questions, Validate holds the evaluation and compliance evidence, and Velocity is the model access layer underneath. Not because the layering is elegant, but because that is what it took to make wrong answers diagnosable.