poker.yoga

How we verify our answers

Every answer here is settled by the cheapest tool that can settle it: tested arithmetic, a published preflop chart, an ICM engine, or a CFR solver. This is the whole pipeline, including what we don't claim.

The verification pyramid

  1. 1Arithmetic: checked by tests

    Outs, equity, pot odds and the rule of 2 and 4 come from code that runs on every commit. If a number in a lesson disagrees with the code, the build fails before it reaches you.

  2. 2Preflop: checked against a published chart

    Opening and defending ranges come from one declared chart for 100bb 6-max. Lesson text is checked against that chart rather than against opinion, so “open this hand” means the same thing everywhere on the site.

  3. 3Tournament spots: an ICM engine

    Push/fold, bubble and final-table spots run through an ICM calculator, with calling ranges that are themselves ICM-adjusted, not chip-EV shortcuts borrowed from cash games.

  4. 4Contested postflop spots: a CFR solver

    When two strong players could argue either way, when the lesson is about bet sizing, or when the text quotes a frequency or an EV edge, the spot is solved with a CFR solver (TexasSolver) before it ships. No run, no number.

Reproduce it

The first three levels above are published as code you can run. Every pot-odds, equity and ICM figure on this site is computed by that repository, from committed data with a recorded seed. Clone it and run the tests — if a number here is wrong, that is where it shows.

git clone https://github.com/poker-yoga/poker-math
cd poker-math && npm install
npm test

Expected output

 Test Files  9 passed (9)
      Tests  105 passed (105)

The equity tables regenerate deterministically. Running npm run gen:vs-random rewrites the starting-hands table from the committed matrix — one million boards per hand pair, seed 1 — and produces a byte-identical file every time. Published figures agree with it to within 0.1 percentage points, which is Monte-Carlo noise. A larger gap is a bug on our side, and we would rather have the issue than the benefit of the doubt.

What this does not cover is the CFR solver on level four. Its binary is third-party software we download rather than redistribute, and its runs happen offline on one machine. What we publish instead is the configuration and result of each run, next to the spot it settled — the worked example below.

The solver, in detail

Level four uses TexasSolver, an open-source CFR solver published under the AGPL. We run version 0.2.0 locally, in overnight batches, downloaded from the project's own release page. That licence is why we can show you its output and call a spot solver-verified, and why the binary itself is not in our repository: publishing results is fine, redistributing the program is not.

TexasSolver

What every run has to record

  • Both players' ranges, taken from the declared 100bb 6-max chart rather than invented for the run.
  • The full bet-size menu the lesson offers, so that a size the text recommends is a size the solver was able to choose.
  • Pot, effective stack and board exactly as the spot states them.
  • The opponent model, written down. Too tight a defence range is the fastest route to a confident wrong answer, and it is how we shipped two answers we later had to overturn.
  • The accuracy target, measured as exploitability — and we never quote a frequency more precisely than that accuracy supports.

One run, start to finish

The gutshot lesson in Outs & equity. You are in the big blind with T♥9♥, the flop is K♠Q♦6♣, stakes are $1/$2 and stacks 100bb. You check, the button bets the pot. These are the inputs the solver was given:

Configuration

set_pot 20
set_effective_stack 190
set_board Ks,Qd,6c
set_range_ip  AA,KK,QQ,JJ,TT,…,KJo,KTo,QJo,QTo,JTo
set_range_oop AA,KK,QQ,JJ,TT,…,KQo,KJo,QJo
set_bet_sizes ip,flop,bet,100
set_thread_num 8
set_accuracy 0.4
set_max_iteration 250

Strategy at the decision node

FOLD            0.986
RAISE 2.8x      0.014
CALL            0.000

Run on 11 July 2026: fifteen minutes on eight threads, stopped at 0.38% exploitability after 191 iterations. The lesson teaches the fold, and the solver folds it 99% of the time. The spot carries this run's id in the content source, which is how a later re-solve knows what to compare against.

What makes a run trustworthy

  • The ranges in the simulation match the published chart, for both players. A sim with invented ranges verifies nothing.
  • The bet-size menu includes every size the lesson offers. You cannot validate “a third of the pot” in a simulation that has no third-pot option.
  • The opponent model is written down. A defence range that is too tight is the fastest route to a confident wrong answer: it is exactly how we shipped two answers we later had to overturn.
  • The accuracy target is recorded, and we never quote a frequency more precisely than that accuracy supports.
  • Every solved spot keeps its record: the run, its date, and the output that decided the answer. No record means the spot may not call itself verified.

The solver decides what, a human writes why

A simulation can veto an action, a size or a number. It cannot explain anything. Every “why” on this site is written by a human and reviewed against the run, because the most common failure in poker content is the right answer with the wrong reason. Where the solver genuinely mixes two actions, we say so instead of presenting one of them as gospel.

What we don't claim

  • The preflop chart is a deliberate simplification for 100bb 6-max: a compass, not gospel. It is not solver-derived.
  • Not every spot needs a solver. Most are settled by arithmetic or by the chart, and we don't dress those up as simulations.
  • When a chart or an opponent model changes, older runs go stale. Those spots are queued for a re-solve and carry no solver claim until it happens.
  • We don't sell solver output as a product. Where a solver genuinely mixes two actions, the lesson says so rather than picking one and calling it the answer.
  • We don't call a postflop tournament spot ICM-verified. The engine settles push/fold, bubble and final-table decisions; postflop play under ICM pressure is past what it models, so it is past what we claim.
  • We don't make claims about how “most players” or “the population” play. That needs a hand database, and we don't have one.
  • This is training material, not gambling advice, and no verification method predicts your results at a real table.

When we get it wrong

Verification only means anything if it sometimes overturns us. Every answer we have changed after publishing it is logged with its date, what it used to say, and what changed our mind.

Drift is caught by the build

Content and code ship together. The test suite asserts that every practice scenario still matches the spot it teaches (the board, the hero's hand and the answer itself), so text quietly drifting away from a verified answer fails the build instead of reaching you.

Who runs this

poker.yoga is an independent engineering project — not a personal brand, not a poker school, and not a front for a room. We publish no author biography, because a name is not evidence. What stands behind an answer here is the code that produced it, the tests that guard it and the log of the times we got it wrong.

Questions, corrections, or a number that looks off: support@poker.yoga

What we don't sell

As things stand today, this site has no affiliate deals with poker rooms or casinos, carries no ads, and sends you nowhere to play. Everything here is free, the cheat sheet and the calculators included. That is a description of how the project works right now, not a promise about every future version of it.

Common questions

Is every answer on poker.yoga solver-verified?

No, and that is deliberate. A solver is the most expensive tool we have, so it is reserved for spots where it can change the answer: contested postflop decisions, sizing lessons and any quoted number. Fundamentals and arithmetic are settled more cheaply and more reliably by tests.

Which solver do you use?

TexasSolver, a CFR solver, run locally in batches. ICM and push/fold spots use a separate ICM engine: a CFR solver cannot model preflop or ICM, and using it there would produce confident nonsense.

What happens when the solver disagrees with a published lesson?

The lesson changes. In July 2026 a re-solve against a wider, more realistic defence range overturned two answers that were already live (one bet-sizing spot and one c-bet spot), and both were rewritten. The same review also refuted three of the five objections raised against us.

Where this shows up

Last reviewed:
2026-08-08
Methodology version:
v2

What changed here

  • 2026-08-08v2 — added the reproduction steps, the solver's version and licence, a worked run end to end, the corrections log, and this changelog.
  • 2026-07-31v1 — first published: the verification pyramid, the rules a run has to follow, and the limits.