A random-drawing step records its seed beside the result — what does the recorded seed fix, and what does it not?

## What a seed is, and the one thing it fixes A random generator produces a long deterministic sequence of values from a starting point. **A recorded seed** is that starting point, fixed deliberately and written down beside the result, so the same sequence can be produced again. It belongs in the same evidence as **a clean run from empty** — a new process with nothing bound, executing every block once in the order the file lists them — because a file with an unrecorded random step does not reproduce even when everything else about it does. The guarantee is narrow and exact: **the same generator, seeded with the same value, hands out the same numbers in the same order.** Every extension of that sentence past 'the generator you seeded' is an assumption, and this is the question interviewers use to find out whether a candidate has ever checked one. ## The distance between the block that seeds and the block that draws This is the version specific to an interactive session, and it catches people who know the rest. Set the starting point in one **block**, draw in another, and the values you get depend on **how many draws happened in between** — because the generator advances with every value it hands out and nothing rewinds it at a block boundary. So the same file gives different numbers depending on how the session was driven: - You re-executed the drawing block to look at the output again; the second execution continues from where the first left off. - You ran an exploratory block that drew a few values and then deleted it; the generator advanced anyway. - You inserted a new step above the drawing block; every draw below it now starts from a different position. None of these change the file in a way that explains the moving number, which is why the symptom is reported as 'the seed does not work'. It works; the draws are not where you think they are. The habit that fixes it is to seed immediately before the work that draws, in the same block, so the distance between the two is zero — and then to prove the whole thing with a clean run from empty, where the draw count is whatever the file says it is. ## What a seed does not reach | Source of variation | Does one recorded seed fix it? | Why | |---|---|---| | Serial draws from the generator you seeded | Yes | This is exactly the guarantee | | A component holding its own generator | No | It never consults the one you seeded | | Parallel workers, one stream each | No | Each stream advances independently and the interleaving varies | | Iteration over a hash-based structure | No | The order is arbitrary and is not a draw | | The order concurrent results arrive | No | Timing, not randomness | | A different generator implementation | No | The same seed on a different algorithm gives different values | | Input data that moved | No | The seed governs the generator, never the input | The parallel row is worth dwelling on. Splitting work across workers is the single most common way a run that reproduced yesterday stops reproducing today, and nothing about it looks random from the outside: the code is identical, the seed is identical, and the answer moves by a fraction of a percent every run. ## Recording it so it counts as evidence 1. **Choose the value explicitly** and write it into the file, rather than letting the tool pick one and never learning what it picked. 2. **Seed each generator that is actually in play,** or pass one generator explicitly into the components that need one, so there is a single stream rather than several you have not enumerated. 3. **Print the seed with the result,** not only in the file. A number quoted in writing without its seed cannot be checked later by anybody. 4. **Say whether anything ran in parallel,** because that one sentence tells a reader whether to expect an exact match or a close one. 5. **State the tolerance** you would accept on a re-run when an exact match is not available, so 'it did not reproduce' becomes a measurement rather than an argument. ## The honest sentence Rather than 'the seed makes it reproducible', write what you actually checked: *'seed recorded; one generator, seeded in the same block as the draws; single-threaded; clean run from empty gives the identical figure.'* Every clause there is something a reader can falsify, and each one names a source of variation the seed alone does not cover. A seed is one line of the evidence, not the whole of it.