# Verifiable outputs

The four tools and the game run in the browser, so a crawler cannot exercise
them. These are the artifacts they produce, with the files to check them
against. Every number here is derived from something published on this site.

## Jackpot Climb: Treasure Temple — the shipped math model

Fetch the model itself: https://gamemathemagics.com/games/treasure-temple/MathModel.json
(This is the same file the playable demo loads, not a summary of it.)

| component | RTP contribution |
| --- | --- |
| climb | 28.76% |
| absorbers | 9.98% |
| progressive | 1.00% |
| **total (target)** | **95.78%** |

The named features account for 39.74% of the 95.78% total; the remainder is base-game return.

The total was set to a measured value: 95.78% over a 2-billion-spin Monte
Carlo run, not a design aspiration. The progressive contribution of 1.00%
is exact in closed form rather than simulated. Each feature is verified
analytically and against simulation independently.

## Loom — solver output, browser vs desktop

Loom builds reel strips from targets using the co-location matrix framework
in the paper, and runs the same solver in the browser that the desktop build
runs, via a Worker and a WebAssembly MILP solver (HiGHS).

A volatility-band solve on a real 5-reel, 11-paying-symbol design:

```
CV band     2.8146 .. 3.1179   (span x1.1078)
RTP drift   0
wall time   ~12 s
```

That result is byte-identical between the browser build and the Electron
desktop build, which is the point: the web version is the real solver, not a
demo of one.

## The paper

Full text, 59 pages: https://gamemathemagics.com/papers/reel-strip-construction.pdf
Zenodo record with DOI: https://doi.org/10.5281/zenodo.22139239

Its central claim is falsifiable and stated as such: the current state of the
art (Kamanas et al., 2021) searches count vectors for RTP alone and lists
independent hit-rate and volatility control as open future work. The paper
closes that by construction rather than by search.

## What cannot be checked without opening the site

The interactive behaviour: designing a strip in Loom and playing it, running
a session-economics query in Foresight, authoring a game graph in Maestro,
or spinning the cabinet. Those need a browser. Everything above does not.