#Classic Fruits 3×3 — Math Specification

LEGACY FROZEN v1 — SUPERSEDED DESIGN. This specification and all figures below describe the immutable 95.3967% / 65× backend pack created for GDD 0.1.0. They do not implement the SEVENS-anywhere jackpot design in GDD 0.2.0. Preserve this document as historical evidence. The GDD 0.2.0 math is specified in classic-fruits-3x3-v2-math-spec.md (v2-draft-0.1); nothing below describes it.

#1. Identity and provenance

The SHA-256 above hashes the canonical YAML file as it existed at the recorded backend commit. Changing the YAML produces a different math version and requires regeneration of all evidence.

#2. Current verdict

The pack is mathematically enumerable and internally consistent, but it is not certified under the current low tier policy. “Frozen” describes config immutability, not certification approval.

#3. Bet and payout model

For line awards (L_1,\dots,L_5), the round multiplier is:

[ X = \min\left(65, \frac{\sum_{i=1}^{5}L_i}{5}\right) ]

The canonical pack uses float64 multipliers. Wallet money conversion and currency rounding belong to the platform boundary and are not defined by this pack.

#4. Target and exact metrics

Exact distribution figures:

Because there are no features, the exact distribution covers the complete round.

#5. Symbols and paytable

Values are per-line multipliers before division by five active lines. Wild substitution behavior is defined by the shared mathengine line evaluator. No scatter payouts exist.

#6. Paylines

Row 0 is top, 1 middle and 2 bottom.

#7. Reel model

Each reel is an ordered list of eight weighted entries. One weighted draw selects the top entry; the visible column is that entry and the next two entries with wraparound.

Rows on a reel are correlated. They are not three independent weighted draws.

#Reel 1

#Reel 2

#Reel 3

Reel 3 is identical to Reel 1.

Each reel's weights total 32, but this does not create 32 ordered strip positions. There are eight selectable entry indices per reel and therefore:

[ N = 8^3 = 512 ]

reachable reel-stop combinations.

#8. Expected symbol visibility

Exact expected cells per 3×3 grid:

#9. Evaluation order

select one weighted entry per reel
→ construct three contiguous wrapping columns
→ evaluate five fixed paylines with shared line evaluator
→ apply Wild substitution
→ sum per-line paytable awards
→ divide by five active lines
→ apply MaxWinMultiplier = 65
→ return total-bet multiplier

There are no feature executors, scatter contributions, recursive states or additional RNG draws after grid generation.

#10. Exact calculation

The exact calculator uses the same evaluator as runtime. This provides internal consistency, but independent cross-checking remains useful to detect shared evaluator errors.

#11. Win distribution

The current certification helper reports big-win frequency 0.001923 for its own configured threshold. That threshold is not identical to every coarse histogram band and must not be reverse-engineered from this table.

#12. Max-win analysis

The maximum is reachable without the clamp truncating a larger natural result. Any reel or paytable change must rerun ValidateMaxWin; increasing the declared cap alone does not create a reachable higher win.

#13. Monte Carlo cross-check

Exact calculation is authoritative for this enumerable game. Simulation is used only as a regression/cross-check.

Latest fresh test evidence observed while preparing this document:

The pack header also records a historical one-million-round run cf-cal-pB8-1m with 95.42% RTP and approximately 33.45% hit frequency. Exact figures supersede sampled header figures wherever both exist.

#14. RNG contract

Current backend behavior:

• seed string is SHA-256 hashed;
• the first eight digest bytes form the deterministic math/rand seed;
• each RNG instance has no global mutable state;
• the same seed and config reproduce the same result;
• five pack golden seeds currently pass.

This is deterministic replay evidence, not external RNG certification. Production seed generation, unpredictability, mapping analysis and jurisdiction-specific RNG testing remain separate release requirements.

#15. Golden and parity evidence

A formal game-engine/reference parity manifest should additionally bind vectors to Game ID, config hash, RNG version and runtime build identity.

#16. Certification findings

The current certification test grades the pack as tier low and returns rejected.

This creates a product decision:

1. Retain the current simple low-variance classic model and revise its certification classification/policy where legitimately appropriate; or
2. Create a new math version with different reels/paytable/targets to satisfy the current tier bands.

Do not mutate frozen v1 to force a pass.

#17. Lifecycle and handoff

flowchart LR
    A["Frozen math pack v1"] --> B["Exact report"]
    A --> C["Golden vectors"]
    A --> D["PAR sheet"]
    B --> E["Runtime parity gate"]
    C --> E
    D --> E
    E --> F{"Certification policy passed?"}
    F -- "Current result: no" --> G["Decision / new version"]
    F -- "Yes" --> H["Certification package"]

Handoff artifacts:

#18. Locked parameters

All of the following are locked in frozen v1:

• ordered reel entries and weights;
• paytable values;
• five paylines;
• Wild behavior through the evaluator;
• five-line normalization;
• 65× maximum-win cap;
• absence of features;
• RNG/replay behavior associated with existing golden vectors.

Any mathematical change requires a new config hash, new math version, regenerated exact/PAR evidence and full regression/parity testing.

#19. Risks and limitations

#20. Sign-off state