#Magic Vault 5×3 — Exact Results, draft-v0.1

DEV ONLY · NOT FOR PRODUCTION · NOT FOR CERTIFICATION. Everything in this report is an exact enumeration. Sampled results live in ../simulation/draft-v0.1.md and are never mixed in here.

#Command

cd /Users/admin/kiro/backend
go test -count=1 -v ./libs/mathengine/games/magic_vault_5x3 -run Exact

#Method boundary — what "exact" covers here

mathengine.ExactCalculate refuses the whole config, returning NotEnumerableError{stochastic_feature}: hold_and_win is a stateful stochastic machine, not a grid-determined feature. That refusal is asserted, not worked around (TestPackIsNotEnumerable).

Exact results are therefore produced for the two genuinely enumerable parts:

No Monte Carlo figure appears in this document.

#1. Exact trigger probability

Each strip carries a contiguous three-entry COIN run at indices 0–2, so the visible COIN count on a reel is a function of the drawn stop:

Per-reel weight total 1720; all five reels are symmetric in weight.

The five per-reel count distributions are convolved in int64. The denominator is 1720⁵ = 15,036,246,323,200,000, comfortably inside int64, so there is no floating-point rounding in the derivation at all. Mass is verified twice: by exact integer equality against the denominator, and as a float within 1e-12.

Method validation. The identical routine reproduces hold_and_win_reference's documented 1 in 155.4035 exactly. That is the check that this models the engine's actual reel window rather than a plausible-looking alternative.

#2. Exact distribution of initially locked cells

E[initial locked | trigger] = 6.4652.

This table is the reason Magic Vault cannot inherit the reference harness's conditional mean. The mechanic is byte-identical; the entering distribution is not. The harness's own E[initial locked | trigger] is 6.7322, and the award scales with how many cells arrive already locked.

A 15-COIN base grid is reachable but at probability ~1e-6 of triggers, so the Grand is in practice reached by filling the grid during respins rather than on the trigger itself.

#3. Exact base-game results

Enumeration of the base-only copy (Features = nil).

The base maximum of 64× against a 500× round ceiling is the containment half of the max-win claim: the cap can only ever bind on a feature round, so the base and feature contributions stay additive and the RTP decomposition remains valid.

#4. Reconciliation

Total RTP = exact base RTP + exact P(trigger) × E[award | trigger]
          = 0.559961      + 0.0126493391      × 31.6252
          = 0.959998        (95.9998%)

The third term is estimated, not exact, and is the only sampled input to this line. Its provenance and uncertainty are in the simulation report.

#Required base RTP

required base RTP = 0.96 − 0.0126493391 × 31.6252 = 0.559962   (55.9962%)
achieved          =                                 0.559961   (55.9961%)
difference        =                                 0.0001pp

The design brief's 55.44% is not this number; it assumed the reference harness's conditional mean. See ../../changelog.md.

#5. Unresolved drift

None within this report. The exact terms agree with the recorded targets to better than 0.001 percentage points, and the trigger sits comfortably inside its band.

Carried forward: the whole game remains non-enumerable, so no exact whole-game RTP or exact whole-game max-win distribution exists or can be produced without changing the mechanic.