Build journal · Building an AI casino under audit discipline · Episode two

The 1410% Error

The first time Plinko rendered, it published a return to player of 1410.82%. The game looked perfect — ball dropped, multipliers sat in the interface, payouts arrived — and a hand-typed label would have read 96% over that same broken board for as long as the page existed.

Plinko is the simplest probability object in a casino. Twelve rows of pegs, a ball that goes left or right at each one with equal chance, and thirteen slots at the bottom. Twelve fair coin flips, which means the landing slot follows a binomial distribution: the centre slot is reached 924 times in 4,096, and each outer edge exactly once in 4,096.

You price it by putting large multipliers where the ball rarely lands and small ones where it lands constantly. The array used here runs 40, 10, 4, 2, 1, 0.6, 0.3 from the edge inward, then mirrors back out. Multiply each slot’s probability by its multiplier, sum the thirteen products, and the return is 96.3281%.

What went wrong

The array was assembled from a half-array and its reverse. That is a reasonable way to build a symmetrical thing and it is where the error entered: the halves went together in the wrong order, so the sequence ran 0.3, 0.6, 1, 2, 4, 10, 40 from the edge inward instead of outward.

The 40× multiplier landed in the centre slot. The slot the ball reaches 924 times in 4,096 was paying forty to one, and the 1-in-4,096 edges were paying 0.3×.

Read the last two columns and the fault is obvious. Read the running game and it is invisible. Nothing about a Plinko board tells a player what the multipliers ought to be — the numbers are arbitrary by nature, printed on the slots, and a 40 in the middle looks exactly as plausible as a 40 on the outside to anyone who has not done the arithmetic.

What caught it

Not testing. Not a review. Not a player noticing that the game paid too well, which would have taken a long time and a lot of coins.

The page printed the number.

The rule on this platform is that no number describing a game is written by a human. Every published return is computed at load, in the browser, from the same constants the game reads to play — the paytable, the reel strip, the multiplier array. So the label is not a claim about the game. It is a measurement of the game, taken in front of whoever is looking.

A return above 100% is impossible in a game with a house edge, so 1410.82% was not a subtle discrepancy requiring investigation. It was an absurdity sitting in the interface at first render, before deployment, before anyone played a round. The array was rebuilt edge-to-centre-to-edge, the figure recomputed at 96.3281%, and the result checked by hand against the binomial coefficients.

The version where nobody finds out

Now run the same mistake through the ordinary process, the one nearly every operator uses.

A developer builds the board. A mathematician certifies the intended design and issues a report stating 96.33%. Marketing takes 96.33% from the report and puts it on the page. The reversed array ships, because the certificate describes the design and the page describes the certificate, and neither of them describes the code.

The label would have said 96% forever. Not through dishonesty — every person in that chain acted in good faith on the document in front of them. The number simply had no mechanical connection to the thing it described, and once that connection is missing, no amount of diligence downstream restores it.

The failure mode this exposes is not specific to AI. It is what a static number always is: a claim about a past state of the code, printed as though it were a property of the running game.

Why an AI build makes this worse, and easier

Worse, because volume. An AI produced twelve games in one night, and a reversed array is exactly the class of error that arrives with speed — not a conceptual mistake but a mechanical one, in code that reads correctly and computes something else. Reviewing twelve games by eye at three in the morning finds the errors a human would make, not the errors that come from assembling arrays quickly.

Easier, because there was never a hand-typed number to protect. When production is close to free, computing the figure at load costs nothing next to writing it down, and a project with no legacy labels has no reason to keep any. The rule was affordable because the whole thing was built after it.

This is the second time the method has caught its own author. In July, Faro Dorado published 94.7% and a five-million-spin audit measured 92.38% — the paytable did not return what the label promised, the paytable was re-solved, and the published figure moved to 94.6%. That error was a human’s. This one was an AI’s. The ledger does not distinguish, and the correction path was identical.

What is on the record

Every mistake made building this platform is logged with what caught it and what changed — the reversed array, a baccarat rendering fault that reached production for about twenty minutes, dead code left in a working file, a batch delete that swallowed its own error message. The ledger is kept because a methodology that has never caught anything is untested, and the entries are the evidence that this one is not.

The error was found by arithmetic that ran in public, and the fix is checkable in the same place: open Plinko, read the multipliers off the board, and redo the sum.

Flickloot editorial. Written with an AI build partner; the workflow, the division of labour and the error ledger are documented at /methodology/. Gold Coins cannot be purchased, redeemed, transferred, or exchanged for anything. They have no value of any kind. 18+.