Model and Blueprint Specification

A Spawn Model is a computational system whose state and update rules are explicit. A Blueprint packages one version of that Model with the information required to test, benchmark, and launch it.

The original Spawn specification used the tuple:

O = <S, f, sigma, tau>

That structure remains useful, but Spawn now applies it to Models and Worlds rather than only to digital organisms.

State space S

S describes everything the Model needs to represent one complete state.

A state must be serializable: it must be possible to convert it into a canonical byte sequence without hidden memory. The specification must define field order, data types, widths, endianness, and encoding.

Examples include:

• the location, velocity, and status of every marble in a race;
• the atmospheric grid used by a hurricane Model;
• the resources, military units, and diplomatic relationships in a war game;
• the players, score, inning, count, and baserunners in a baseball simulation.

Transition function f

f maps the current state and accepted inputs to the next state.

The Blueprint must explain:

• which inputs f accepts;
• which calculations it performs;
• which parts are deterministic;
• how randomness is generated;
• what happens when an input is invalid;
• which arithmetic and software environment affect reproducibility.

For a deterministic Model, identical starting state, inputs, and random-generator state must produce the same next state.

Seed sigma

sigma initializes any seeded randomness. The Blueprint must name the pseudorandom number generator and explain how its state advances.

The random-generator state belongs inside the serialized state. A seed alone is insufficient if the generator can advance outside the recorded transition process.

Tick trigger tau

tau defines what authorizes the Model to advance.

Possible triggers include:

• a scheduled interval;
• a public user action;
• a new block;
• the completion of a previous event;
• a batch of signed or recorded external inputs.

The trigger must be observable and unambiguous. A private operator timer is not enough for a World that claims public replayability.

Inputs and data versions

Many Models depend on information that changes over time. A baseball Model, for example, may use current rosters, starting pitchers, injuries, weather, and season statistics.

The Blueprint must separate:

1. the Model version, which defines the rules;
2. the data snapshot, which defines the facts supplied to one run;
3. the World configuration, which defines adjustable parameters;
4. the run seed, which controls seeded variation.

This separation allows a stable Model to use newer data without silently changing its logic.

Checkpoints

A checkpoint commits to a complete state at a specific point in the run.

One possible construction is:

H_0 = SHA-256(model_version || data_manifest || seed || serialize(s_0))
H_t = SHA-256(H_(t-1) || input_t || serialize(s_t))

The Blueprint must define checkpoint frequency, publication location, and the procedure used to reproduce a checkpoint.

Configuration boundaries

A Blueprint must state which values a Launcher may change. It must also define safe or tested ranges where those ranges are known.

A hurricane Blueprint might allow sea-surface temperature, wind shear, grid size, and initial disturbance to change. It should not allow a Launcher to replace the governing transition function while continuing to claim it is the same Blueprint version.

Required test package

A Blueprint should include:

• schema validation;
• deterministic replay tests where applicable;
• known-input and known-output fixtures;
• boundary and invalid-input tests;
• resource benchmarks;
• checkpoint and serialization tests;
• failure and recovery tests;
• a list of known limitations.

What the specification proves

A complete specification proves that a Model has been described precisely enough to inspect and test. It does not prove that the Model represents reality accurately, predicts future events, or produces economically safe outcomes.