In a billing pipeline, when is a Monte Carlo algorithm's error probability unacceptable but a Las Vegas one's variable runtime fine?

## Two contracts, named after casinos A randomized algorithm has to give something up, and there are two choices about what. **Las Vegas**: the answer is always correct, and the *runtime* is a random variable. You may wait longer than expected, but what you get is right. A shuffle-then-verify draw is one — reshuffle until the arrangement satisfies whatever constraint you require, and you leave with a valid arrangement, eventually. So is a pass that draws its pivots at random: correct on every run, with a finish time that varies. **Monte Carlo**: the runtime is bounded and the *answer* is a random variable. You get a result on schedule, and with some probability it is wrong — either wrong in the sense of an estimate that is off, or wrong in the sense of a yes/no answer that is occasionally mistaken. A sampled count over a stream is the everyday instance. Both are respectable. Neither is a weaker version of the other. What decides between them is not elegance but what happens downstream when the guarantee is exercised. ## The conversion in both directions The contracts are not far apart, which is why they get confused. Given a **cheap way to verify** an answer, any Monte Carlo algorithm becomes a Las Vegas one: run it, check the result, repeat until the check passes. Correctness becomes certain and the uncertainty relocates into how many attempts you need. This is why verifiability is the pivotal question in the design review — if checking is as expensive as computing, the conversion is not available. Going the other way is trivial and is done accidentally all the time: cap a Las Vegas run at a deadline and return whatever you have, or a default. You have just bought a Monte Carlo contract, whether or not anyone wrote that down. A timeout on an "always correct" routine silently converts correctness into a probability — a conversion that belongs in the design document, not in an operations config nobody reads. Note that lowering an error probability, by more sampling or by running several independent attempts and taking a majority, never reaches zero. Small is not none, and the difference matters exactly when the output has legal or financial weight. ## Choosing by consequence, not by taste The deciding question is never "how small can we make the error?" It is **what happens the first time the guarantee is exercised.** Where the output is money someone is held to — an invoice total, a payout, a tax figure, a settlement — a wrong answer is not a small deviation. It is a customer dispute, an auditor's finding, a correction with a paper trail, and a support cost far exceeding whatever the fixed runtime saved. And it is worse than an ordinary bug because it is *by design* unreproducible: the same input can produce the correct answer when you go looking. On-call cannot debug a contract. Where the output is already an estimate — a dashboard's unique-visitor count, a sampled log query, a capacity forecast, a health metric — the Monte Carlo contract is the honest one. Insisting on exactness there buys precision nobody consumes at a cost everybody pays, and it is the more common failure in practice: exact answers computed over full data because "exact is safer", at ten times the infrastructure bill, for a number that gets rounded before anyone reads it. Meanwhile a variable runtime, the thing Las Vegas gives up, is a problem operations solves for a living. It becomes tail latency, a queue, a batch window that occasionally runs long, a retry. Those are budgeted, alerted on and absorbed. That asymmetry — one failure mode lands on people who know how to handle it, the other lands on finance and support — is usually the whole argument. ## Owning the decision The call is a commitment, not an implementation detail, and it belongs where consequences land. Say it in the language of a service level: *"always exact, finishes between four and eleven minutes"* versus *"always eleven minutes, and roughly one run in a million is off"*. Put both to the owner of the consequence. Do not bury either one in a code comment. Three practices follow. Write down which contract each pipeline holds, so nobody adds a timeout to a Las Vegas job without noticing what they changed. Record the seed with each run, so a Las Vegas result can be replayed and a Monte Carlo result explained. And revisit the choice when the output's use changes — a sampled metric that starts feeding a billing rule has silently changed contracts, and that migration, not the algorithm, is where the incident comes from.