Is the Perfect Shuffle a Myth? Part 4 - The Machine Enters the Simulation

Written By Paradis

Part 1 asked why the Shuffle Master / One2Six should not be accepted as a black box.

Part 2 reconstructed the public mechanism as carefully as the sources allowed.

Part 3 explained why the table had to be built before the machine could be tested.

This part is where the machine enters the simulation.

That does not mean the project is complete. It means the project has moved from mechanism research and baseline construction into an executable model. The One2Six is no longer only a patent trail, a manual, a forum argument, and a set of modelling assumptions. It now exists as a configurable card source inside a working casino Blackjack simulation framework.

That is a major change.

The project is no longer asking only:

What might this machine be doing?

It can now begin asking:

If the machine works this way, what does the output look like?

Why the table had to come first

It was tempting to start with the shuffler.

That would have been the wrong order.

A shuffler simulation plugged into a sloppy blackjack engine would produce numbers, but the numbers would not mean much. The whole point of this project is to test whether a physical card source creates measurable structure. If the game engine gets the timing, settlement, discard order, or physical-card identity wrong, the shuffler result is contaminated before it even begins.

Blackjack is not just card totals and a dealer drawing to 17. For this project, the ugly procedural details matter. Busted hands are collected at specific times. Blackjacks settle differently. Doubles change total wager. Splits create multiple hands from a single box. Dealer blackjack after double or split has special accounting. Discards have order. Cards are physical objects that leave the layout and may eventually re-enter the card source.

Those details are usually irrelevant to a toy blackjack simulator. They are not irrelevant here.

The central question is not merely whether the player wins or loses a hand. The central question is how cards move through the system. If I want to test whether recently discarded cards can influence future output, then I need to know what was discarded, when it was discarded, in what order it was collected, when it was accepted by the card source, and when the same physical card appears again.

That is why the table came first.

The architecture now in place

The current codebase is structured around one important idea:

The card source is the experimental variable.

The blackjack engine should not care whether the next card comes from an IID generator, a finite shoe, a manual shoe, or a One2Six-style shuffler. It should ask the card source for the next card. The card source should supply it. Everything else should be measured behind that boundary.

The project now separates the main layers:

Layer Role
Card source Supplies cards from IID, finite shoe, manual shoe, or One2Six-style source
Game engine Runs the casino Blackjack hand flow and settlement logic
Strategy policy Chooses actions from legal actions
Result tracking Records wagers, outcomes, streaks, blackjacks, doubles, splits, busts, and edge metrics
Experiment framework Runs source-level and game-level diagnostics, metrics, plots, and comparisons

That separation is not cosmetic. It is the difference between a simulation and a pile of assumptions. If the One2Six model produces a result, I need to know whether that result comes from the shuffler, the game rules, the strategy, the discard timing, or the accounting layer.

The code now gives the project a way to isolate those pieces.

Casino Blackjack baseline

The casino Blackjack baseline now models the rule set closely enough to support shuffler experiments.

The current implementation includes:

Rule / behaviour Current model
Dealer hole card No initial hole card
Dealer upcard Dealer starts with one exposed card
Dealer soft 17 Dealer hits soft 17
Dealer hard 17 Dealer stands on hard 17
Blackjack payout 3:2
Player blackjack vs dealer blackjack Push
Surrender Not allowed
Doubling Allowed only on first two cards totalling 9, 10, or 11
Ace for double eligibility Ace counts as 1
Double after split Allowed if the split hand satisfies the 9/10/11 rule
Splitting Creates two hands with equal wagers
Resplitting Not allowed by default
Split aces Receive one card only
Split aces / split tens Cannot make blackjack
Dealer blackjack after double or split Original wager collected; double/split increments stand off
Busted hands Collected immediately

The strategy layer currently uses an approximate published H17 multi-deck strategy constrained by the implemented casino legal actions. It is not yet a solver-generated exact casino strategy, and I am not pretending otherwise. That will matter later if the project moves from sequence analysis into EV optimisation.

For now, the strategy is good enough for baseline comparison and engine validation. It is not the final word.

Discard timing became a first-class issue

One of the biggest corrections in the project was around discard timing.

The current model does not immediately return current-round discards to the card source at the end of the same round. Instead, it uses a staged discard-rack model:

Round N cards are collected into the discard rack.
Those cards become the pending discard rack.
They are not available during the next initial deal.
After the next round's initial deal, the pending rack is returned to the card source.

This is important because it creates a temporary exclusion window. The previous round’s cards are not available during the next initial deal. If the shuffler model later shows structure around recently returned cards, this timing detail will matter.

The discard rack is also ordered.

The implemented collection model includes:

  • busted hands collected immediately
  • immediate blackjack settlements collected immediately
  • remaining live hands left on the layout until final settlement
  • final collection by boxes in ascending order
  • hand-order preservation within each box
  • dealer cards collected last
  • no duplicate physical cards in the discard rack

This may look excessive for a blackjack sim. It is not excessive for this project. If the One2Six-style source preserves any local order, grouping, or timing effects, discard order becomes part of the equation.

Physical card identity

The card identity model now distinguishes between two concepts:

physical_id
    stable identity of the real physical card

draw_id
    identity of a specific deal/draw event

This is one of the most important design decisions in the project.

For an IID source, every draw can be treated as a fresh generated card. Physical-card recurrence is not meaningful, because the source has no physical memory. Symbol recurrence still matters.

For a finite shoe, manual shoe, or One2Six-style shuffler, the same physical card can be dealt, discarded, accepted back into the source, stored, shuffled or moved, and later dealt again.

That is the entire point.

If the simulation cannot distinguish a card type from a physical card, it cannot answer the One2Six question. A rank/suit result such as “ten of spades” is not enough. A six-deck game contains multiple physical ten-of-spades cards. The project needs to know whether the same physical card returned, not merely whether the same rank/suit appeared again.

The code now preserves physical identity across the card source, hand, discard rack, accepted discards, reshuffle, carousel shelf, output buffer, and later redraw.

That gives the project the basis for return-time analysis.

The card sources now implemented

The project now supports four card-source families.

Source Purpose
IID random source Mechanical validation and clean independent baseline
Finite shoe source Generic finite physical-card source with without-replacement dealing
Manual shoe source Casino-style manual shoe benchmark with cut-card penetration
One2Six-style source Configurable stateful model of the shuffler mechanism

The IID source is deliberately unrealistic. It deals independent random cards and treats each draw as new. That makes it useful for validating game mechanics, settlement logic, blackjack frequency, action handling, and streak calculations.

The finite shoe source introduces physical-card depletion. It draws without replacement and can accept discards for later reshuffle. It is useful for lower-level testing, but it is not the casino manual-shoe comparator.

The manual shoe source is the proper ordinary-shoe benchmark. It defaults to eight decks with configurable cut-card penetration, currently using 75% as the default assumption. Cards are dealt without replacement. Discards are unavailable until reshuffle. The source does not reshuffle mid-round. When the cut-card threshold is crossed, reshuffle is pending for the next round boundary.

The One2Six-style source is the new piece.

That is where the project changes.

The One2Six-style source

The implemented One2SixCardSource models the shuffler as a configurable stateful card source.

It has:

  • six-deck default
  • carousel shelves
  • shelf capacity
  • ordered feeder
  • output buffer
  • random shelf insertion
  • full-shelf ejection
  • buffer refill threshold
  • LIFO shelf ejection by default
  • fallback behaviour if no shelf meets the minimum ejection occupancy
  • telemetry
  • invariant checks

The current default assumptions are:

Parameter Current working value
Deck count 6
Carousel slots 38
Slot capacity 10
Output buffer target 18
Refill threshold 8
Minimum ejection cards 7
Ejection rule Whole shelf
Shelf order LIFO

These are working assumptions, not claims of exact production certainty.

This distinction matters. Part 2 of the series separated confirmed, inferred, speculative, and unknown claims. The simulator follows that discipline. The point is not to declare that the production One2Six definitely has these exact parameters. The point is to expose the assumptions so they can be swept later.

If an effect appears only at 38 slots and disappears at other plausible values, it is probably not robust. If an effect survives across plausible parameter families, it deserves more attention.

The implemented shuffler path

The current One2Six-style model can be summarised as:

initial pack / accepted discards
    -> ordered feeder stack
    -> bottom card of face-up stack fed first
    -> random carousel shelf selection
    -> card inserted onto shelf
    -> shelf retains order
    -> output buffer filled from shelf ejections
    -> dealer draws from front of buffer
    -> when buffer reaches threshold, eligible shelf is selected
    -> whole shelf ejected into back of buffer

The model deliberately preserves ordered input. If cards enter the feeder in a particular order, the model allows that order to matter. New cards are appended to a shelf, representing a physical stack. Under the current LIFO assumption, if a shelf receives:

A, B, C

where A entered first and C entered last, then ejection sends:

C, B, A

to the output buffer.

That may or may not be the exact production behaviour. It is a modelling assumption. But it is an explicit assumption, which means it can be tested, replaced, or swept.

The dealer draws from the front of the output buffer. Ejected shelf groups are appended to the back. When the output buffer reaches the refill threshold, shelves are ejected until the buffer returns to target or above.

That gives the model a real state.

Cards are no longer abstract events. They have locations.

They can be in the feeder, on a shelf, in the buffer, on the table, in the discard rack, or outside the source awaiting return.

That is the beginning of a real shuffler simulation.

Telemetry and invariants

A simulation like this is easy to get wrong.

Cards can duplicate. Cards can disappear. A shelf can exceed capacity. A discard can be accepted twice. The output buffer can contain an impossible state. Physical identity can be lost accidentally. Those errors may not crash the simulation, but they would destroy the analysis.

For that reason, the One2Six source now records telemetry and checks invariants.

The telemetry includes:

  • physical card IDs
  • shelf IDs
  • event order
  • buffer sizes
  • ejection records
  • accepted discard batches
  • fallback ejection flags

The invariant checks include:

  • no duplicate physical cards inside the source
  • no shelf exceeding capacity
  • output buffer uniqueness
  • source-plus-external completeness where appropriate
  • physical identity preservation

A diagnostic smoke test produced:

draws: 100000
unique physical IDs seen: 312
ejection count: 10449
fallback ejection count: 0
invariant check: passed

This does not prove an edge. It does not even prove the model is correct.

It proves something more basic and more important at this stage: the source can run at meaningful scale while preserving the expected number of physical cards and avoiding obvious state corruption.

Before interpreting any shuffler result, the model has to survive that kind of boring check.

Result tracking

The result layer has also become more serious.

The system now separates:

initial_wagered
action_wagered
total_wagered
net_profit
edge_per_initial_wager
edge_per_total_wager

That separation corrected an earlier interpretive trap. A blackjack frequency must be calculated from initial hands, not from initial dollars wagered.

For example:

465 blackjacks / $100,000 initial wagered = 0.465%

That is not a blackjack rate.

The correct denominator is the number of initial hands:

465 blackjacks / 10,000 initial hands = 4.65%

That is consistent with the expected IID blackjack rate of about 4.7337%.

This is exactly the kind of mistake that can quietly poison a simulation project. If the denominator is wrong, the result looks meaningful while saying nothing. That is why accounting is part of the research, not admin.

Streak tracking

The project now tracks win/loss streaks in a way that matches bankroll direction.

The key rule is:

Pushes do not break streaks.

So:

W W P W -> win streak of 3
L L P L -> loss streak of 3
W P L   -> win streak of 1, loss streak of 1

This is the right definition for the project because a push does not move the bankroll. If the goal is to detect clustering or anti-clustering in outcomes, it makes no sense for a neutral result to break the streak mechanically.

The system now tracks:

  • current win streak
  • current loss streak
  • max win streak
  • max loss streak
  • full win streak distribution
  • full loss streak distribution
  • signed streak distribution

For signed plots, loss streaks appear on the negative x-axis and win streaks appear on the positive x-axis.

This will matter later. If a One2Six-style source produces streak distributions that differ from IID or manual shoe baselines, that is not proof of an edge, but it is a signal worth investigating.

Sample outputs so far

The project can now run casino Blackjack against multiple card sources.

The following outputs are smoke-test level only. They demonstrate that the machinery runs and records results. They are not final EV estimates and they are not evidence of exploitability.

IID Casino Blackjack sample

Rounds: 10000
Base bet: $10.00
Card source: iid
Deck count: 6
Initial wagered: $100,000.00
Action wagered: $11,810.00
Total wagered: $111,810.00
Net profit: $-1,055.00
Player edge per initial wager: -1.0550%
House edge per initial wager: 1.0550%
Player edge per total wager: -0.9436%
House edge per total wager: 0.9436%
Blackjacks: 465
Doubles: 910
Splits: 271
Busts: 1733

Manual shoe sample

Rounds: 10000
Base bet: $10.00
Card source: manual-shoe
Deck count: 8
Cut-card penetration: 75.00%
Shuffle count: 170
Initial wagered: $100,000.00
Action wagered: $12,020.00
Total wagered: $112,020.00
Net profit: $-420.00
Player edge per initial wager: -0.4200%
House edge per initial wager: 0.4200%
Player edge per total wager: -0.3749%
House edge per total wager: 0.3749%

One2Six-style sample

Rounds: 10000
Card source: one2six
Output buffer size: 17
Ejection count: 5512
Fallback ejection count: 0
Net profit: $420.00
Player edge per initial wager: 0.4200%
Player edge per total wager: 0.3759%

The One2Six sample is not the interesting result.

A 10,000-round positive result with an approximate strategy and an assumed shuffler model is not evidence of an edge. It is variance until proven otherwise. The correct next step is not interpretation. The correct next step is diagnostics.

The article would be dishonest if it pretended otherwise.

Test status

The project has grown quickly, but the tests have grown with it.

The latest verification state was:

python -m pytest                 157 passed
python -m ruff check .           passed
python -m ruff format --check .  passed
python -m mypy src               passed
IID smoke experiment             passed

The test count increased as the project expanded:

68 tests  -> initial casino baseline
95 tests  -> audit and discard correction
108 tests -> finite shoe and identity
127 tests -> manual shoe and streaks
144 tests -> One2Six source
157 tests -> experiment framework

That progression matters because the hard failure modes are not obvious. A blackjack sim can look like it works while silently reusing cards incorrectly, returning discards too early, losing physical identity, misaccounting doubles, or calculating rates from the wrong denominator.

Those are exactly the errors this project cannot afford.

Why this is now a serious project

The project has crossed an important line.

Before this stage, the series had a question, a mechanism reconstruction, and a baseline argument. That was useful, but it was still mostly conceptual.

Now there is an executable framework.

The game and table mechanics are coded.

The card sources are modular.

The One2Six-style source exists.

Physical identity is preserved.

Discard timing is explicit.

Telemetry is captured.

Invariants are checked.

The experiment layer is separate from the engine.

That is the difference between having an idea and building the machinery to test it.

This is also why the project still has to stay disciplined. The existence of a One2Six source does not mean the source is correct. The source is a working hypothesis. It is a model of a plausible random-in, group-out shuffler mechanism. The next stage is to compare it against baselines and ask what changes.

The simulator is not there to confirm my suspicion.

It is there to make my suspicion answerable.

What comes next

The next stage is not exploit strategy.

The next stage is validation.

The IID source needs a large baseline run. The current smoke experiment works, but a 1,000-round or 10,000-round run is not enough to validate the measurement layer. The next proper IID experiment should run at much larger scale and verify the obvious things first:

  • rank frequencies
  • suit frequencies
  • blackjack rate
  • ten-value rate
  • ace rate
  • Hi-Lo value distribution
  • target-card recurrence
  • rank-level recurrence
  • win/loss streak distributions
  • outcome rates
  • cumulative profit behaviour

The recurrence model matters. Inter-arrival time for a target card is geometric, not Poisson. A fixed-window count can be approximated with binomial or Poisson models, but “how many cards until this target appears again?” is a geometric question.

That may sound like a minor distinction. It is not. The project is about recurrence, latency, and return times. The baseline distribution has to be right before the One2Six distribution can be interpreted.

After IID validation, the same diagnostic framework needs to be applied to the manual shoe and then to the One2Six-style source. Only then does the comparison become meaningful.

The important future measurements are:

  • physical-card return time
  • first reappearance after discard
  • same-discard-batch clustering
  • shelf ejection group sizes
  • output buffer occupancy
  • carousel occupancy
  • neighbour reappearance
  • rank and value autocorrelation
  • outcome streak distribution
  • comparison against IID and manual shoe baselines

This is where the project becomes evidence-based.

If the One2Six-style model produces no measurable difference, that is a result.

If it produces measurable structure that cannot be observed before betting, that is also a result.

If it produces observable and stable structure, then the project gets more interesting.

But that question comes after diagnostics, not before.

Current conclusion

The machine is now in the simulation.

That is the milestone.

The project has moved from:

research idea + baseline blackjack scaffold

to:

tested simulation engine + One2Six-style card source + experiment framework

The next question is no longer whether the project can be built. The next question is whether the model produces card-stream structure that differs from IID and manual-shoe baselines.

That is the right question.

Not “can I win?”

Not “is the machine rigged?”

Not “does a 10,000-hand smoke test show profit?”

The question is:

Does this mechanism preserve measurable structure?

If it does, the next question becomes whether that structure is observable and exploitable.

If it does not, the machine survives this stage.

Either way, the black box is no longer closed.

References and source notes

  • mathematical-ev/shufflemaster-simulation GitHub repository. Public code repository for the simulation framework.
  • Project README. Documents the long-term purpose, architecture principles, baseline commands, card-source separation, discard-rack timing, and physical-card identity model.
  • src/shufflemaster_sim project package. Contains the simulation engine, card sources, games, strategies, and result-tracking code.
  • scripts/run_star_blackjack_baseline.py. Command-line runner for baseline casino Blackjack simulations using different card sources.
  • experiments/ framework. Separate experiment layer for metrics, plots, runners, output artifacts, and source/game diagnostics.
  • CARD one2six User Manual, 10.02.2005. Useful for One2Six operating procedure, multi-deck operation, discard insertion timing, front shoe, wheel, and inventory behaviour.
  • US Patent 6,659,460 B2, Card shuffling device. CARD / Shuffle Master patent family describing compartment-based card-handling architecture.
  • US Patent 6,889,979 B2, Card shuffler. Describes card forwarding into compartments, card counting, randomised compartment/drum movement, and group ejection in described embodiments.
  • US Patent Application 2015/0196834 A1. Identifies ONE2SIX as a CARD-developed compartment shuffler disclosed in US 6,659,460 and US 6,889,979.
  • Bertsekas and Tsitsiklis, Introduction to Probability. Useful background for treating the shuffler as a probabilistic model with a defined generating process.
Paradis
Next

Is the Perfect Shuffle a Myth? Part 3 - Building the Baseline Before the Machine (or Now the Fun Begins)