Store the Seed, Own the Result

"Randomness you saved the seed for isn't really random anymore — it's a result you can prove."

The paradox of reproducible randomness

Monte Carlo is built on random draws, so at first it seems like the opposite of reproducible — run it twice, get two different fans. Keep dissolves that paradox by storing the random seed alongside every run. A pseudo-random generator is deterministic: give it the same seed and it produces the exact same sequence of "random" numbers, every time, on every machine. So a run that captures its seed can be regenerated bit-for-bit later. The randomness is real enough to explore possibility, and pinned enough to reproduce and audit.

What a run persists

Reproducibility means capturing everything that determined the output, not just some of it. A Keep simulation run stores the full determinant set: the mode, owner, ticker set, horizon, iteration count, hurdles, mean-reversion coefficient, calibration, seed prices, the percentile paths, the results — and the random seed. Miss any one of these and the run stops being reproducible: the same seed with different inputs gives a different answer, and the same inputs with a lost seed gives different random paths. Reproducibility is all-or-nothing. You capture the complete recipe, or you can't rebake the cake.

To reproduce a computation, persist every input to it — the seed included. A result you can't regenerate is a result you can't verify, debug, or trust later. The random seed is an input just as much as the parameters are; treating it as throwaway is the single most common way 'reproducible' simulations quietly aren't.

Why an auditable run matters here

This isn't academic rigor for its own sake — it serves the calm, honest posture of the whole app. Because a run is fully persisted and replayable, you can come back to a scenario months later and see exactly what it assumed and produced, not a fuzzy memory of "I ran something like this once." There's no mystery number floating in the UI that nobody can reconstruct. Every scenario is a durable, inspectable artifact with a complete provenance — the same honesty Keep applies to prices and cash, applied to simulations.

Deletion is precise, too. A run is identified by its own numeric primary key, and deleting a run targets exactly that key — you remove one specific run, not a fuzzy match that might catch others. Precise identity for creation, precise identity for deletion: a run is a first-class, individually-addressable record from birth to removal.

Code

The seed makes 'random' reproducible (illustrative)·python

import numpy as np

def run_simulation(inputs):
    seed = inputs.get("seed") or new_seed()   # chosen once, then persisted
    rng = np.random.default_rng(seed)         # deterministic from the seed
    result = simulate(**inputs, rng=rng)
    persist_run({**inputs, "seed": seed, "result": result})  # store EVERYTHING
    return result

# Replaying is exact: same inputs + same seed -> identical fan.
def replay(run):
    rng = np.random.default_rng(run["seed"])  # the SAME seed
    return simulate(**run["inputs"], rng=rng)  # bit-for-bit the same result

# assert replay(run) == run['result']   # holds, forever, on any machine

Exercise

Find any computation you've run that used randomness (a shuffle, a sample, a simulation, a synthetic dataset). Could you regenerate the exact same output today? List everything you'd need to have stored to do so — and check whether the seed was one of them. Then describe a debugging situation where NOT having the seed would leave you unable to reproduce a result someone is asking about.

Hint

The classic failure: 'it gave a weird result last week, can you reproduce it?' — and you can't, because the seed was never stored, so every re-run gives fresh randomness. Storing the seed turns 'I think it did something like this' into 'here is the exact run, regenerated.'

Store the Seed, Own the Result

The paradox of reproducible randomness

What a run persists

Why an auditable run matters here

Code

External links

Exercise

Progress

Comments 0