A reachable majority is a probability event, not a correctness proof

For n replicas with a strict-majority threshold q=floor(n/2)+1, a quorum exists when at least q are available and mutually usable for the operation. In a simple count model, if K are unavailable, failure occurs when K exceeds n−q. Define unavailable carefully: a running process isolated from the leader may be unusable, while two separately observed healthy counts may not represent one communicating quorum. The model's observation point matters. Count failures for the same request or time horizon rather than mixing long-run node availability with a different operation's communication requirement.

If each replica is independently unavailable with the same probability p, K has a binomial distribution. Sum its upper tail from n−q+1 through n. This uses mutual independence and identical marginal probabilities; neither follows from replicas being on different machines. Different probabilities require a different calculation even under independence. Shared networks, common deployments, correlated repair, and load redistribution can all change the tail. A small numerical result is meaningful only if the model captures the mechanisms that can remove several required participants together.

A conditional mixture can add an environment that disables every replica with probability c, while normal-condition failures follow a binomial model with probability p0. Total no-quorum probability is c plus the weighted normal tail. The shared scenario prevents the probability from falling below c no matter how small the normal independent tail becomes. A more realistic fault domain may remove only part of the set, requiring a conditional count distribution for that domain. Map replica placement and communication dependencies before arguing that a larger odd number automatically improves the user's service.

Even when a reachable majority exists, correctness requires a protocol whose quorum intersections, state transitions, durable storage, and failure model support its claims. Crash-fault majority counting does not establish Byzantine tolerance. A stale leader, unsafe membership change, lost durable state, or read path bypassing required barriers can return incorrect answers while most replicas are up. The reliability lab's green majority indicator is intentionally limited to counts. Treat that indicator as a necessary resource condition in the declared model, not a certificate of linearizability, persistence, or safe recovery.

Record failures by domain, operation, and observation point. Exercise a partition with many processes still running, a restart after durable-state loss, and failover under realistic load. Compare the model's predicted no-quorum periods with actual failed operations rather than relying only on host uptime. A deployment can maintain the count while exhausting CPU on every survivor, making a nominal quorum too slow for the deadline. Include deadline and capacity conditions in the availability event when those are part of the objective, and keep causal diagnosis separate from a count correlation.

Use the binomial lab for the probability question. Reset, explicitly set BOTH unavailability p=0.1 and n=5, predict tail K≥3 equals 0.00856, then Play or Step. Edits retain elapsed t; playback highlights exact counts rather than sampling replica states. Separately, on paper, five replicas with two unavailable leave three up against threshold three; three unavailable leave only two. That arithmetic is a count condition, not a protocol. The instrument includes neither correlation nor communication, and its independent distribution must not be treated as evidence that real replicas can elect a safe leader or preserve acknowledged data.