Simulation Acceptance: Identify Every Randomness Source

A robot simulation delivery includes a seed field and a claim that the experiment can be repeated. The buyer still does not know which parts of the software use that field. Simulation acceptance should identify each randomness source relevant to the commissioned task before treating the seed as a complete reproducibility record. This fictional review contains no simulation run, generated values or comparison result.

Draw the boundary around the process being repeated

Ask the supplier which task the repeatability claim concerns. It might be preparation of initial conditions, generation of a disturbance or a sampling step in an analysis component. Those tasks can belong to different parts of a software package. A single field in a launcher does not explain every component's initialization.

The imaginary buyer has received an orchestration script and an analysis module. The supplier should explain whether they share one generator or initialize separate generators. The reviewer should not assume the answer from the fact that both records contain a seed label. Identify the relevant components and retain the supplier's account of how their initialization relates to the delivery.

The agreed review should also state what it excludes. Reproducing a sequence used in an analysis is not the same as validating a physical robot, a sensor model or a complete simulator. Keeping the target observation narrow makes the handover question answerable without promising equivalence that the evidence does not address.

Read the generator's compatibility conditions

The NumPy random compatibility policy describes strict conditions for stream compatibility, including the same generator configuration, seed, sequence of calls and relevant build and environment. Its discussion makes clear why a seed alone is not an unlimited cross-environment promise. The buyer must identify the policy applicable to the delivered implementation.

Request a record of the software context the supplier considers necessary for the commissioned comparison. That explanation should be specific enough to relate the package to the claimed result. Do not replace missing build information with an assumption that all releases behave identically. Equally, do not declare a difference in environment to be a failed simulation when no comparison has been performed.

The purpose of this documentation review is to understand the stated conditions. It does not require disclosing private infrastructure or prescribing a new execution environment. The parties should agree on the evidence appropriate to their commission and keep actual software experiments within an authorized isolated workflow.

Keep separate libraries' initialization records distinct

The Python random module documentation discusses reproducibility with qualifications about threading and changes across versions, alongside limited compatibility guarantees. That policy concerns Python's documented generator behavior. It should not be silently substituted for the policy of a separate NumPy generator or another simulation component.

If the package uses more than one library, ask which generator each relevant operation calls. Two settings with the same written seed do not, by themselves, establish that the implementations produce the same stream. The supplier should explain whether the commission expects independent initialization or a particular coordinated arrangement.

Keep that explanation associated with the delivered components. A general statement that everything is seeded may leave the reviewer unable to locate the actual initialization paths. Request the missing association rather than inventing a seed value or modifying code to force an apparent match. This article supplies no program edits or runtime commands.

Specify the comparison that would answer the acceptance question

Where the contract requires an observed repeat, name the starting package, initialization record and output to compare. Decide beforehand which variation is in scope. The supplier and responsible reviewer should retain the actual observation and relevant conditions. A demonstration that produces similar-looking graphics may not answer a question about a particular generated sequence.

If the comparison is not part of the current review, say that only the documentation was examined. That can still produce a useful finding about whether the reproducibility claim is sufficiently specified. Do not describe an unperformed run as successful or failed, and do not turn a software-sequence question into a claim about physical equipment performance.

Accept the stated repeatability boundary

The final note should identify the process, generator ownership, initialization evidence and environment assumptions actually reviewed. Unexplained components should remain visible with a targeted clarification request. Accepting one documented randomness source does not establish that every part of the simulation is deterministic or that all future releases preserve the same output.

The original diagrams show component and review relationships without seed values or generated data. Related reproducibility topics appear in the robot simulation collection, and the article directory provides further reading. A useful acceptance makes a repeatability claim specific enough to inspect while leaving unsupported extensions outside the conclusion.