# Results-oriented poker evidence bundle

- Published: 2026-09-04
- Model version: 1.0.0
- Evidence type: synthetic logical demonstration
- Sampling: none; four constructed cases, no random seed or iterations
- Units: abstract cash-game chips, not currency

> This bundle does not contain observed users, observed poker hands, poker-player psychology data, solver output, or a strategy recommendation.

## Question

Can the same poker decision keep the same expected-value grade when one constructed instance wins and another loses?

The answer demonstrated here is yes. A result tells us what happened once. The decision audit asks what the action was worth from the information and model available before that result.

## Static river-call model

All four cells use a heads-up no-limit Hold’em cash-chip river call with closed action, no remaining rake or drop, no ties, no side pot, and no future action. The pot is 300 chips before Hero acts; that amount already includes the opponent’s river bet. Calling costs 100 more and makes a 400-chip final pot.

The decision-point equations are:

```text
required equity = 100 / (300 + 100) = 25%
call EV = equity × 400 − 100
fold EV = 0
```

The two constructed equity inputs bracket the threshold:

| Locked equity input | Call EV | Pre-reveal grade | If the call wins | If the call loses |
|---:|---:|---|---:|---:|
| 30% | +20 chips | positive-EV call | +300 chips | −100 chips |
| 15% | −40 chips | negative-EV call | +300 chips | −100 chips |

Within each row, the win and loss cases have identical decision-time inputs and identical pre-reveal audits. Only the case identity and realized-outcome fields differ. The outcome is never an input to the decision grade.

## Files

- `results-oriented-poker-cases.json`: assumptions, formulas, the four-cell matrix, pair invariants, and review-card schema.
- `results-oriented-review-card.csv`: one reusable template row followed by the four synthetic example rows.
- `results-oriented-poker-quick-review.csv`: one plain 12-field header plus one reusable template row; no example data.
- `results-oriented-poker-verifier.py`: independent Python standard-library verifier with separately pinned fixtures.
- `results-oriented-poker-README.md`: this public method and limitation note.

The website source also retains the JavaScript model and deterministic generator:

- `scripts/lib/results-oriented-poker-model.mjs`
- `scripts/generate-results-oriented-poker-data.mjs`
- `tests/results-oriented-poker-data.test.mjs`

## Reproduce

From the repository root, regenerate the JSON and CSV:

```console
node scripts/generate-results-oriented-poker-data.mjs
```

Then run the independent verifier and targeted tests:

```console
python public/data/results-oriented-poker-verifier.py
node --test tests/results-oriented-poker-data.test.mjs
```

The Python verifier does not import or execute the JavaScript model. It parses numbers independently, rejects non-finite values and duplicate JSON keys, pins the four declared fixtures, recomputes every EV and realized chip result, checks both within-pair invariants, validates both exact CSV headers, compares every technical example cell with the JSON, and pins the quick template. This comparison depends on trusting the published verifier source and its embedded pins; it is not a cryptographic provenance check.

## Choose the quick or technical card

Start with `results-oriented-poker-quick-review.csv` for a single decision. Its 12 chronological fields are:

1. `id`
2. `locked_state_and_options`
3. `locked_belief_or_range`
4. `action_and_reason`
5. `confidence`
6. `reference_and_mismatch`
7. `locked_model_based_action_grade`
8. `raw_result`
9. `post_reveal_snap_grade_or_change`
10. `genuinely_new_evidence`
11. `future_model_update`
12. `next_comparable_sample`

The intended workflow is to complete fields 1–7 before revealing the result, then complete fields 8–12 without rewriting the locked record. This chronology is self-reported. Column order makes the separation inspectable, but a static CSV cannot enforce when someone filled or edited a field. The quick card is an audit trail, not a validated test of outcome bias, psychology, or decision skill. Its prompts have not been validated as a diagnostic scale or behavioral intervention.

Use the 40-column `results-oriented-review-card.csv` when the pot, price, reference values, and update plan need separate machine-readable cells or when reproducing the four published examples.

## Use the review card in two passes

Copy the first CSV row before use. Do not overwrite it. Its chronology and provenance cells are instructions, not prefilled claims: enter `TRUE` only if the locked fields were completed before the result was seen, and label a row synthetic only when it really is constructed.

### Pass 1: result hidden

1. Fill the `lock_` fields from information available at the decision. Record the actual action, pot, price, estimate, assumptions, rake, ties, future action, and contemporaneous reasoning.
2. While the result is still hidden, fill the `audit_` fields from a named calculation, solver, database, coach review, or an explicit “none.” Record its date/version and scope. An unavailable or inapplicable reference should be marked unresolved rather than invented.

### Pass 2: result revealed

3. Fill the `reveal_` fields. Keep realized chips separate from the locked grade; do not backfill a better read because the hand won or a worse read because it lost.
4. Use the `update_` fields to name what future belief might change, the evidence unit needed, the comparison scope, confidence, and next test. One isolated win or loss may motivate a question, but it does not validate an equity assumption by itself.

The four technical example rows are completely synthetic and show field mechanics only; those rows truthfully contain `TRUE` and the synthetic disclosure because their dataflow is generated in that order. The technical template and quick file contain instructional rows, not chronology assertions. Neither file is evidence that players use this workflow, that the workflow changes behavior, or that either kind of decision occurs at any real-world rate.

## Boundaries

Passing the generator, tests, and verifier shows that the checked files are consistent with the declared fixtures embedded in the checked verifier version. The verifier source and pins must themselves be trusted; a pass does not establish cryptographic provenance or prove that the files came from a particular author, repository state, or build. It also cannot prove that a human completed the locked fields before seeing a result; chronology remains self-reported. It does not establish solver optimality, real opponent ranges, poker-player psychology, protocol efficacy, causation, long-run frequency, gambling profit, or the quality of a live decision. Real review work must specify the game, stakes or units, positions, effective stacks, action line, sizing, rake, ranges or reference model, future actions, and any tournament payout conversion that can affect the decision.