Deterministic generation

The same inputs have to produce the same frames.

If a run cannot be repeated, an experiment built on it cannot be repeated either, and a bad batch cannot be debugged because you can never get back to it. Determinism is not a nice property of a synthetic pipeline; it is the property that makes the rest of the evidence mean anything.

Master seed: 67
Config hash: e940fe63a119
Manifests: 40
Determinism check: passed

Three things have to be pinned

A run is reproducible when the seed, the configuration and the scene are all recoverable. Pinning one or two of them is the usual half-measure, and it fails in the way that wastes the most time: the run looks reproducible until the day it is not, and by then nobody remembers what changed.

The seed. One master seed drives every placement decision, recorded in the capture and again in each frame’s own manifest. This run’s was 67.
The configuration. The whole run contract, hashed. Classes, camera policy, spawn rules, render settings, quality thresholds. If any of it changed, the hash changes.
The scene. The map name and every actor’s position at capture time, so a level that was edited between runs is detectable rather than mysterious.

Recorded	Value
FRAME	plugin_000004
MAP	Map_Airbase_Demo
CONFIG	e940fe63a119
MANIFEST	f0c3ecffaa0c
SEED	67
CAMERA	sunlit_far · 8 attempts
STATUS	ACCEPTED

Checking it rather than claiming it

Determinism is easy to assert and cheap to test, so the pipeline tests it on every capture instead of putting it in a feature list.

Relabel and compare

Two frames are put through the labelling path a second time and the output is compared byte for byte against the first pass. Reference result: 2 frames labelled twice, byte-identical.

Verify the snapshot

The stored configuration is rehashed and checked against the recorded hash, so a snapshot that was edited after the fact does not pass silently. configuration snapshot verified (e940fe63a1198cb9abc634330de558b19de566e60ec4c6fa0043b71001110f9e)

Reconcile the manifests

Every frame manifest is checked against the run index: counts, hashes and rejection reasons all have to agree. 40 frame manifests and index agree; 3360 candidates, 0 rejected with reasons

Note what the first check does and does not prove. It proves the derivation is deterministic: given the same dump, labelling twice gives identical bytes. It does not prove that re-rendering the scene on different hardware gives identical pixels, because it does not, and claiming otherwise would be a lie about how GPUs work. What is guaranteed is the placement decisions, the metadata and everything derived from the buffers.

What reproducibility buys you in practice

Four things that are impossible without it, and are the reason it is worth the bookkeeping.

Ablations that mean something

Change the weather, hold the seed, and the two runs differ by the weather. Without determinism they differ by the weather and by everything else, and the comparison is worthless.

Debugging a bad batch

A frame that looks wrong can be regenerated on its own, with the same seed, and inspected. The manifest names the actor, the actor names the asset.

Auditing a delivered dataset

Months later, the hash says whether the dataset you have is the one the report describes. 3,360 placements, all traceable to a decision and a seed.

Resuming a long run

A fifty-thousand frame soak that stops at batch thirty resumes at batch thirty-one with the same contract, rather than starting again.

# the seed lives in the job, not on the command line, so a job file
# fully determines a run
{
  "seed": 67,
  "source": { "map": "Map_Airbase_Demo" },
  "scene_contract": {
    "population_mode": "spawn_zones",
    "scatter_min_spacing_m": 1,
    "scatter_max_slope_deg": 12,
    "shuffle_per_frame": true
  }
}