Deterministic Execution

The historical Spawn core is:

O = <S, f, sigma, tau>

v2 expands this into a launchable Blueprint package.

Core transition

state[t+1] = f(state[t], inputs[t], prng_state[t]).

Requirements:

• complete finite/serializable state;
• no hidden mutable memory;
• deterministic execution under pinned environment;
• canonical input ordering;
• declared arithmetic semantics;
• deterministic PRNG state included in state when stochastic behavior is replayed;
• observable tick authorization;
• canonical serialization;
• immutable runtime/code hash by Blueprint version.

Blueprint package

• blueprint_id
• version
• designer
• state_schema
• transition_code_hash
• runtime_version/hash
• input_schema
• configuration_schema
• initial-state construction rule
• seed/randomness specification
• serialization specification
• checkpoint cadence
• observables
• dataset manifest
• provenance manifest
• verification_class
• benchmark_profile
• license
• royalty policy

Versioning

No silent mutation. Any change that can alter replayed state roots requires a new version.

Arithmetic classes

Spawn must not promise bit-exact replay for every scientific or parallel workload. Each Blueprint declares one arithmetic class:

EXACT

Integer, fixed-point, or otherwise canonical arithmetic produces identical serialized state bytes in the pinned runtime. Exact state-root equality is required.

PINNED FLOAT

Floating-point execution is restricted to a pinned runtime, compiler, libraries, hardware assumptions, operation order, and rounding behavior. Bit-exact replay may be claimed only after cross-run and cross-worker test vectors demonstrate it.

TOLERANCE VERIFIED

The Model permits documented numeric variation. It defines per-output tolerances, invariants, statistical tests, and an adjudication rule. Raw floating-point state hashes are not treated as proof that two valid executions must be byte-identical.

Parallel reductions, GPU kernels, transcendental functions, compiler optimizations, and dependency changes can alter floating-point results. A Blueprint that cannot meet its declared replay class must use a lower verification class or remain non-economic.

Reference artifacts

A replayable Blueprint must publish executable test vectors containing the initial state, ordered inputs, seed, runtime identifier, expected checkpoints or tolerance results, and failure cases. “Pinned WASM” or “deterministic” is not sufficient without reproducible artifacts.