Is the Perfect Shuffle a Myth? Part 3 - Building the Baseline Before the Machine (or Now the Fun Begins)
Now the fun begins!
The easy version of this project would be to look at the Shuffle Master One2Six, decide it “feels” streaky, and start inventing stories.
That is not what I am trying to do.
If the One2Six can be attacked, the path will not start with casino folklore. It will start with a boring question: what process is this machine actually implementing? Once that process is understood, the next step is to build a model, compare it against sensible baselines, and measure whether the output differs from the kinds of randomness we already understand.
That is where the project now sits.
Part 1 asked whether a physical shuffling machine should really be treated as equivalent to a perfect shuffle. Part 2 attempted an initial reconstruction of the One2Six mechanism from public information. Part 3 is where the project moves from suspicion and mechanism-hunting into simulation design.
Before I can say anything meaningful about the shuffler, I need a blackjack engine that does not lie to me.
1. The research lesson so far
The deeper source work changed how I think about the One2Six.
The broad mechanism remains interesting. The machine is not a normal shoe. It is a physical device that accepts used cards, feeds them into an internal shuffling mechanism, stores them, and later delivers cards back into play. Public material supports the idea that the One2Six is a continuous shuffler for multi-deck blackjack, including four, five, and six-deck operation. The patent trail also supports the general idea of cards being fed into internal compartments and later delivered out of the mechanism.
That is enough to justify the project.
It is not enough to justify pretending every parameter is known.
That is the first serious lesson from the research phase. Patents are not production manuals. Marketing material is not a stochastic model. Forum posts are not engineering evidence. A patent embodiment may describe a real mechanism, a possible mechanism, or a related mechanism. It does not automatically prove the exact internal behaviour of the machine sitting on a casino table.
So the project now has to separate claims into four buckets:
| Category | Meaning |
|---|---|
| Confirmed | Supported directly by strong public sources. |
| Inferred | Not directly confirmed, but strongly suggested by mechanism and multiple sources. |
| Speculative | Plausible, but not yet supported well enough. |
| Unknown | Important parameter not yet pinned down. |
This matters because Part 2 was necessarily a working reconstruction. Part 3 needs to be stricter. The project is no longer “what do I think the machine does?” It is now “what do I know, what do I infer, what do I need to test, and which assumptions drive the result?”
That is a much better place to be.
2. The wrong first question
Most blackjack discussion around continuous shufflers collapses into the same question:
Can you count it?
That is not the right starting point.
A normal card count assumes a particular kind of shoe depletion. Cards are removed from the shoe, the composition changes, and the count attempts to track that changing composition. A continuous shuffler changes the problem. Used cards may be returned to the machine, mixed internally, delayed, buffered, and reintroduced according to the machine’s physical process.
So the better question is not “can you count it?”
The better question is:
What equation is this machine implementing?
An IID random card source is one process. A finite shuffled shoe is another process. A manual casino shoe with a cut card is another. A continuous shuffler with internal compartments, delayed discard return, group delivery, and an output buffer is another again.
Those are not interchangeable. They may produce similar enough blackjack outcomes that no useful edge exists, but that is a conclusion to be tested, not assumed.
The chain of reasoning has to be:
mechanism -> model -> simulation -> measurement -> exploitability test
Anything else is just a gambling story.
3. Why the baseline matters
It is tempting to jump straight into modelling the One2Six. That would be a mistake.
A shuffler simulation plugged into a sloppy blackjack engine would produce numbers, but the numbers would not mean much. Before modelling the machine, the project needs a clean baseline engine that can handle the game itself: cards, hands, boxes, wagers, blackjacks, doubles, splits, dealer rules, settlement, discard timing, and result aggregation.
That is the current stage of the codebase.
The key architectural decision is that card supply must be separated from game rules. The blackjack engine should not care whether the next card comes from an IID random generator, a finite shoe, a manual shoe, or a future One2Six-style simulator. It should simply ask the card source for the next card.
That separation is critical because the card source is the experiment.
The blackjack rules are the measuring instrument. The shuffler is the object under test.
4. Current simulation architecture
The project has now moved beyond a toy script. The baseline has been built around a modular structure:
| Layer | Purpose |
|---|---|
| Game engine | Runs Star Blackjack-style rules and hand flow. |
| Strategy layer | Provides player decisions. |
| Card source layer | Supplies cards from IID, finite-shoe, manual-shoe, and eventually One2Six-style sources. |
| Result layer | Tracks wagers, outcomes, streaks, blackjacks, doubles, splits, busts, and edge metrics. |
| Test layer | Keeps the pieces honest as the model becomes more complex. |
This is the correct shape for the project because the final question is comparative. I do not only want to know what happens under a One2Six-style model. I want to know how that differs from simpler sources of randomness.
The current baseline supports three card sources:
| Card source | What it represents | Why it matters |
|---|---|---|
| IID random source | Each draw is independent. | Simplest baseline. Useful for engine testing, but not a physical shoe. |
| Finite shuffled shoe | Cards are dealt from a finite shoe without replacement. | Introduces physical card depletion. |
| Manual-shoe benchmark | A casino-style shoe with penetration and reshuffle behaviour. | Gives a more realistic comparison point before introducing the CSM. |
This matters because “random” is not a single thing. A memoryless random draw, a finite shoe, and a continuous shuffler are different processes. If the outputs differ, we need to know which difference comes from which process.
5. Star Blackjack assumptions
The baseline is being built around the blackjack rules relevant to the game being studied, rather than a vague generic blackjack abstraction.
At this stage, the engine models Star Blackjack-style behaviour closely enough to support the next phase of analysis. The important features are not just hand totals and dealer drawing. The important features are the state transitions: when cards are dealt, when hands are resolved, when busted cards leave play, when discards are staged, and when those discards become eligible to return.
That timing matters enormously for a continuous shuffler.
In a normal shoe simulation, the discard pile can often be treated as dead until the next shuffle. In this project, that is not good enough. If the machine receives used cards continuously or near-continuously, discard timing becomes part of the stochastic process.
That means the simulation has to care about details that a normal blackjack sim might ignore:
| Detail | Why it matters |
|---|---|
| Physical card identity | The same physical card may leave play and later reappear. |
| Ordered discards | If the machine preserves local structure, discard order may matter. |
| Bust timing | Busted hands may be collected before the rest of the round finishes. |
| Box order | Multi-box collection order may affect the discard stream. |
| Dealer-card collection | Dealer cards may systematically enter after player hands. |
| Previous-round delay | Returned cards may not be immediately available. |
This is one of the biggest practical lessons so far. The interesting object is not just the final blackjack outcome. It is the card-flow process that generated it.
6. Why physical card identity matters
One of the most important design decisions is distinguishing between a card type and a physical card.
A card type is something like “King of hearts.”
A physical card is a specific King of hearts from a specific deck inside a multi-deck game.
For many blackjack simulations, that distinction is unnecessary. For this project, it is central.
The One2Six is not an abstract probability oracle. It is a machine moving physical cards. A card is dealt, exposed, collected, returned to the mechanism, stored internally, and eventually dealt again. If the simulation cannot track that physical object through the system, then it cannot measure return times, clustering, discard-neighbour effects, or any possible memory in the machine.
This is where the project stops being a normal blackjack simulator and starts becoming a shuffler model.
The future One2Six simulation needs to be able to answer questions like:
| Question | Why it matters |
|---|---|
| How many rounds pass before a specific physical card returns? | Measures return-time distribution. |
| Do recently adjacent discards reappear close together? | Tests whether local order survives. |
| Do certain ranks cluster more than expected? | Tests for rank-level structure. |
| Does output depend on discard timing? | Tests procedure sensitivity. |
| Does the buffer create predictable delay? | Tests whether returned cards are temporarily unavailable. |
Those are the questions that matter before any betting system is even considered.
7. Baseline results so far
The current baseline work has already produced useful results, but they should be interpreted correctly.
The most important result is not a bankroll number. The most important result is that the architecture now supports controlled comparison between card sources. The simulation can run Star Blackjack-style hands, track outcomes, separate initial wager from action wager, and record detailed result metrics.
An earlier baseline run over 10,000 rounds produced the following rough output:
| Metric | Result |
|---|---|
| Wins | 4,928 |
| Losses | 5,864 |
| Pushes | 3,336 |
| Blackjacks | 53 |
| Doubles | 1,671 |
| Splits | 4,075 |
| Final bankroll | -$1,750.50 |
I am not treating this as a final estimate of casino EV. That would be the wrong lesson.
The useful lesson is that blackjack accounting becomes non-trivial as soon as doubles and splits enter the game. A round is not the same as a resolved hand. Initial wager is not the same as total wager. Splits create multiple hands from one original box. Doubles change exposure. Pushes affect streak tracking. Busts affect card collection timing.
That early result exposed the accounting problem, which forced the result layer to become more serious.
The project now tracks:
| Result category | Examples |
|---|---|
| Wager accounting | Initial wagered, action wagered, total wagered. |
| Profitability | Net profit, average profit per round, player/house edge by initial and total wager. |
| Outcome counts | Wins, losses, pushes, blackjacks, busts. |
| Action counts | Doubles, splits. |
| Streaks | Maximum win streak and loss streak. |
| Shoe mechanics | Shuffle count for manual-shoe simulations. |
This is a good example of why baseline work matters. The first numbers were not the answer. They were a diagnostic.
They showed what the simulation needed to understand before the shuffler could be introduced.
8. What the baseline can and cannot tell us
The current baseline can tell us whether the game engine, card-source abstraction, and result accounting are working in a way that supports further investigation. It can compare IID, finite-shoe, and manual-shoe behaviour. It can test whether strategy and settlement logic behave sensibly under large simulation runs.
It cannot yet answer whether the One2Six is exploitable.
That is the next stage.
The current baseline cannot yet measure One2Six-specific effects because the One2Six-style card source has not yet been introduced. It also cannot claim anything about real-world exploitability until the simulated card sequence shows measurable structure, and until that structure is shown to be observable before a betting decision.
This is the correct limitation.
The project should be strict about what has and has not been shown. At this stage, the baseline shows that the table is being built properly. It does not yet show that the machine leaks useful information.
9. The One2Six model to build next
The first One2Six simulator should not pretend to be the final truth. It should be a configurable family of plausible mechanisms.
The reason is simple: public sources do not yet pin down every production parameter. Rather than guessing one set of numbers and building the whole project around it, the simulator should expose uncertain parameters and allow them to be swept.
The first One2Six-style card source should include:
| Parameter | Meaning |
|---|---|
| Deck count | Usually six for the blackjack scenario of interest. |
| Compartment count | Number of internal carousel/shelf compartments. |
| Compartment capacity | Maximum or target number of cards per compartment. |
| Insertion rule | How incoming cards are assigned to compartments. |
| Intra-compartment order | Whether local order is preserved, reversed, or mixed. |
| Output rule | How a compartment/group is selected for ejection. |
| Group size | Whether an entire compartment or partial group is output. |
| Output buffer size | Number of cards available for dealer draw. |
| Low-water trigger | When the machine refills the output buffer. |
| Discard return delay | When used cards become eligible to re-enter the machine. |
| Collection order | How player/dealer cards are returned to the discard stream. |
The aim is not to “guess the machine.” The aim is to test families of plausible machines and see whether the output distribution changes in a meaningful way.
That is why the current modular architecture matters. The One2Six should become just another card source from the blackjack engine’s perspective.
10. What will count as signal
The next phase should measure the card sequence directly before worrying about profit.
That is important.
A betting result is downstream of many things: strategy, rules, variance, bet sizing, and card sequence. If the card sequence itself does not show measurable structure, then betting systems are irrelevant.
The first measurements should include:
| Statistic | Purpose |
|---|---|
| Physical-card return time | Measures how long specific cards stay out of play. |
| Rank return time | Measures whether ranks reappear faster or slower than baseline. |
| Rank autocorrelation | Tests serial dependence in ranks. |
| Blackjack-value autocorrelation | Tests serial dependence in card values. |
| Neighbour reappearance | Tests whether adjacent discards reappear close together. |
| Clump-size distribution | Tests grouping effects. |
| Mutual information | Tests whether recent discards predict future output. |
| Initial two-card total distribution | Tests whether starting-hand distribution changes. |
| Blackjack frequency | Checks high-level game impact. |
| Dealer bust frequency | Checks downstream game impact. |
| Outcome distribution | Compares player/dealer results under fixed strategy. |
The key comparison should be against IID, finite-shoe, and manual-shoe baselines.
Only then does it make sense to ask whether anything observed is unique to the One2Six-style process.
11. What will count as an edge
Even if the simulated One2Six output differs from ideal randomness, that is not automatically an edge.
This is important enough to state clearly.
A measurable deviation is not enough. For a real edge, the structure must be:
| Requirement | Meaning |
|---|---|
| Observable | The player must be able to know something before betting. |
| Timely | The information must arrive before the relevant decision. |
| Large enough | The effect must overcome the house edge and practical noise. |
| Stable | It must survive plausible machine parameters and procedures. |
| Legal and practical | It cannot require impossible or illegal information. |
This is why I am not interested in claiming too much early. The machine may produce tiny measurable deviations that are mathematically interesting but practically useless. That would still be a valid result.
The question is not whether I can force an edge into existence.
The question is whether the equation underneath the machine leaves anything usable.
12. Where the project now stands
The project has moved from suspicion to infrastructure.
That is real progress.
The One2Six is no longer just “that shuffler might be weird.” It is becoming a layered modelling problem:
| Layer | Current status |
|---|---|
| Source research | Broad mechanism identified; exact parameters still being separated into confirmed, inferred, speculative, and unknown. |
| Blackjack engine | Baseline Star Blackjack engine built. |
| Card-source abstraction | IID, finite-shoe, and manual-shoe sources implemented. |
| Result accounting | Detailed wager, outcome, and streak metrics implemented. |
| Discard timing | Now treated as a first-class modelling issue. |
| One2Six source | Next major build. |
| Monte Carlo comparison | Next major analysis stage. |
That is the correct shape of the project.
The next step is to implement the first configurable One2Six-style card source, then run it against the existing baselines. The immediate goal is not to find a betting system. The immediate goal is to see whether the card sequence produced by a plausible random-in/group-out machine behaves differently from the baseline processes.
If it does not, the project moves toward a null result.
If it does, the next question is whether the signal is observable and large enough to matter.
Either way, the machine gets pulled apart properly.
That is the point.