A “human” bounding box looks like a self-evident output: four coordinates, a class label, a confidence score. Treat it that way and you produce numbers a safety reviewer cannot connect to anything. The box is a structured claim, and its meaning is only complete once its role in the evidence chain is explicit. That distinction matters most when the class is a person. A pedestrian or vulnerable-road-user detection isn’t just one more entry in a list of objects — it typically exercises the highest-integrity safety goal in the whole function. When a reviewer asks “what does this detection assert, and against which requirement?”, a team that has treated the box as a raw accuracy metric has no answer. A team that understands the box as a traceable claim can walk the detection back to the ASIL D safety goal it serves. What does a bounding box actually assert? A detection output bundles three separate assertions into one artifact, and it helps to keep them separate when you reason about evidence. The first is extent: where the thing is. In an image-plane detector this is pixel coordinates — usually two corners or a centre plus width and height. In a metric-space or bird’s-eye-view detector it’s a position and size in the vehicle frame. These are not interchangeable, and confusing the two is a common source of downstream error. The difference between image-plane and bird’s-eye-view detection outputs is not cosmetic; it changes what the coordinates mean and what calibration they depend on. The second is class: what the model asserts the thing is. “Human”, “pedestrian”, “cyclist” — a discrete label drawn from the model’s trained taxonomy. The label is only as meaningful as the taxonomy behind it, and taxonomies vary between datasets. A box trained on one class definition and evaluated against another produces a claim that looks valid and isn’t. The third is confidence: a scalar the model emits alongside the box. This is the assertion most often misread, and we’ll come back to why. Put together, a single detection asserts: there is an object of this class, at this extent, and the model’s internal signal for that assertion is this value. That is the raw claim. It is not yet evidence. How a human box differs from other object classes In a safety-relevant perception function, not all classes carry equal weight, and the asymmetry is deliberate. A missed traffic-cone detection degrades comfort or triggers a nuisance event. A missed pedestrian can be a hazardous event that maps directly to the function’s top-level safety goal — which for automatic emergency braking and similar functions is frequently allocated at ASIL D. The practical consequence is that the same detector output means something different depending on the class. For lower-consequence classes, a reviewer may accept aggregate detection metrics. For the human class, the reviewer wants to see the detection claim connected to the specific hazard it mitigates, the operating conditions under which it was validated, and the failure behaviour when the box is wrong. This is the same reasoning we lay out for what a perception model owes an ASIL D evidence pack — the human class is where that debt is largest. This is why “our pedestrian mAP is 0.94” is a poor answer on its own. Mean average precision is a corpus-level summary. It tells a reviewer nothing about the false-negative behaviour at the specific ranges, occlusions, and lighting the safety goal cares about. The metric is real; its connection to the integrity argument is missing. How a detection maps back to an ASIL D safety requirement The box becomes evidence when each of its three assertions is tied to a requirement. Here is the mapping made explicit. Detection claim to requirement traceability Box assertion Raw metric view Evidence view (what the pack needs) Requirement it exercises Extent (coordinates) “IoU 0.7 on the test set” Localisation error bounded within the range/lateral tolerance the downstream planner assumes Positional accuracy requirement for the collision-avoidance function Class (label) “94% pedestrian precision” False-negative rate on the human class under the declared operating conditions, with the taxonomy pinned Detection-completeness requirement tied to the pedestrian hazard Confidence (scalar) “threshold at 0.5” A calibrated relationship between the score and observed correctness, plus the decision threshold’s justification Uncertainty-handling requirement in the fusion/decision layer Read the middle column: none of those are new measurements the model can’t produce. They are the framing that turns an output into a claim a reviewer can trace. The evidence value comes from making the requirement link explicit, not from generating more numbers. That is the whole point of the DETR-versus-YOLO validation discussion: the detector architecture matters far less than whether its outputs can be tied back to safety goals. Why confidence score alone fails to establish trust The single most common misreading is that a high confidence score means a detection is trustworthy. It doesn’t, for a structural reason. A softmax or sigmoid confidence is the model’s internal signal, and modern detectors are frequently miscalibrated — the emitted value does not equal the empirical probability that the detection is correct. A network can be systematically overconfident, reporting 0.95 for detections that are right only 80% of the time (an observed pattern across deployed detectors and a well-documented calibration failure mode; not a single benchmarked rate). Nothing in the raw score guarantees the mapping. There’s a second, subtler failure: confidence says nothing about the absence of a detection. The score attaches to boxes the model drew. The pedestrian the model never boxed produces no low-confidence output — it produces no output at all. Safety cares intensely about that silent false negative, and confidence is structurally blind to it. So “confidence was 0.98” is not an integrity argument. What the pack needs is a calibration statement — a demonstrated relationship between score and correctness on held-out data representative of the operating conditions — and a separate treatment of miss behaviour. Confidence is an input to that argument, not a substitute for it. How to express detection uncertainty so it becomes evidence If a scalar confidence isn’t enough, what is? The goal is to make uncertainty legible rather than merely present. A few practices turn it from a raw metric into usable evidence: Calibrate the score. Report reliability against held-out data (temperature scaling and similar post-hoc methods are standard) so a stated confidence maps to an empirical correctness rate. Now the number means something a reviewer can use. Separate localisation uncertainty from classification uncertainty. A box can be confidently classified but loosely localised, or vice versa. Collapsing both into one number hides which one the downstream function is sensitive to. Characterise the operating conditions. Uncertainty is not constant. Range, occlusion, illumination, and weather move it. Evidence states under which conditions the calibration holds and where it degrades. Treat misses as first-class. Report false-negative behaviour on the human class explicitly, because confidence cannot represent it. Done this way, the detection stops being “a box with a number” and becomes a bounded claim with declared conditions of validity. That is the form a validation pack can carry. The same discipline of tying an output to its conditions of validity shows up wherever perception meets safety evidence — it is closely related to how rotated bounding boxes change what the coordinates assert and why the extra degree of freedom has to be justified against a requirement rather than assumed. Common misreadings that trigger a reviewer clarification cycle The failures below are the ones we see cause the most avoidable back-and-forth. Each is a case of treating the box as a raw metric instead of a traceable claim. Reporting aggregate mAP as if it answered the pedestrian question. It’s a corpus summary, not a per-hazard argument. Presenting a confidence threshold with no calibration behind it. The reviewer cannot connect 0.5 to a correctness probability. Mixing up image-plane and metric extent without stating which calibration the metric position depends on. Silence on false negatives, because the confidence-centric view never surfaces them. A class taxonomy that doesn’t match the one the safety requirement assumes. Each of these forces the reviewer to send the pack back with a clarification request, and each is preventable at the point the detection output is defined rather than at review time. FAQ What does working with human bounding box meaning involve in practice? A human bounding box is a structured claim, not a single number. In practice it asserts three things at once — an extent (where), a class (what), and a confidence (the model’s internal signal for that assertion). The meaning is only complete when each of those assertions is tied to the safety requirement the detection serves. What does a bounding box actually assert — coordinates, class label, and confidence — and how do these combine into a single detection claim? The coordinates assert extent (pixel or metric position and size), the label asserts class from the model’s taxonomy, and the confidence is a scalar the model emits for that assertion. Combined, one detection claims: an object of this class exists at this extent with this internal support. That combined claim is the raw output — it becomes evidence only when each part maps to a requirement. How does a human (pedestrian / vulnerable-road-user) bounding box differ in significance from other object classes in a safety-relevant perception function? A missed low-consequence object degrades comfort; a missed pedestrian can be a hazardous event tied to the function’s top-level safety goal, frequently allocated at ASIL D. So the same detector output means more for the human class, and a reviewer wants it connected to the specific hazard, the validated operating conditions, and the failure behaviour rather than to aggregate metrics. How does a bounding box output map back to an ASIL D safety requirement so a reviewer can trace it? Each assertion links to a requirement: extent to a positional-accuracy requirement, class to a detection-completeness requirement for the hazard, and confidence to an uncertainty-handling requirement in the decision layer. These are framings of measurements the model already produces, not new tests. The evidence value comes from making the requirement link explicit. What does a bounding box NOT tell you — and why does confidence score alone fail to establish that a detection is trustworthy? A raw confidence is the model’s internal signal and is often miscalibrated, so a high value doesn’t equal a high empirical correctness rate. It also says nothing about the pedestrian the model never boxed — the silent false negative produces no output at all. Trust requires a calibration statement plus a separate treatment of miss behaviour, not the score by itself. How do you express detection uncertainty around a human bounding box so it becomes usable evidence rather than a raw metric? Calibrate the score against held-out data so it maps to a real correctness rate, separate localisation uncertainty from classification uncertainty, characterise the operating conditions under which the calibration holds, and report false-negative behaviour as first-class. That turns a box-with-a-number into a bounded claim with declared conditions of validity — the form a validation pack can carry. What common misreadings of bounding box meaning trigger a reviewer clarification cycle in a perception validation pack? Reporting aggregate mAP as if it answered the pedestrian question, presenting a confidence threshold with no calibration behind it, confusing image-plane with metric extent, staying silent on false negatives, and using a class taxonomy that doesn’t match the requirement. Each treats the box as a raw metric instead of a traceable claim, and each forces the reviewer to send the pack back. Where this leaves the detection output The box is a claim, and a claim without a requirement behind it is just a number. Getting the meaning right early — at the point you define what a detection asserts, not at review time — is what keeps a pedestrian detection traceable through the whole computer vision perception pipeline and into the safety argument. When the output is defined this way, the cross-vertical reliability evidence pattern has something coherent to tie to, and the clarification cycles shrink because the reviewer can see the requirement the box exercises without asking. The open question is rarely “how accurate is the detector?” It’s “can you show me what each detection claims, and against which safety goal?” A team that can answer that has turned its perception output into evidence. A team that can’t still has a box and a number.
