Skip to content

Repeated-Trial Probability Calculator

Calculator — instantiates Eventual-Occurrence Containment Design

Converts a small per-opportunity probability and a large number of opportunities into the near-certainty of at least one occurrence over the whole horizon.

Repeated-Trial Probability Calculator is the smallest, sharpest tool in the set: it takes a per-opportunity probability p and a count of opportunities n and returns the probability the outcome happens at least once — 1 − (1 − p)ⁿ. That one line of arithmetic is the archetype's whole argument made numerical. A "one-in-a-million" event feels like zero until you multiply the chances; across ten million tries it is not zero but a near-certainty. The calculator exists to force that multiplication onto the table before anyone rounds a small per-chance number down to "won't happen." Its defining move — and its limit — is that it assumes the opportunities are independent; it is deliberately the naive engine, and knowing exactly where that assumption breaks is half of using it well.

Example

An API team ships an endpoint with a subtle race condition: on any given request there is roughly a one-in-two-million chance that two writes interleave and corrupt a record. In review, that number reads as ignorable. The calculator reframes it. The endpoint serves ≈5 million requests a day, so the per-day probability of at least one corruption is 1 − (1 − ½,000,000)^5,000,000 ≈ 92% — not "unlikely," but most days. Stretch n across a quarter and corruption is effectively guaranteed to have happened, probably many times over.

The number nobody would fund a fix for at the per-request scale becomes, at horizon scale, a near-certainty. That single recomputation moves the conversation from "is this worth fixing?" to "it is already happening — what contains it when it does?" — which is exactly the shift the archetype is built to force.

How it works

  • Take three inputs: the per-opportunity probability p (from assessment or observed data), the opportunity count n over the horizon (from the exposure register), and the horizon itself.
  • Return P(at least one) = 1 − (1 − p)ⁿ, and its complement — the vanishing probability of a clean run.
  • Optionally report the expected number of occurrences (≈ np for small p) and the horizon length at which P(at least one) crosses a chosen line ("50% by day 34").
  • Do one thing and refuse to launder it: this is transparent arithmetic, not a model of the system.

Tuning parameters

  • p, the per-opportunity probability — the single most consequential input; a factor-of-ten error in p moves the horizon at which occurrence becomes likely by the same factor. Source it honestly and carry its uncertainty.
  • n, the opportunity count — how many trials over the horizon. Doubling the horizon doubles n; growth in n is exactly what the exposure register tracks.
  • Independence assumption — whether trials are treated as independent. If occurrences cluster or share a cause, the naive formula understates the chance of a first hit and badly misstates the chance of many; this dial decides whether the number can be trusted at all.
  • Output framing — P(at least one), expected count, or time-to-threshold. Each answers a different question; pick the one the decision needs.

When it helps, and when it misleads

Its strength is clarity and speed: in one line it dissolves the "basically zero" intuition that lets teams under-defend against inevitable events, and it hands the Stop-or-Scale-Back Gate a concrete horizon-scale number to trigger on. Nothing else in the set makes the core point so cheaply.

Its danger is that the arithmetic looks authoritative while resting entirely on its inputs and one strong assumption. Trials are often not independent — a shared dependency, a bad deploy, or an attacker makes occurrences cluster — and applied blindly the formula returns a precise, confident, wrong answer; the independence question is not a footnote but the whole ballgame, which is why validating it is handed to Probabilistic Safety Assessment. The classic misuse is running it backwards: choosing the flattering p or the short horizon that lands cumulative risk just under an acceptable line, manufacturing permission to skip containment. The discipline is to treat p as uncertain (compute a range, not a point), state the independence assumption out loud, and remember the tool sizes the chance of occurrence — never its consequence.[1]

How it implements the components

  • per_opportunity_probability_bound — p is the tool's central operand; the calculator is built to carry a single-trial bound faithfully across many trials.
  • cumulative_occurrence_model — 1 − (1 − p)ⁿ is the cumulative-occurrence model in its simplest independent-trials form, plus the expected-count and time-to-threshold read-outs.

It only sizes the chance of occurrence. Defining what counts as the adverse outcome and checking whether the independence assumption even holds are Probabilistic Safety Assessment's; maintaining the live count *n is the Opportunity Exposure Register's; and everything about consequence, containment, and recovery belongs to other siblings.*

References

[1] The law of truly large numbers — with a large enough number of opportunities, even a very improbable outcome becomes probable (Diaconis and Mosteller). It is the honest core of this tool and the reason a per-chance probability can never be read without its n. ↩