Testing Verification and Replay

Spawn separates three questions:

1. Does the Model run as specified?
2. Does the World use the Model and parameters it claims to use?
3. Is the Model a good representation of the system it describes?

Technical verification can answer the first two questions. Scientific or predictive validation is required for the third.

Testing before launch

Designers should test a Model before submitting it as a Blueprint.

The test package should cover:

• schema and input validation;
• deterministic replay where the Model claims determinism;
• known cases with expected results;
• boundary values and invalid inputs;
• random-seed handling;
• serialization and checkpoint stability;
• resource use at several workload sizes;
• interruption, recovery, and resume behavior;
• security limits on user-controlled inputs.

Parameter testing

Launchers should test the exact World configuration they plan to deploy. Passing Blueprint tests does not prove that every parameter combination is stable, fair, interesting, or affordable.

A useful pre-launch process includes:

1. checking every parameter against its allowed range;
2. running short smoke tests;
3. running repeated simulations across many seeds;
4. identifying runaway, frozen, or trivial outcomes;
5. measuring runtime and storage cost;
6. testing adversarial player actions;
7. reviewing outputs with subject-matter experts when real-world claims are involved.

Replay

For a reproducible run, a verifier needs:

• the exact Blueprint version;
• the data manifest;
• the World configuration;
• the initial state;
• the random seed and generator state;
• the ordered input or event log;
• the declared execution environment.

The verifier reruns the Model and compares checkpoints.

recomputed checkpoint = recorded checkpoint  -> execution matches
recomputed checkpoint != recorded checkpoint -> execution mismatch

An execution mismatch should identify the earliest divergent step and publish enough information for another reviewer to reproduce it.

Verification classes

Not every World needs the same verification system.

• LOCAL: runs on a user's device and makes no public settlement claim.
• RECORDED: publishes inputs, configuration, and outputs for inspection.
• REPLAYABLE: an independent party can reproduce checkpoints.
• ATTESTED: approved verifiers attest to the result.
• ON-CHAIN: the relevant state transition or settlement logic executes on chain.

The World page must state its verification class. A lower class is acceptable when it matches the World’s purpose and economic risk.

Scientific validation

Replayability proves that the same rules produced the same output. It does not prove the rules predict reality.

Scientific or predictive validation may require backtesting, out-of-sample evaluation, calibration, sensitivity analysis, comparison with observed data, expert review, or peer review. The appropriate method depends on the Model.

Floating-point limits

Floating-point operations can vary across CPUs, GPUs, compiler settings, library versions, and parallel execution order. Models that need bit-exact replay should prefer integer or fixed-point arithmetic.

When floating point is necessary, the Blueprint must declare PINNED FLOAT or TOLERANCE VERIFIED behavior. A tolerance-based Model must publish the tolerance per output, invariant checks, benchmark fixtures, and the rule used when two valid runs differ within or beyond that tolerance. It cannot use raw state-root equality as its only correctness test.

Public replay evidence

A World may claim REPLAYABLE only when an independent user can obtain the necessary artifacts and execute the documented replay procedure. For v1, that means a public replay client or equivalent reproducible command, pinned test vectors, retrievable inputs, and visible checkpoint comparisons.