§ Platform / Correctness
Proven, not promised.
Consumer GPUs differ, drivers differ, and floating point does not care about your deadline — so correctness here is machinery, not an attitude. A CPU reference anchors every compute path, anything unverified is checked before it counts, and the verification kit itself is published under a permissive license, so no claim on this page has to be taken on faith.
Every result answers to a reference
The engine keeps one correctness anchor: a CPU reference that defines the intended result of every built-in operation. Every GPU kernel, including the hand-tuned paths behind training in your browser, must reproduce that reference within a declared tolerance on the hardware it actually runs on. A missing GPU kernel is a bug to fix, never a quiet fall-back to the CPU — a substitution that changes your numbers or your speed does not happen behind your back.
Tolerance is part of the contract, not folklore. Four classes — exact, tight, default, and loose — each resolve to a declared pair of absolute and relative bounds, and the class an operation claims has to be justified by what it does: a matrix multiply cannot declare itself loose to dodge the check. The declared class shows up in the catalog as a trust signal, so a loosely-toleranced training operation is visibly lower-trust before you depend on it.
Every kind of artifact earns trust through a named check
| Artifact | Checked by | The rule |
|---|---|---|
| Built-in kernels | the reference | Every GPU implementation must match the CPU reference within its declared tolerance — on each kind of hardware. |
| Kernels you write | conformance evidence | Bound to the exact code and to the hardware it was proven on; required before trusted, shareable use — on your own device it runs freely either way. |
| Gradient rules | gradcheck | Finite differences against the author's own forward pass — with a mandatory negative control. |
| Combining rules | property tests | A rule that claims it can combine partial results in any order is tested both ways before any planner is allowed to rely on it. |
| Results from other devices | re-execution · quorum | Verified within tolerance before they count — never trusted on arrival, and never compared bit-for-bit on the GPU path. |
| Bytes & caches | SHA-256 | Anything that fails its hash is corruption — refetched, never patched over. |
One checker, two audiences: the same check that gates your content at publish also gates ours — trust is earned, and it does not care who wrote the thing.
Trust is a property of the artifact — earned by machinery and recorded next to it — never a property of who made it. Compute you write yourself passes exactly the checks the built-in content passes, through the same checker, and the checks compose upward: a trained model records the conformance status of everything it was trained with, so a model trained on an unverified gradient stays distinguishable from a fully conformed one, and is never quietly presented as equivalent.
The catalog shows all of this before you depend on anything: where it came from, how far it is trusted, whether it has been checked, and what tolerance it claims — real signals on the card, not decoration. Community work can reach verified; official is not a shortcut past the checks, because there is no path past the checks.
You choose how reproducible a run is — nothing changes it quietly
| Setting | Guarantee | Stated plainly |
|---|---|---|
| debug | Bit-for-bit identical — same seed, same device | Deterministic GPU code: a fixed order of operations, no shortcuts — a real, visible cost in speed. |
| prod | Deterministic within the declared tolerance | The working setting for training and reproducible analysis — agreement within the bounds the operation declared. |
| fast | Freer ordering, only where it is declared safe | Maximum throughput; every relaxation is declared, and none of them is silent. |
| (not set) | Refused at compile | No setting, no run — a named diagnostic, never a quiet assumption on your behalf. |
Bit-for-bit sameness across different devices exists only on the CPU reference path — GPU arithmetic does not add up in a fixed order, so GPU runs reproduce to their declared tolerance. A physical limit, published in honest limits rather than rounded up.
How exact a run is, is a dial you set — and it is carried all the way down, into the code that runs on the GPU, and recorded in the run's record. The dial has no hidden position: a workflow whose setting is undefined is refused with a named diagnostic rather than patched with a quiet default, because a wrong number that looks right is the worst thing a scientific tool can produce.
Randomness is engineered for replay. The generator is counter-based: the same seed at the same position gives the same draw on any hardware; dropout, shuffling, and augmentation each own a named stream of their own; and the full state of the generator lives inside every checkpoint. So a resumed training run continues the exact stream it left, and a piece of work sent to another device draws the same numbers wherever it lands.
Your kernel earns trust the way ours does
Write a GPU kernel and you pair it with a reference of your own. The conformance check then generates the test cases itself, from your signature and shape contract, and proves your GPU code matches your reference within the tolerance you declared. Sharing it as a trusted artifact requires the resulting conformance evidence — which is bound to the exact code and to the hardware it was proven on, so someone else's machine re-proves it locally instead of importing your trust.
The gate bounds trust, never execution: your own device always runs your own unproven kernel — what the check governs is what may be shared, trained with, and dispatched as trusted, not what you may try. Gradients climb the same ladder: a declared gradient is checked against finite differences of your own forward pass, and the harness insists on a negative control — it must also catch a deliberately wrong gradient, or the check itself does not count. The limit comes with it: a passed gradient check is strong evidence, not a formal proof.
Results from other devices are verified, never believed
GPUs disagree in the last bits: floating-point addition does not add up in a fixed order, and the browser's GPU standard makes no promise of bit-for-bit sameness across devices. So when devices pool their compute, a returned piece of work is never verified by comparing hashes — it is re-executed within its declared tolerance, or settled by agreement among several devices, before it counts. Reproducibility is declared in two honest tiers: bit-exact on the reference path, tolerance-bounded on the GPU path — and every run says which one it is.
Even a declared shortcut is tested. When work is split across devices, the planner is allowed to combine the partial results in whatever order they arrive — but only if the rule that combines them says that is safe. A rule that says so wrongly would quietly produce wrong science, so the claim is property-tested before it is ever relied on, negative control included. A combining rule that honestly cannot work that way refuses the shortcut by construction, and pays the stated cost of a single collector.
Every claim on this page is independently checkable
The verification kit itself is published under a permissive, Apache-class license: the specifications and schemas, the conformance corpus with its declared tolerances, and the CPU reference — the interchange ring of the platform. Anyone — a reviewer, an auditor, a competitor — can re-run the checks against the same references and verify every correctness claim here without asking permission.
The proof also outlives our releases. A frozen corpus of work from earlier engines re-runs automatically on every engine release, so an update can never quietly change what an old operation computes; that your work outlives our releases is tested, not asserted. And every run pins the engine version and the precision setting that produced it, so a reproduced result names the exact engine it answers to.