A printed marking opens a camera-controlled gate once in five presentations — how do you report that finding?

## Intermittence is the result, not a defect in it Engineers used to deterministic bugs read "reproduces sometimes" as "not confirmed". For a physical evasion finding that instinct is wrong. The artefact was fitted to a distribution of capture conditions, and each presentation draws a fresh sample from the real one: a slightly different angle, a cloud moving, an auto-exposure decision, a different frame chosen by the reader. A per-presentation success **rate** is the only well-formed statement available. A finding that says "it works" without a rate, and a triage note that says "could not reproduce" after three tries, are both malformed. ## The columns that make the rate mean something A physical rate is uninterpretable without the conditions it was drawn under. A usable report carries: - **Trials and successes**, not a percentage alone. Four of twenty and forty of two hundred are very different evidence for the same 20%. - **Geometry** — the range of angles and distances presented, and whether they were varied or held fixed. - **Illumination** — overcast, direct sun, night under the gate's own lighting; which hours were covered. - **The capture chain** — the camera model actually deployed, its resolution and capture settings, and whether the pipeline's resize and lossy encode were in the loop or bypassed. - **Fleet and time coverage** — one camera at noon is one condition; the risk lives in the rate across the installed cameras and across the day. - **Tuning disclosure** — whether the artefact was optimised under the same conditions it was then measured under. If it was, the rate is optimistic for the same reason that evaluating on training data is. The last one is where reports most often mislead without intending to. ## Setting severity from the economics, not the percentage The question a decision-maker actually needs answered is not "how strong is the attack" but "what does it take to succeed once". At a gate: - a presentation costs a printed sheet and a few seconds; - retries are unlimited, cheap and mostly unattributed; - a failed read looks exactly like a dirty plate, a bad angle or rain, so it generates no signal by default; - one success is the whole payoff, because the gate opens. Under those conditions a 20% per-presentation rate is not a curiosity: a handful of attempts gets through, and the expected number of attempts is small enough to fit inside a normal dwell time at the barrier. Contrast a setting where each attempt is expensive, attributable, or rate-limited after a few failures — the same 20% is a much weaker finding there. **Severity is set by attempts-per-hour and cost-per-attempt, not by the headline rate.** This also points at the defence worth recommending, which is operational rather than model-side: repeated failed reads from the same lane inside a short window are a cheap, high-signal detection, and the attacker's need to retry is precisely what makes it work. ## The trap in a clean digital number sitting in the same report When a report puts a digital figure and a field figure in the same table, readers compare them as if they were rows of one experiment. They are not: they were measured over different input distributions, and only the second says anything about the gate. Either drop the digital row or label it explicitly as an upper bound obtained without the capture chain. ## What to write A defensible finding reads roughly like: *under the deployed camera and capture settings, with the pipeline's resize and encode in the loop, presented from within the normal driver's angle and distance range under overcast daylight, the artefact was read as the target marking in 24 of 120 presentations. Not yet measured: direct sun, night lighting, or the other camera model in the fleet. The artefact was tuned under a different lighting condition than the one measured.* That is a smaller claim than "we defeated the gate", and it is one you can defend in a room.