#Slot Math Specification — Hold & Win Reference

This Math Spec owns whole-game totals and links to the mechanic-owned math. Canonical executable parameters live in the Go backend; this document records their identity and never maintains a second copy. A generated PAR sheet is evidence, not a replacement for the rules, targets, tuning history and approval gates recorded here.

#1. Identity and provenance

#Change log

#2. Math status

#3. Bet and payout units

round multiplier  = min(baseWin + featureWin, 500)
monetary win      = ApplyMultiplier(totalBetMinor, round multiplier)

#4. Target math profile

Base RTP and trigger frequency are now EXACT, from the design probe's enumeration of all 8000 reachable base grids. Everything else stays pending until the seeded simulation at plan Task 10.

Two rows are outside their draft band. That is recorded drift, not a defect to be quietly corrected: the parameters responsible are open for tuning only after DRAFT MATH approval.

The total/base split was set by the user on 2026-08-09; the design spec fixed only the ≈20% mechanic contribution.

#5. RTP decomposition

The decomposition must reconcile to total RTP within the simulation's reported confidence interval. BaseGameWin and FeatureWins["hold_and_win"] are separate fields on the engine's round outcome, so the split is measured rather than apportioned.

#6. Mathematical model

#Reel model consequence

Because one draw per reel selects a contiguous wrapping window, rows on a reel are correlated and only len(strip) distinct columns are reachable per reel. Reaching 6 or more BONUS across 15 cells therefore requires contiguous BONUS runs inside the strips. This makes trigger frequency a discrete function of run length and stop weight rather than a continuous parameter, and it is the reason the ≈1/150 target is treated as a tuning objective rather than a value that can simply be set.

#State-space size

N = Π_r L_r          (L_r = entry count of reel r)

Note that the base grid state space does not bound the round: the feature draws per empty cell, so the full round is not enumerable regardless of N.

N = 20 × 20 × 20 = 8000 reachable base grids. BONUS occupies entry indices 0-4 on every reel, contiguous, so visible BONUS count is a function of distance from that run.

#7. Symbols and paytable

Payouts are multipliers of TOTAL bet, awarded per winning payline. Only 3-of-a-kind pays; the grid is 3 reels wide, so 3 is also the maximum count.

#Scatter payouts

None. BONUS is deliberately not a scatter: the mechanic counts it directly, and a scatter pay would add an unattributed base contribution to exactly the rounds that trigger the feature.

#Paylines

Five straight rows. Positions[i] is the row index on reel i.

The paytable and the reel strips are the pack's own design inputs, not part of the approved mechanic contract. They were chosen so the enumerated base RTP lands near its 76% target; payouts are linear in that figure, so they were scaled as one block rather than tuned individually.

#8. Reel strips / weights

Canonical machine-readable reels remain in the versioned backend configuration.

The feature never spins a reel strip. It draws land/miss and prize values directly, so there is no feature reel set.

#9. Evaluation order

grid       = spinReels(reelSet)
baseWin    = evaluateLines(grid)
featureWin = countVisible(grid, "BONUS") >= 6 ? holdAndWin(grid) : 0
roundWin   = min(baseWin + featureWin, MaxWinMultiplier = 500)

#10. Feature model

#Feature: hold_and_win

Authoritative math is mechanic-owned: math/mechanics/hold-and-win/hold-and-win-math-draft-v0.1.md.

#Feature state transitions

#Closed-form derivation

Not available for the award. The respin-reset rule makes the number of steps an absorbing random walk whose transition probabilities depend on the current empty-cell count — a step over e empty cells lands nothing with probability (1-p)^e. The expected award is therefore measured, not derived. The two per-draw expectations that are closed form:

E[regular value] = 264 / 100          = 2.64×
E[landed prize]  = 3065 / 1026        ≈ 2.9873×

#11. RNG and mapping contract

No secret production seed material belongs in this document.

#12. Exact calculation

A tractable exact state-space method was not implemented. Simulation is not a substitute for exact calculation; it is the only method available here, and it is labelled estimated.

#13. Monte Carlo specification

n >= (z·σ / ε)²          SE = s / √n          CI = mean ± z·SE

#Simulation results

#14. Win distribution

Measured over 2,000,000 rounds — see the simulation report. Bin edges are the engine's existing ones (0, (0,1), [1,5), [5,10), [10,50), [50,100), [100,500), [500,1000), [1000,5000), ≥5000). Note that with a 500× round cap the top three bins can only be reached at the boundary: a capped round lands in [500,1000) exactly at 500.

Threshold probabilities will not be inferred from these coarse bins; any specific threshold claim requires its own counter.

#15. Max-win analysis

500× here is a reachable value, not merely a mathematical upper bound. Both facts are asserted: the value is attainable, and no round exceeds it.

#16. Test vectors and parity

Vectors are created at plan Task 9 and indexed in test-vectors/README.md.

Required scenarios:

• No win, no trigger
• Base line win without trigger
• Five BONUS — no trigger, no feature RNG consumed
• Six BONUS — trigger, exact lock order
• Miss-only step decrements respins
• Landed prize resets respins to 3
• Mini, Minor and Major landed prizes
• Ordinary sum below the cap
• Ordinary sum capped once at 500×
• Full grid awarding exactly Grand 500×
• Interrupted-round replay and duplicate step idempotency
• Reference RunToCompletion equals persisted step execution

#17. Draft Math handoff

#Open and locked parameters

Draft handoff criteria:

• All payout-affecting rules are defined.
• Draft metrics meet draft tolerances.
• Config and evidence are versioned and hashed.
• Test vectors cover critical paths.
• Unsupported mechanics are rejected or explicitly excluded.

#18. Tuning record

No tuning has been performed. Tuning is prohibited before DRAFT MATH approval; entries are added under math/tuning/ at plan Task 11, one per traceable revision, never overwriting the baseline.

#19. Lifecycle and freeze

stateDiagram-v2
    [*] --> Draft
    Draft --> Integration: Draft gate
    Integration --> Tuning: Measured change request
    Tuning --> Integration: New candidate
    Integration --> Frozen: Sim/parity/max-win gates
    Frozen --> Certification: Immutable package
    Certification --> Certified: External approval
    Certification --> Tuning: Rejected with new revision
    Certified --> Retired

Current state: draft. Frozen parameters at freeze time: reel strips and weights, paytable, landing probability, prize and jackpot weights, evaluation and cap order, RTP split, RNG algorithm/version and mapping, max win and cap.

#20. Certification evidence bundle

Not assembled. DRAFT / NOT FOR CERTIFICATION. Internal tests and simulations are not external certification, and this reference pack is not a certification candidate.

#21. Risks and limitations

#22. Final sign-off

Approved 2026-08-09 by the user (Bogdan), verbatim APPROVE FREEZE & HANDOFF, for the scope recorded in math/mechanics/hold-and-win/hold-and-win-math-handoff-v0.1.md.

The immutable Final is math/mechanics/hold-and-win/hold-and-win-math-final-v1.0.md, a verbatim copy of the approved draft-v0.2. The mechanic is developer-ready.

Developer-ready is not a certification claim and not a switch-on. Internal tests, simulations and this approval are not external certification, and the durable runtime is dormant in production until an operator flag is explicitly enabled.