Collision Probability Table¶
Reference artifact — instantiates Birthday-Bound Collision Budgeting
A precomputed grid of collision probabilities across namespace sizes and draw counts, so non-specialists can read off a safe volume — or the size a target risk requires — without redoing the math.
The Collision Probability Table is the birthday-bound arithmetic frozen into a lookup artifact. Rows are candidate namespace sizes (code lengths, digest bits, alphabet-and-length combinations); columns are draw counts; each cell is the resulting collision probability. Its defining virtue — the reason it exists alongside the raw calculation — is that it puts the answer before the math: a product manager or ops engineer who will never derive 1 − exp(−n²/2N) can still find the row where a million issued codes stays under one-in-a-million, and can read the table backwards to answer the design question — "how long must the code be?" — which is the calculation's sizing consequence made browsable.
Example¶
A retailer is about to run a promo with unique single-use coupon codes. Marketing wants short, human-typable codes; nobody wants two customers handed the same one. Instead of asking an engineer to model it, the team opens the standard collision-probability table. They locate their planned issuance (≈2 million codes) along the top and scan down the size column. A 6-character Base32 code (≈10^9 values) sits in a red cell — collisions near-certain at that volume. An 8-character code (≈10^12) lands in an amber cell; a 10-character code drops it to green. The table has converted a vague "codes feel plenty long" into a concrete rule: at this issuance, use at least ten characters — read straight off the grid, no derivation required.
How it works¶
- Precompute the grid once, from the birthday bound, over the size and volume ranges a domain actually uses — and freeze it as a shared reference.
- Read forward — enter with your
(size, volume)and read the probability cell — to sanity-check an existing design. - Read backward — enter with a volume and a tolerated probability and read off the smallest size that clears it. This reverse lookup is the sizing rule the table uniquely delivers.
- Colour-band the cells against typical risk tiers so the safe/marginal/unsafe verdict is legible at a glance.
What distinguishes it from the live calculation is that it trades flexibility for reach: fixed rows and columns, but usable by anyone, and standardised so every team sizes against the same numbers.
Tuning parameters¶
- Granularity — how finely rows and columns are spaced. Finer grids read more precisely but get unwieldy; coarse grids round toward the conservative cell.
- Rounding direction — whether borderline cells round up (toward more risk shown) or down. Rounding pessimistically keeps the table a safe default.
- Probability vs. safe-volume framing — publish the raw
pin each cell, or invert it to "max codes at this size for a 1-in-Xbudget." The inverted form is friendlier for sizing. - Effective-size columns — whether sizes are labelled by their nominal or their effective value (after excluding confusable characters); labelling effective prevents the most common misread.
When it helps, and when it misleads¶
Its strength is democratisation: it makes safe volumes visible to people who would otherwise guess, and it standardises the sizing decision so two teams don't pick incompatible code lengths. As a wall-chart or a page in a design guide, it is the archetype's most-used artifact.
It misleads when its fixed assumptions are read as universal. A table almost always assumes uniform, independent draws over a single shared space; a reader who applies it to biased generators, merged partitions, or a truncated hash[1] will read a green cell that is really red. It is also easily misused by picking the size the desired code length already implies and pointing at the table as justification. The discipline is to label the assumptions on the artifact itself and route any non-uniform or adversarial case to a review rather than the grid.
How it implements the components¶
pairwise_collision_estimate— every cell is a precomputed estimate; the table is the estimate reproduced across a whole range so it need not be recomputed.namespace_sizing_rule— the backward read turns a budget-and-volume into a required size (code length, digest bits, alphabet), which is the actionable sizing rule the archetype calls for.
It presents estimates but does not derive them for a novel case — that live computation is Birthday-Bound Calculation's. It does not model a specific system's effective space or projected draws (finite_namespace_model, draw_or_occupancy_count, acceptable_collision_budget) — that applied check is Identifier-Space Capacity Check's — nor does it judge whether the space's entropy is real (effective_entropy_assessment), which belongs to Namespace Entropy Review.
Related¶
- Instantiates: Birthday-Bound Collision Budgeting — the artifact that makes the archetype's sizing consequence usable without the math.
- Consumes: Birthday-Bound Calculation — the formula the grid is generated from.
- Sibling mechanisms: Birthday-Bound Calculation · Identifier-Space Capacity Check · Namespace Entropy Review · Hash Collision Risk Assessment · Capacity Warning Dashboard · Collision Retry Protocol · Domain-Separated Identifier Scheme · Duplicate Detection Audit · Adversarial Birthday-Attack Review
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: A precomputed grid of collision probabilities across namespace sizes and draw counts, so non-specialists can read off a safe volume — or the size a target risk requires — without redoing the math, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Collision Probability Table as 'A precomputed grid of collision probabilities across namespace sizes and draw counts, so non-specialists can read off a safe volume — or the size a target risk requires — without redoing the math', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Probability theory supplied the birthday bound and lookup tables relating namespace size, draw count, and collision risk.
Related originating lineages:
- Computer Science & Software Engineering — Identifier and hash design turn the probability table into a practical sizing artifact.
Review resolution: Both reviewers agree on mathematics as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains computer_science only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Dang, Q. Recommendation for Applications Using Approved Hash Algorithms. NIST Special Publication 800-107 Revision 1 (2012). Explains that truncating a hash digest reduces its collision resistance. registry ↩