Every published decision starts with a state you can inspect.
Each published OOB proof state records the exact game rules, remaining-shoe
composition, player hand, dealer upcard, available actions and action EVs needed to
independently inspect the result.
State IDs, engine versions and methodology versions preserve the technical context
behind every published calculation.
Exact Inputs
Rules · Shoe · Player · Dealer
Action EVs
Every available action
Versioned
Engine + methodology
Traceable
State ID + validation status
State anatomy
Everything needed to reconstruct the decision is recorded with the state.
A reproducible state separates the game inputs, exact shoe composition, available
actions, calculated outputs and version information needed for a deterministic rerun.
Rule configuration
The Exact Game
Deck count, S17/H17, Peek or ENHC, doubling, splitting, surrender and blackjack payout rules define the game being evaluated.
Hand state
Player and Dealer Context
The player hand, dealer upcard and current decision context define which actions are available at that exact moment.
Remaining composition
Every Rank Still Available
The remaining count of A, 2, 3, 4, 5, 6, 7, 8, 9 and 10/J/Q/K is recorded so the same depleted shoe can be reconstructed.
A · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10/J/Q/K
Calculation result
Action EVs and Decision
The EV of every available action and the resulting highest-EV decision are preserved with the published state.
The technical record travels with the state.
Each published state is linked to a unique State ID, engine version, methodology
version and validation status so later reruns or corrections can be traced to the
exact calculation that was published.
If any required input differs, it is no longer the same reproducible state.
Published state format
Every state follows the same technical record.
A standard format makes published decisions easier to inspect, reproduce and compare
across OOB versions and independent validation methods.
Identification
State ID
Unique permanent identifier
Engine Version
Version used for the calculation
Methodology Version
Methodology applied to the published result
Validation Status
Current validation state of the record
Game inputs
Rule Configuration
Exact rules used for the calculation
Player Hand
Player cards and decision context
Dealer Upcard
Visible dealer card
Available Actions
Actions permitted in that exact state
Exact shoe
Remaining Composition
A2345678910/J/Q/K
The published record stores the remaining count for every rank.
Calculation output
Stand EV
Hit EV
Double EV
Split EV
Surrender EV
Highest-EV Action
Selected from the actions available in the state using unrounded internal EV values.
Unavailable is different from uncalculated.
If an action is not permitted by the current hand or rule configuration, the
public record marks it as unavailable rather than assigning it an EV.
The same format is used whether OOB agrees with Basic Strategy, identifies a
composition-dependent deviation or publishes a borderline decision.
State selection
The library is built to document diverse states, not only impressive ones.
OOB states are organized by what they demonstrate and selected under rules designed
to reduce cherry-picking and improve reproducibility.
Baseline states
Agreement with Basic Strategy
Some published states show cases where OOB and static Basic Strategy produce the same action under the same game rules.
Composition states
Composition-Dependent Differences
Some states show cases where the exact remaining shoe changes action EVs enough to produce a different highest-EV decision.
Borderline states
Small EV Gaps
Some states are published because the top available actions are close in EV, helping show the difference between mathematical preference and practical magnitude.
Rule states
Rule-Sensitive Decisions
Some states are selected because rule changes such as ENHC vs Peek, S17 vs H17, surrender or split restrictions materially affect the evaluation.
Selection rules matter as much as the states themselves.
The published library is not limited to “best-looking” outcomes. States may be
included because they confirm agreement, reveal composition-dependent
differences, illustrate borderline decisions or demonstrate rule sensitivity.
Include agreements
States are not published only when OOB differs from Basic Strategy.
Include differences
Composition-dependent deviations are included when they are clearly defined and reproducible.
Include borderline cases
Small EV gaps are part of the record, not filtered out.
Include rule-sensitive cases
States that change under different supported rule configurations are part of the library.
State publication is organized by explanatory value, not by how dramatic the result
looks.
State validation status
Every published state carries its current validation status.
A state advances only when the checks required for that stage have been completed and
documented. Status reflects evidence, not confidence or marketing preference.
In build
State Record Being Prepared
The state has been selected and its technical record is being assembled, but it is not yet ready for public verification.
Internally validated
Internal Checks Passed
The state, rule configuration, action availability, EV outputs and deterministic rerun have passed the defined internal validation checks.
Cross-validated
Independently Compared
The published calculation has been compared with an independent method, tool or reviewer under equivalent state and rule conditions.
Public verified
Evidence Available for Inspection
The state record, methodology context and applicable validation evidence are publicly available so the result can be independently inspected.
Corrected / Revised
A Published Record Was Updated
A later review identified a change requiring correction or clarification. The original record, affected version and updated result remain linked in the validation history.
Status is attached to the state — not to OOB as a whole.
A PUBLIC VERIFIED state means that the evidence for that specific published state
is available for inspection. It does not mean every OOB calculation, rule
configuration or future result has been independently verified.
In build→Internally validated→Cross-validated→Public verified
Corrected / Revisedmay be applied if a published record changes after review.
Validation status changes remain versioned so the history of the published state is
preserved.
How to reproduce a state
Use the published inputs. Calculate independently. Compare only after the result is fixed.
A reproduction uses the exact published state and rule configuration without changing
assumptions or relying on the OOB output as the starting point.
1
Reconstruct
Recreate the Exact State
Use the published rule configuration, player hand, dealer upcard, available actions and remaining count of every card rank.
2
Calculate
Calculate the Action EVs Independently
Use an independent method or compatible external tool to calculate the EV of each available action under the same state and EV convention.
3
Compare
Compare the Results
Compare the independently calculated action EVs and highest-EV decision with the published OOB record using the defined numerical tolerance.
For stronger validation, calculate before seeing the OOB answer.
Blind reproduction reduces anchoring: the reviewer receives the inputs first,
submits the independent calculation, and only then compares it with the OOB
output.
Same inputs required
Rules, exact shoe and decision state must match.
Same EV convention required
Values must use the same wager normalization and action definitions.
Unavailable actions stay unavailable
An action prohibited by the state is not assigned an EV.
Differences are investigated
A mismatch is a finding to examine, not automatic proof that either implementation is wrong.
A reproduction is strongest when the independent result is recorded before the OOB
output is revealed.
State library
Explore the first ten reproducible states.
Each entry links to the complete technical record: exact inputs, action EVs,
highest-EV decision, versions and current validation status.
10 published states · Internal validation completed
Internally validated
All ten states have passed the internal checks: inputs and shoe composition,
available actions, repeatability across two separate runs on the same engine,
agreement with the published values to four decimal places, and selection of the
highest-EV action from the unrounded values.
Independent validation: Not yet performed.
Category
Validation Status
INTERNALLY VALIDATED
OOB-RS-0001BASELINENORMAL
Hand10 + 9 = 19
Dealer6
High-Low0.00
Highest-EVSTAND
Margin—
Internally validatedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
10 + 9 = 19
Dealer Upcard
6
Other Cards
None
Cards Dealt
3
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
32
3
32
4
32
5
32
6
31
7
32
8
32
9
31
10/J/Q/K
127
Total remaining: 413
Calculation output
Stand
+0.4946
Hit
-0.7199
Double
-1.4399
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
STAND
Per original bet, including any additional wager.
Technical metadata
State ID
OOB-RS-0001
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
No other cards are removed in this state — skip this step.
Enter the two player cards: 10 + 9.
Enter the dealer upcard: 6.
Stop before playing the hand.
Check that Cards Dealt reads 3 and that the
exact remaining shoe matches the composition above
(413 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0002BASELINENORMAL
Hand5 + 6 = 11
Dealer6
High-Low+0.38
Highest-EVDOUBLE
Margin—
Internally validatedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
5 + 6 = 11
Dealer Upcard
6
Other Cards
None
Cards Dealt
3
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
32
3
32
4
32
5
31
6
30
7
32
8
32
9
32
10/J/Q/K
128
Total remaining: 413
Calculation output
Stand
-0.1515
Hit
+0.3393
Double
+0.6786
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
DOUBLE
Per original bet, including any additional wager.
Technical metadata
State ID
OOB-RS-0002
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
No other cards are removed in this state — skip this step.
Enter the two player cards: 5 + 6.
Enter the dealer upcard: 6.
Stop before playing the hand.
Check that Cards Dealt reads 3 and that the
exact remaining shoe matches the composition above
(413 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0003BORDERLINE
Hand10 + 6 = 16
Dealer10
High-Low0.00
Highest-EVHIT
Margin0.0027 over Stand
Internally validatedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
10 + 6 = 16
Dealer Upcard
10
Other Cards
5
Cards Dealt
4
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
32
3
32
4
32
5
31
6
31
7
32
8
32
9
32
10/J/Q/K
126
Total remaining: 412
Calculation output
Stand
-0.5770
Hit
-0.5743
Double
-1.1486
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
HIT
Margin over next action
0.0027 over Stand
Static Basic Strategy
HIT
Basic Strategy Agreement
Yes
Per original bet, including any additional wager.
Margins are calculated from the displayed, rounded action EVs.
Technical metadata
State ID
OOB-RS-0003
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
Enter the other cards in the published order: 5.
Enter the two player cards: 10 + 6.
Enter the dealer upcard: 10.
Stop before playing the hand.
Check that Cards Dealt reads 4 and that the
exact remaining shoe matches the composition above
(412 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0004COMPOSITIONBS-DEVIATIONREMOVED-CARD
Hand10 + 6 = 16
Dealer10
High-Low+0.13
Highest-EVSTAND
Margin0.0003 over Hit
Internally validatedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
10 + 6 = 16
Dealer Upcard
10
Other Cards
5, 5
Cards Dealt
5
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
32
3
32
4
32
5
30
6
31
7
32
8
32
9
32
10/J/Q/K
126
Total remaining: 411
Calculation output
Stand
-0.5776
Hit
-0.5779
Double
-1.1557
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
STAND
Margin over next action
0.0003 over Hit
Static Basic Strategy
HIT
OOB deviation
HIT → STAND
Secondary characteristic
Borderline
Per original bet, including any additional wager.
Margins are calculated from the displayed, rounded action EVs.
Technical metadata
State ID
OOB-RS-0004
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
Enter the other cards in the published order: 5, 5.
Enter the two player cards: 10 + 6.
Enter the dealer upcard: 10.
Stop before playing the hand.
Check that Cards Dealt reads 5 and that the
exact remaining shoe matches the composition above
(411 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0005COMPOSITIONBS-DEVIATIONREMOVED-CARD
Hand10 + 2 = 12
Dealer4
High-Low-0.38
Highest-EVHIT
Margin0.0116 over Stand
Internally validatedRevisedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
10 + 2 = 12
Dealer Upcard
4
Other Cards
10, 10, 10, 10
Cards Dealt
7
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
31
3
32
4
31
5
32
6
32
7
32
8
32
9
32
10/J/Q/K
123
Total remaining: 409
Calculation output
Stand
-0.2205
Hit
-0.2089
Double
-0.4178
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
HIT
Margin over next action
0.0116 over Stand
Static Basic Strategy
STAND
OOB deviation
STAND → HIT
Per original bet, including any additional wager.
Margins are calculated from the displayed, rounded action EVs.
Technical metadata
State ID
OOB-RS-0005
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Revision note — 2026-09-06
Value
Initial capture
Current
Double EV
-0.4189
-0.4178
Under ENHC, the dealer blackjack probability used a denominator of n − 1, although the upcard had already been removed from the shoe when it was built. The dealer hole card has no known value, so it is one of the n remaining cards. The correction aligns ENHC with the denominator convention already used for the US Peek path.
The Double EV for this state also changed, but the dealer upcard is 4, where the blackjack probability is zero and the ENHC correction has no effect. The cause of the earlier value has not been established. It is not attributed to the ENHC correction.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
Enter the other cards in the published order: 10, 10, 10, 10.
Enter the two player cards: 10 + 2.
Enter the dealer upcard: 4.
Stop before playing the hand.
Check that Cards Dealt reads 7 and that the
exact remaining shoe matches the composition above
(409 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0006BORDERLINE
Hand10 + 2 = 12
Dealer4
High-Low+0.13
Highest-EVSTAND
Margin0.0011 over Hit
Internally validatedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
10 + 2 = 12
Dealer Upcard
4
Other Cards
None
Cards Dealt
3
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
31
3
32
4
31
5
32
6
32
7
32
8
32
9
32
10/J/Q/K
127
Total remaining: 413
Calculation output
Stand
-0.2111
Hit
-0.2122
Double
-0.4243
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
STAND
Margin over next action
0.0011 over Hit
Per original bet, including any additional wager.
Margins are calculated from the displayed, rounded action EVs.
Technical metadata
State ID
OOB-RS-0006
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
No other cards are removed in this state — skip this step.
Enter the two player cards: 10 + 2.
Enter the dealer upcard: 4.
Stop before playing the hand.
Check that Cards Dealt reads 3 and that the
exact remaining shoe matches the composition above
(413 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0007RULE STATESPLIT
Hand8 + 8 = 16
Dealer6
High-Low+0.13
Highest-EVSPLIT
Margin—
Internally validatedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
8 + 8 = 16
Dealer Upcard
6
Other Cards
None
Cards Dealt
3
Available Actions
Stand · Hit · Double · Split
Exact remaining shoe
A
32
2
32
3
32
4
32
5
32
6
31
7
32
8
30
9
32
10/J/Q/K
128
Total remaining: 413
Calculation output
Stand
-0.1565
Hit
-0.4258
Double
-0.8515
Split
+0.2318
Surrender
Unavailable
Highest-EV Action
SPLIT
Per original bet, including any additional wager.
The application opens the two split-hand panels automatically for a pair. This record is the initial decision: the Action EV panel remains on the main hand (8 + 8), and Split appears as an available action with its own EV. The split was not executed.
Technical metadata
State ID
OOB-RS-0007
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
No other cards are removed in this state — skip this step.
Enter the two player cards: 8 + 8.
Enter the dealer upcard: 6.
Stop before playing the hand.
Check that Cards Dealt reads 3 and that the
exact remaining shoe matches the composition above
(413 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0008RULE STATESURRENDERENHC
Hand10 + 6 = 16
Dealer10
High-Low-0.13
Highest-EVSURRENDER
Margin0.0320 over Hit
Internally validatedRevisedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Late Surrender · Blackjack 3:2
Player Hand
10 + 6 = 16
Dealer Upcard
10
Other Cards
None
Cards Dealt
3
Available Actions
Stand · Hit · Double · Surrender
Rule Difference
Late Surrender
Exact remaining shoe
A
32
2
32
3
32
4
32
5
32
6
31
7
32
8
32
9
32
10/J/Q/K
126
Total remaining: 413
Calculation output
Stand
-0.5764
Hit
-0.5707
Double
-1.1414
Split
Unavailable
Surrender
-0.5387
Highest-EV Action
SURRENDER
Margin over next action
0.0320 over Hit
Per original bet, including any additional wager.
Margins are calculated from the displayed, rounded action EVs.
Technical metadata
State ID
OOB-RS-0008
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Revision note — 2026-09-06
Value
Initial capture
Current
Double EV
-1.1415
-1.1414
Surrender EV
-0.5388
-0.5387
Under ENHC, the dealer blackjack probability used a denominator of n − 1, although the upcard had already been removed from the shoe when it was built. The dealer hole card has no known value, so it is one of the n remaining cards. The correction aligns ENHC with the denominator convention already used for the US Peek path.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Late Surrender · Blackjack 3:2.
Start a new 8-deck shoe.
No other cards are removed in this state — skip this step.
Enter the two player cards: 10 + 6.
Enter the dealer upcard: 10.
Stop before playing the hand.
Check that Cards Dealt reads 3 and that the
exact remaining shoe matches the composition above
(413 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0009COMPOSITIONSAME-TCPAIR-A
Hand10 + 6 = 16
Dealer10
High-Low+0.38
Highest-EVSTAND
Margin0.0033 over Hit
Internally validatedRevisedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
10 + 6 = 16
Dealer Upcard
10
Other Cards
3, 4, 5, 5
Cards Dealt
7
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
32
3
31
4
31
5
30
6
31
7
32
8
32
9
32
10/J/Q/K
126
Total remaining: 409
Calculation output
Stand
-0.5791
Hit
-0.5824
Double
-1.1647
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
STAND
Margin over next action
0.0033 over Hit
Per original bet, including any additional wager.
Margins are calculated from the displayed, rounded action EVs.
Technical metadata
State ID
OOB-RS-0009
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Revision note — 2026-09-06
Value
Initial capture
Current
Double EV
-1.1648
-1.1647
Under ENHC, the dealer blackjack probability used a denominator of n − 1, although the upcard had already been removed from the shoe when it was built. The dealer hole card has no known value, so it is one of the n remaining cards. The correction aligns ENHC with the denominator convention already used for the US Peek path.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
Enter the other cards in the published order: 3, 4, 5, 5.
Enter the two player cards: 10 + 6.
Enter the dealer upcard: 10.
Stop before playing the hand.
Check that Cards Dealt reads 7 and that the
exact remaining shoe matches the composition above
(409 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
OOB-RS-0010COMPOSITIONSAME-TCPAIR-B
Hand10 + 6 = 16
Dealer10
High-Low+0.38
Highest-EVHIT
Margin0.0084 over Stand
Internally validatedRevisedView record
Game inputs
Rule Configuration
8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2
Player Hand
10 + 6 = 16
Dealer Upcard
10
Other Cards
2, 3, 6, 6
Cards Dealt
7
Available Actions
Stand · Hit · Double
Exact remaining shoe
A
32
2
31
3
31
4
32
5
32
6
29
7
32
8
32
9
32
10/J/Q/K
126
Total remaining: 409
Calculation output
Stand
-0.5804
Hit
-0.5720
Double
-1.1440
Split
Unavailable
Surrender
Unavailable
Highest-EV Action
HIT
Margin over next action
0.0084 over Stand
Per original bet, including any additional wager.
Margins are calculated from the displayed, rounded action EVs.
Technical metadata
State ID
OOB-RS-0010
Engine Version
OOB-ENG-b0681ede84a3
Methodology Version
Methodology v1.0
Validation Status
INTERNALLY VALIDATED
Verified on
2026-09-06
Independent validation
Not yet performed
Composition source
Starting shoe minus published dealt-card history
Verified runtimeOOB-RT-a209a03d7b2d · Python 3.14.4 · Production
PreviousOOB-RT-d6eb746d45d4 · Python 3.11.4 · Development · 2026-09-06
The build identifier is a fingerprint of the
engine source files. It is the same on any machine running the
same code. The runtime identifier fingerprints
the code objects held in memory, which is what actually executes
— but it depends on the Python version, since the same
source compiled by different versions produces different
bytecode. Reproducing the runtime identifier requires the same
Python version; reproducing the build identifier requires only
the same files.
Revision note — 2026-09-06
Value
Initial capture
Current
Double EV
-1.1441
-1.1440
Under ENHC, the dealer blackjack probability used a denominator of n − 1, although the upcard had already been removed from the shoe when it was built. The dealer hole card has no known value, so it is one of the n remaining cards. The correction aligns ENHC with the denominator convention already used for the US Peek path.
Recreate the state manually in OOB, or in any independent tool
that supports the same rules. These steps do not import the
state into the application.
Set the full rule configuration: 8 decks · ENHC · S17 · DAS No · Double any first two cards · Split to a maximum of 2 hands (one split, no resplitting) · Resplit aces No · Hit split aces No · Surrender None · Blackjack 3:2.
Start a new 8-deck shoe.
Enter the other cards in the published order: 2, 3, 6, 6.
Enter the two player cards: 10 + 6.
Enter the dealer upcard: 10.
Stop before playing the hand.
Check that Cards Dealt reads 7 and that the
exact remaining shoe matches the composition above
(409 cards remaining).
Then calculate the EV of each available action independently,
using the same EV convention, and compare with the published
values only after your own result is recorded.
Publication does not depend on whether OOB differs from Basic Strategy.
Agreement states, composition-dependent differences, borderline decisions and
rule-sensitive cases can all enter the library under the same record and
validation standards.
Internal validation confirms that the published values are reproducible on the
identified build. It is not independent verification: no third party has reproduced
these calculations.
Composition vs count
Same True Count. Different Shoe. Different Decision.
Two published states share the same rule configuration, the same hand, the same
number of cards dealt and the same Hi-Lo reading — but not the same exact
remaining composition.
Identical between the two states
Rules8 decks · ENHC · S17 · DAS No
Hand16 vs 10
Cards dealt7
Cards remaining409
Running Count+3
True Count+0.38
True Count = +3 ÷ (409 / 52) ≈ +0.38
Remaining decks = remaining cards / 52. True Count is shown rounded to two
decimal places.
OOB-RS-0009STAND
Other cards removed
3, 4, 5, 5
Exact remaining shoe
A
32
2
32
3
31
4
31
5
30
6
31
7
32
8
32
9
32
10/J/Q/K
126
Action EV
Stand-0.5791
Hit-0.5824
Double-1.1647
Margin: 0.0033 over Hit
Margins are calculated from the displayed, rounded action EVs.
OOB-RS-0010HIT
Other cards removed
2, 3, 6, 6
Exact remaining shoe
A
32
2
31
3
31
4
32
5
32
6
29
7
32
8
32
9
32
10/J/Q/K
126
Action EV
Stand-0.5804
Hit-0.5720
Double-1.1440
Margin: 0.0084 over Stand
Margins are calculated from the displayed, rounded action EVs.
The count is the same. The shoe is not.
Hi-Lo compresses card removal into a single number, so several different exact
compositions can map to the same True Count. Those compositions still contain
different cards, which produces different action EVs and — in this pair
— a different highest-EV action.
This does not mean True Count is not useful. It means a count summarizes the shoe,
while the exact composition determines the outcome probabilities used in the
calculation.
The state is the evidence. The methodology tells you how to test it.
Use the published state record together with the OOB methodology and validation
framework to inspect exactly what was calculated and how the result was evaluated.
Methodology
Understand the Calculation
Review the exact-state model, probability framework, action EV logic and rule handling used by OOB.
A published state demonstrates what was calculated for that specific state. It does
not guarantee future gambling outcomes or validate every OOB calculation.