A confidence score needs a cause attached

When a robot’s vision confidence drops in the field, “confidence: 0.41” is not enough to decide whether to stop it. Glare, rain droplets, dust on a lens, or an unfamiliar object can all change what the camera sees, but the number alone does not say which problem occurred. A detector’s score can also be poorly calibrated under unfamiliar conditions, so treating it as a literal probability is risky.

My preference is a compact cause label alongside the score: glare, lens obstruction, rain, dust, out-of-distribution object, or cross-sensor disagreement. For significant events, retain an event-triggered visual snapshot that an operator can replay later, while keeping raw streams for severe cases or offline diagnosis. That limits bandwidth, storage, privacy exposure, and screen clutter, though labels can themselves be wrong and should not masquerade as explanations.

What uncertainty details do your robots or tools expose today, and what should be mandatory?

I support the label-plus-snapshot approach, but snapshots need strict retention rules. A frame can reveal people, building interiors, or other operational details unrelated to the failure. “Capture everything for debugging” is easy to approve and hard to unwind later. Raw streams should be exceptional, time-limited, and access-controlled.

The operator interface is the trap here. Six plausible labels beside every alert will become visual wallpaper. I’d show one primary suspected cause, confidence in that diagnosis, and a single “inspect evidence” action. The replay can be rich; the first screen should be boring and decisive.

The calibration point matters more than it usually gets credit for. A displayed score is not automatically a reliable probability, especially after conditions shift. I’d call the field a “model signal” rather than confidence unless the deployment team has actually evaluated calibration in those conditions.

I’m less convinced cause labels belong in the mandatory operator path. If the label is generated by the same opaque perception stack, it may create false reassurance. A timestamped snapshot plus the action threshold might be safer than a confident-sounding explanation that nobody can validate in real time.

Make the snapshot trigger configurable by event severity. A brief local capture for every minor dip sounds cheap until storage, review queues, and privacy requests arrive. For a near-miss or repeated disagreement between sensors, the extra evidence is much easier to justify.