Why Repeated Results Do Not Prove a Random Picker Is Broken
Independent trials are trials in which the outcome of one draw does not change the probabilities assigned to the next draw.
A worked example with numbers
A four-item lunch picker contains Soup, Rice, Tacos, and Salad. The first result is Tacos. If the list stays unchanged and the tool selects with replacement, the next result has a 1/4 chance of being Tacos again. The chance of Tacos on all three draws is (1/4) × (1/4) × (1/4) = 1/64, about 1.56%. That particular sequence is uncommon, but so is every specific three-result sequence such as Soup, Rice, Salad. Seeing a pattern feels special after it appears; the model assigned the same probability to each named sequence before drawing.
How to set the rule before the result
First ask which model the task needs. A single item picker leaves every entry eligible for the next independent selection. A remove-after-pick selector produces an order without repeats because it shuffles the full population. A list shuffler is also without replacement: after the first name occupies position 1, it cannot appear in position 2. A repeat is expected in the first model and a defect in the second.
Common mistakes that change the odds or the process
The usual error is rerunning until a more varied-looking sequence appears. That converts a test of the process into a preference for a result, and it makes the retained run no longer representative of a single declared procedure. Another error is applying “due” logic: after three Reds, Blue is not owed a turn when the probabilities are independent. A third error is treating repeated labels as repeated outcomes; if a list contains two rows labelled “Alex,” check whether that is one person duplicated or two different people with the same display name.
Where this method stops being appropriate
A repeat should trigger an input and model check, not a reflexive accusation. Confirm the list length, duplicate policy, intended replacement rule, and whether two people were looking at the same frozen inputs. Then run a modest diagnostic only if the implementation itself is in doubt, recording all trials rather than selecting a favourable subset. No small sample can prove a generator fair; it can only reveal obvious departures, such as an option that never appears across a large recorded run.
How the random source fits into the rule
This reasoning does not validate a high-stakes drawing. An informal browser sequence cannot demonstrate regulatory compliance, identity verification, or a secure audit trail. NIST describes statistical tests as hypothesis tests under a null model in NIST SP 800-22; a streak is one observation, not a complete assessment. For casual choices, make the rule visible and preserve the first agreed result. For an actual no-repeat requirement, choose the no-repeat tool instead of expecting independent trials to imitate it.
Count opportunities for a streak, not only the streak you noticed
A person usually notices a repeated result after many possible patterns have already passed. In 20 coin flips there are 18 overlapping runs of three positions; the chance that at least one run looks striking is far larger than the chance of one pre-named run such as HHH. This is why surprise is a poor diagnostic. The question “what was the probability that something unusual-looking would appear?” is different from “what was the probability of this exact sequence before it started?”
Use the correct corrective action. If the task requires unique winners, switch to a shuffled finite list. If it requires independent experiments, retain replacement and accept repeats. If a technical defect is suspected, define a sample size and record every output before viewing it; do not stop when a preferred pattern emerges. The same discipline protects people from both false alarm and false reassurance. A short, selected history is not evidence that any option was favoured.