The One2Six Advantage-Play Project, Part 4: Building the Simulator with Physical-Card Tracking

21 June

Written By Paradis

From a reconstructed mechanism to a working stateful card source

Part 3 defined the experimental design required to test the One2Six properly. By the beginning of Part 4, the project had reached the stage where diagrams, manuals and architectural plans had to become executable choices.

I enjoy this stage of a project because ambiguity loses most of its places to hide. A patent can refer to a compartment without specifying how cards are ordered inside it. Software eventually demands an answer: how many compartments exist, how much each one can hold, which card enters first, which card leaves first and what happens when the preferred action is impossible. Every unresolved detail either becomes an explicit parameter or quietly turns into an assumption embedded in the code.

I strongly prefer the first option. Hidden assumptions have a habit of returning several weeks later dressed as established facts.

During this stage, the blackjack engine, physical-card model, discard procedure and first configurable One2Six-style source were brought together into a working simulation. Physical cards could be dealt, collected in order, held outside the machine, returned through the feeder, stored inside carousel compartments, moved into an output buffer and eventually dealt again while retaining their identities.

The reconstructed machine had become something I could run, inspect and attempt to break.

What Had to Be Built

The central design principle from Part 3 remained in place: the card source would be the experimental variable. The blackjack engine would request the next card through a common interface, while the source determined how that card became available.

An IID generator, finite shoe, manual casino shoe and One2Six-style mechanism could therefore operate inside the same game. The rules, strategy, settlement and result accounting would remain unchanged while the card-generating process moved underneath them.

The codebase was divided into layers with separate responsibilities:

Layer	Responsibility
Card model	Represents rank, suit, physical identity and individual draw events
Card source	Supplies cards and accepts ordered returned batches
Game engine	Runs the deal, player hands, dealer play and round flow
Strategy policy	Chooses actions from the legal actions available
Settlement layer	Resolves wagers, blackjacks, doubles, splits and pushes
Result tracker	Records outcomes, exposure, profit and streaks
Experiment framework	Runs controlled comparisons and source diagnostics

This separation allowed the card source to change without requiring a second version of blackjack to be written around it. When the sources were eventually compared, differences in output would not be tangled with different implementations of dealing, settlement or strategy.

It also gave the project room to evolve. The One2Six reconstruction was still based on incomplete public evidence, so its internal assumptions were likely to change. Keeping those assumptions within the source meant that a new compartment rule or buffer configuration would not require the surrounding game to be rebuilt.

The Casino Blackjack Engine

The engine needed to reproduce the flow of cards through the casino game being studied rather than merely calculate hand totals.

The implementation covered:

initial dealing order;
legal player actions;
natural blackjacks and ordinary twenty-ones;
doubles and additional wager exposure;
split hands and their separate settlement;
dealer play;
bust collection;
player and dealer card collection;
round boundaries;
the timing with which completed discard racks returned to the source.

The strategy used during this stage was a published multi-deck baseline constrained by the legal actions available under the implemented rule profile. Its purpose was to generate consistent decisions while the mechanics were tested. Any strategy designed to react to the One2Six would come much later, after the project had shown that the machine produced information available to a player before a decision.

At this point, changing strategy between card sources would only make the comparison harder to interpret.

The Discard Rack Became Part of the Game State

One of the first implementation risks was returning cards to the shuffler too early.

A simple simulator could finish a round, place every card into a discard list and immediately make those cards available again. That would simplify the code while removing part of the physical process that motivated the project.

The implemented procedure stages each completed rack:

Round N is played.

Cards are collected into an ordered discard rack.

That rack remains outside the card source during
the initial deal of Round N + 1.

After the next initial deal, the pending rack is
accepted by the source.

This creates a temporary exclusion window. Cards visible in the completed rack from the previous round cannot appear during the next initial deal because they have not yet returned to the machine.

The rack also preserves the order created by the table. Busted hands are collected when they leave play, while immediate settlements are collected at the appropriate stage. Remaining player hands stay on the table until settlement, boxes are collected in ascending order, split hands retain their hand order and the dealer’s cards are collected after the player hands. The implementation also prevents the same physical card from being collected twice.

The eventual analysis may show that collection order has little influence on the output. The simulator still needs to retain that information long enough to test the question. Throwing it away in the game engine would decide the result before the card source had processed a single batch.

Physical Cards and Draw Events

A six-deck game contains several cards with the same rank and suit. Six separate physical objects can all be represented as the ten of spades, which means rank and suit alone cannot support recurrence analysis.

The card model therefore uses two identities:

physical_id
    Stable identity of one physical card.

draw_id
    Unique identity of one appearance of that card.

If one particular ten of spades is dealt, returned through the machine and later appears again, both deals share the same physical_id. Each appearance receives its own draw_id.

The stable identity remains attached to the card as it moves through the full process:

source
    -> hand
    -> table
    -> discard rack
    -> accepted discard batch
    -> feeder
    -> carousel shelf
    -> output buffer
    -> later draw

This makes it possible to measure how long a specific card remains absent, whether cards collected together later emerge near one another and whether adjacency in the discard rack survives passage through the machine.

Without physical identity, the simulator could count how often a ten appears. It could not determine whether one physical ten returned after twenty draws or whether another copy had appeared instead. Since the project is concerned with mechanical memory, that distinction is fundamental.

The Card Sources Implemented

By the end of this stage, the blackjack game could run against four source families:

Source	Purpose
IID random source	Validates card frequencies and game mechanics under independent draws
Finite shoe source	Introduces stable physical cards and dealing without replacement
Manual shoe source	Provides a conventional casino comparator with penetration and reshuffle behaviour
One2Six-style source	Models the stateful compartment mechanism reconstructed in Part 2

The IID source creates each draw independently. It provides a clean baseline for card frequencies, strategy flow and settlement, although it has no meaningful concept of one persistent physical card returning through a system.

The finite shoe contains persistent cards and deals without replacement. Accepted discards remain unavailable until an explicit reshuffle policy returns them to the playable population.

The manual shoe adds cut-card penetration and round-boundary reshuffling. It therefore provides a casino comparator with depletion and physical card persistence, while remaining mechanically different from the continuous source.

The One2Six source was the main implementation milestone because it brought together the feeder, carousel, compartment storage, output buffer and delayed discard return inside one stateful system.

The First One2Six-Style Source

The One2SixCardSource represented the reconstructed mechanism through:

an ordered feeder;
a carousel of internal shelves;
configurable shelf capacity;
random shelf selection for incoming cards;
ordered cards within each shelf;
whole-shelf ejection;
a front output buffer;
a refill threshold and target;
fallback behaviour when no shelf satisfied the preferred ejection rule;
detailed telemetry;
state-invariant checks.

The code uses the word shelf for the simulated equivalent of a physical compartment.

The first working configuration was:

Parameter	Initial working value
Deck count	6
Carousel shelves	38
Shelf capacity	10
Output-buffer target	18
Refill threshold	8
Minimum preferred ejection size	7
Ejection unit	Whole shelf
Order within shelf	Last-in, first-out

These values were explicit modelling assumptions. The public evidence supported a compartment wheel, individual card feeding, multi-card storage and group output as a plausible mechanism family. It did not establish every value in the configuration table as a property of a production One2Six.

Exposing the choices through configuration allowed later experiments to move them independently. A result that survived across several reasonable configurations would deserve more weight than one dependent on a single convenient combination.

The Implemented Card Path

The first source followed this sequence:

initial pack or accepted discards
    -> ordered feeder
    -> one card fed at a time
    -> random carousel shelf selected
    -> card added to that shelf
    -> cards remain ordered within the shelf
    -> eligible shelf selected for output
    -> whole shelf ejected into the back of the buffer
    -> dealer draws from the front of the buffer

The feeder retained the order in which cards were accepted. Under the initial convention, the physical bottom card of the returned face-up stack entered first.

Cards were appended to the selected shelf. The initial last-in, first-out rule meant that a shelf receiving:

A, B, C

would later release:

C, B, A

into the output buffer.

The public material did not settle this detail, so the choice was implemented as a named policy rather than buried inside the source. That made the assumption visible in the code and straightforward to replace when testing alternative compartment behaviour.

This is a recurring preference in how I build models. I am comfortable making assumptions where the evidence runs out, provided I can still find them later.

The Output Buffer

The dealer draws from the front of the output buffer rather than directly from the carousel. When the buffer reaches its refill threshold, the source selects eligible shelves and appends their contents to the back until the target level has been restored.

This creates a separate state between the carousel and the table. A card recently added to the machine must wait for its shelf to be selected, for that shelf to be ejected, for the cards already present in the output buffer to be dealt and for its own position within the released group to reach the front.

The production buffer capacity and refill policy remained uncertain, but the implementation now provided a way to vary those assumptions and observe their effects on return time, recurrence and short-horizon composition.

The buffer also made clear why a single measure of “shuffle delay” would be inadequate. Two cards entering the carousel together could experience the same shelf delay and still reach the dealer at different times because of their relative positions inside the ejected group and the cards already waiting ahead of them.

Telemetry

A stateful source needs to explain how it produced its output. Otherwise, an unusual recurrence pattern might be visible in the results while the mechanism responsible remained hidden inside the simulation.

The source recorded:

physical card IDs;
shelf assignments;
feeder events;
insertion order;
shelf ejections;
ejection group sizes;
output-buffer sizes;
accepted discard batches;
fallback ejection events;
event sequence numbers.

This telemetry was designed for diagnosis and experiment analysis. It does not represent information available to a player at the table.

That separation would become important in later work. Internal state can show why an effect exists, while any advantage strategy must be restricted to information the player can actually observe. Allowing the strategy to read shelf assignments or buffer contents would produce an excellent result against a game that does not exist.

During Part 4, the immediate priority was giving the source enough internal visibility to debug its behaviour and trace individual cards through the mechanism.

Invariants

A stateful physical-card simulation can enter an impossible state without crashing. A card may be duplicated, disappear, remain in two locations at once or be accepted twice in the same batch while the game continues to generate plausible hands and respectable-looking plots.

The source therefore checked invariants covering:

duplicate physical cards within the source;
duplicate cards across internal locations;
shelf-capacity violations;
duplicate cards in the output buffer;
preservation of the expected physical-card population;
consistency between cards inside and outside the source;
stable physical identity through repeated returns.

These checks were more important than any early profit estimate. Before the simulator could investigate whether a machine using six decks produced an edge, it needed to demonstrate that it still possessed six decks.

A casino might have questions if a seventh ten of spades emerged. A Monte Carlo run would probably continue without comment.

The First Large Source Diagnostic

The first meaningful source diagnostic drew 100,000 cards through the One2Six-style mechanism.

It produced:

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

All 312 physical cards appeared during the run. The source completed more than ten thousand shelf ejections, never required its fallback rule and passed the state checks.

This result established that the implemented mechanism could operate at useful scale while preserving its complete physical-card population. Questions about the accuracy of the reconstruction and the existence of an edge remained open, but the model had passed its first operational gate.

For me, that was the point at which the project began to feel real. A conceptual mechanism can remain agreeable for a long time because it has not yet been asked to survive one hundred thousand state transitions.

Result Accounting

The game layer also required more careful accounting before economic comparisons could be trusted.

The result tracker separated:

initial_wagered
action_wagered
total_wagered
net_profit
edge_per_initial_wager
edge_per_total_wager

initial_wagered measures the money committed before the deal. action_wagered records additional exposure from doubles and splits, while total_wagered combines the two.

This distinction became important after an early denominator mistake. I had divided the number of natural blackjacks by dollars wagered. The calculation produced a percentage with several decimal places and answered the wrong question with impressive confidence.

Natural blackjack frequency belongs over the number of initial hands:

player natural blackjacks / initial hands

Monetary edge belongs over wager exposure. Separating event denominators from financial denominators prevented ordinary accounting errors from becoming apparent discoveries about the shuffler.

I do not mind finding mistakes during development. I mind leaving them in the results after I know they are there.

Streak Tracking

The engine also recorded win and loss streaks using the net result of the active box for each completed round. Pushes were treated as neutral observations that did not interrupt the existing streak:

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

A push leaves the bankroll unchanged, so breaking the sequence at that point would alter the run-length distribution without a corresponding change in the financial outcome.

The tracker retained current streaks, maximum streaks and the full distribution of win and loss runs. Signed plots could then place losses on the negative axis and wins on the positive axis.

Streak analysis was included because serial dependence might appear in game outcomes even if the long-run mean remained close to the baselines. Whether this metric would prove useful remained an experimental question.

Verification Status

At the end of the implementation stage, the project passed:

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 suite covered the main game rules, settlements, physical identities, shoe behaviour, discard timing, streak handling and One2Six source mechanics.

Passing these checks could not validate the reconstruction against a production machine. It did provide evidence that the software behaved consistently with the mechanism and game rules I had defined.

That distinction matters because the next stages depend on two separate questions. The first concerns whether the model has been implemented correctly. The second concerns whether the model itself is a useful representation of the real process. Confusing those questions would allow a thoroughly tested assumption to masquerade as a confirmed fact.

What Part 4 Established

By the end of Part 4, the project contained:

a working casino blackjack engine;
interchangeable card sources;
persistent physical-card identities;
ordered discard-rack collection;
delayed return of completed racks;
a manual-shoe comparator;
a configurable One2Six-style source;
internal carousel shelves and output buffering;
telemetry for source diagnostics;
invariants protecting the physical-card population;
result and streak tracking;
a separate experiment layer.

The One2Six source remained a working reconstruction whose parameters represented assumptions rather than production claims. Its value at this stage came from making those assumptions executable, observable and replaceable.

The simulator could now run the same blackjack table against several card-generating processes while preserving the physical history of every card. That gave the project an experimental foundation, although the measurement framework still needed to demonstrate that it produced correct answers in cases where the correct answers were already known.

Where the Project Stood After Part 4

The next stage was baseline validation. Before interpreting One2Six recurrence, profit or streaks, the IID source needed to behave like IID, the manual shoe needed to reproduce finite-shoe behaviour, natural blackjack rates needed to use the correct denominator and target-card waiting times needed to match the appropriate theoretical distributions.

Part 5 therefore moves from implementation into validation. The objective is to test the simulator against known behaviour before allowing it to make claims about unknown behaviour.

The machine was now inside the simulation. The next task was to establish whether I had earned the right to believe anything it said.

References

mathematical-ev/shufflemaster-simulation. Public repository containing the blackjack engine, card-source interfaces, physical-card model, One2Six-style source, tests and experiment framework.
CARD one2six User Manual, 10 February 2005. Relevant to the production operating procedure, front shoe, internal wheel, discard insertion and card inventory.
US Patent 6,659,460 B2: Card Shuffling Device. Describes the CARD rotating compartment drum, individual card feeding, multi-card storage and output receivers.
US Patent 6,889,979 B2: Card Shuffler. Describes individual card insertion, per-compartment counts, randomised compartment selection and whole-compartment group ejection in a described embodiment.
US Patent Application 2015/0196834 A1. Explicitly connects the ONE2SIX commercial mechanism to the CARD compartment-shuffler patent family.

Paradis