Reproducible robot simulation depends on more than matching solver settings and recording a fixed physics step. Teams that rebuild a run months later need to know which asset versions existed, which activity consumed them, and which agent was responsible at a given time. On this site we treat a published fact and its date, scope and source as separate from any editorial inference drawn from that fact. The two reference points used below are the NIST additive manufacturing program page and the PROV Model Primer. Neither document is about robot simulation directly; they are used here as external evidence for how measurement standards and provenance models describe recorded facts and their origins.
When a lab publishes that a simulated robot arm reached a target pose under a certain controller, the statement itself is a fact only inside a stated scope: the asset version, the time the activity ran, and the source that recorded it. Editorial inference begins when a reader writes that the controller "works well" without restating the mesh, inertia and calibration used. The NIST additive manufacturing page describes measurement science and standards for layered part production; the published fact there is that NIST works with U.S. industry on measurement and standards. That fact has a source and a program scope, and should not be silently widened into a claim that all printed robot parts meet a tolerance. Keeping the header separate means future readers can see whether they are reading the fact or the comment.
A simulation asset is not only its file. It is an entity that was generated by an activity, used by another activity, and possibly revised. The PROV Model Primer introduces entities, activities, agents and time as core concepts for describing how a piece of data or thing came to be. Applying that model, a robot mesh used in a run is an entity; the export from a CAD tool is the activity that generated it; the person or script exporting it is the agent. The date belongs to the activity, not only to the file name. A published fact such as "the collision mesh was generated on 2026-10-20 from source revision 14" carries its own time and scope. An inference that the collision model is therefore valid for a new payload is editorial and must be labelled as such, because the primer does not say a single generation event covers later changes in use.
In a reproducible robot simulation, the distinction between the robot type records and the run configuration matters. A specific arm model in a library is one entity; the instantiated scene with its gravity vector and friction values is another. The PROV primer explains usage and generation: an activity uses entities and generates new entities. A solver step uses the scene entity and generates a trajectory entity. If a team publishes only the trajectory without the used scene entity, the fact is incomplete for reuse. The NIST page, in its own domain, emphasizes comprehensive measurements and standards as the field matures; the parallel for simulation is that recorded measurements of asset identity and time are part of what makes a run comparable. We infer locally that unrecorded usage breaks comparability, but that inference is ours, not a statement found in either source.
Responsibility in provenance answers who or what is accountable for an entity. A script that converts a visual mesh into a collision shape is an agent in the PROV sense, even though it is software. A reviewer who approves a parameter file is another agent. The NIST additive manufacturing material notes standards development as part of its core mission; similarly, assigning agents to simulation artifacts lets a team later ask which conversion produced an unexpected inertia. Suppose a hypothetical case: a team records that "mesh simplification agent v2 produced collision asset B at 09:00 UTC" (hypothetical). The published fact is the record with its timestamp and agent; the inference that B is safe for all future controllers is not contained in the record and would need separate testing evidence.
Robot simulation assets are revised: a new inertial estimate replaces an old one, or a camera pose is recalibrated. The PROV primer describes derivation and revision, and alternate entities and specialization, meaning the same thing can be represented by different entities under different perspectives. A published note might say "revised inertia entity derived from original CAD entity on 2026-10-25". That is a fact about the derivation. Saying the earlier run is therefore invalid is an editorial step; it may be true for a specific tolerance, but the validity judgement depends on the comparison scope the team defines. Internal pages such as simulation frame records and calibration and pose records show how different asset classes each need their own revision trail rather than one global "latest" file.
The value of the two supplied references lies in how they frame recorded facts. The NIST additive manufacturing page is evidence of a measurement-science approach to a production method; the PROV primer is evidence of a general model for entities, activities, agents, usage, generation and time on the web. Neither validates a particular robot solver or a specific inertia value. What a reproducible simulation workflow can take from them is structural: state the entity, the activity, the agent, the time, and keep any interpretation of a result in a separate editorial layer. When we write that a recorded camera pose should be accompanied by its image calibration, that recommendation builds on the primer's separation of an entity from how it is used, and on our own site's practice of splitting a published fact from inference. The reader should be able to strip our comments and still have every original asset fact with its date and source intact.