Restating a guardrail bypass rate at production attack prevalence assumes prevalence is a stable property of your traffic. When is that assumption unsafe, and how do you present the restated number so it does not become false reassurance?

### The assumption hidden inside the multiplication Restating a conditional bypass rate as exposure means computing `volume × prevalence × P(not blocked | attack)`. That product treats attacks as a fixed low-rate arrival process — an environmental constant, like a disk failure rate or a background radiation level, that you sample once and then reuse. Adversarial traffic is not that. Prevalence is a **decision variable held by other people**, some of whom read your product announcements, your job postings and your incident write-ups. Treating an attacker-chosen quantity as a stationary property of your environment is the same category error as assuming a burglary rate is a property of a door. ### The regimes that break it - **Targeted adversary.** Prevalence is 1 by definition: every request they send is an attack. The dilution the restatement provides vanishes entirely and the operational rate they experience is the raw conditional rate — 12% of what they try works, and nothing stops them trying again. Any control justified purely by "it is only one request in eight thousand" is unjustified for this reader, who is usually the reader that matters. - **Campaigns and technique diffusion.** A method that starts as a research artefact and ends up in a widely shared prompt list can move population prevalence by orders of magnitude within days. The identical restatement recomputed a fortnight later tells a different story with no change whatsoever to your system. - **Launch and seasonality effects.** New surface, new audience, new prevalence. A free tier, a public API, or a consumer launch changes who is sending traffic. An estimate therefore has a shelf life and must carry a date. - **Composition shift at constant prevalence.** Even if the attack *share* holds steady, a change in which techniques dominate makes the corpus-derived conditional rate the wrong rate, because the corpus weighted techniques differently from reality. Both factors can be stale at once. - **Measurement drift.** If prevalence came from a stratified sample whose strata were defined by the old guardrail's flags, changing the guardrail invalidates the weights. The number keeps updating and quietly stops meaning anything. ### What it costs to keep honest Re-measuring prevalence is not free — a labelled sample is engineer-days each time, plus the standing cost of maintaining the labelling rule. That expense is the reason estimates go stale, and it is why the sustainable answer is a *trigger list* rather than a calendar: re-measure on a product launch that opens new surface, on a publicly circulated technique against this class of application, or on a sustained unexplained change in flagged-traffic volume or in the mix of techniques flagged. Between triggers, the number carries its date and the reader is told how old it is. Re-running the guardrail corpus, by contrast, is cheap — hundreds of API calls and minutes — so a stale *conditional* rate is far less excusable than a stale prevalence input. ### Where the restated number misleads The restatement was invented to stop a scary conditional percentage being misread as exposure. It fails when it becomes the opposite error: a comforting small number that silently assumes nobody has chosen to attack you. The failure is asymmetric and it is the dangerous direction, because a false alarm costs credibility while false reassurance costs an incident. Two related traps. A band computed across "plausible" prevalences is only as honest as the top of the band — if the high row was set by what felt reasonable rather than by what a campaign could produce, the band is decoration. And the alerting threshold matters: the composition of the flagged population shifts with prevalence too, so a threshold tuned at quiet-hours prevalence behaves differently during a burst, which is exactly when someone will be reading the alerts. ### How to present it so it survives the room State the conditional rate first, labelled with the population it describes, because it is the figure that does not expire when traffic mix changes. Show the ambient restatement as a small sensitivity band, never a single count. Add an explicit targeted-attacker line — prevalence 1, so the operational rate is the conditional rate. Attach a date and a source to the prevalence input and name the triggers that force re-measurement. Where a decision depends on which row of the band you land in, say so in the body rather than burying it. A deliverable that carries both readings, each labelled with its population, is the only version that is still true after everyone has forgotten the caveats that were said out loud.