Reproducibility Is a Deliverable: Packaging Simulation Provenance Before the Thread Snaps

A released simulation that cannot be rerun is not evidence. It is an assertion with a timestamp. Most engineering organizations have invested heavily in the first half of that sentence: the release workflow, the approval trail, the CAD revision, the BOM state. The second half, the part where a colleague or an auditor can reconstruct the run and get the same answer, is often held together by a shared drive, a solver deck named final_v7, and the memory of the engineer who built it.

That is the quiet failure mode of the digital thread. It does not break dramatically at the CAD-to-CAE handoff. It breaks later, when someone asks a simple question: what exactly produced this result?

The Thread Ends Where the Solver Begins

PLM systems are excellent at managing the artifacts they were designed to manage: CAD models, drawings, BOMs, engineering change orders, and release states. They are considerably less good at capturing the causal chain inside a CAE run. A released assembly may point to the correct geometry, but the simulation that justified a design decision depends on a different set of objects: the solver version and build, the input deck, the material card, the boundary conditions, the contact definitions, the mesh export settings, the convergence controls, the run script, and the postprocessing recipe.

None of those items are naturally versioned by PLM. Some live in the CAE tool. Some live in a job queue. Some live in a license server log. Some live only in the engineer's home directory. The result is a thread that looks continuous on an org chart and discontinuous in practice.

This is not an argument for replacing PLM. It is an argument for treating simulation provenance as a first-class deliverable and for packaging it before the thread has a chance to snap.

A Reproducible-Model Audit, Not a File Dump

A reproducible-model audit asks a narrow question: could a competent engineer who was not involved in the original run reproduce the result within a stated tolerance? That question is different from whether the files still exist. A folder full of decks and screenshots can fail the audit completely.

The audit should cover five tiers of information.

Identity and linkage. Which CAD revision, BOM state, and configuration does this simulation correspond to? Which analysis case was intended? Which release decision does it support? The package should link back to the released item, not merely sit near it.

Environment. Which solver product, version, and build number were used? Which operating system, MPI library, and hardware class? Which license features were checked out? Solver behavior changes across releases, and a result that depends on a particular build is not reproducible on a different one without a stated equivalence check.

Inputs. The input deck, material cards, unit system, mesh export settings, boundary conditions, loads, initial conditions, and contact definitions. Material cards deserve special attention because they are often maintained outside PLM and edited in place. A hash of the material card is more useful than a filename.

Decisions. Every model contains simplifications: defeated features, idealized joints, substituted materials, reduced domains. These decisions are usually documented in a report, if at all. For reproducibility, they belong in the package as explicit notes with a rationale and, where possible, a sensitivity check.

Outputs and postprocessing. The raw results, the postprocessing script, the extracted quantities of interest, and the acceptance criteria. A contour plot is not a result. It is a rendering of a result.

An audit that covers these tiers will expose the usual gaps quickly. The point is not to achieve perfect reproducibility for every exploratory run. It is to make the gap visible and to reserve full packaging for the models that support released decisions.

The Metadata Package: Small, Signed, and Portable

A practical simulation provenance package does not need to be elaborate. It needs to be small enough that engineers will actually create it, structured enough that software can index it, and immutable enough that it can be trusted later.

A minimal package can contain a manifest, the input deck, the material cards, the run script, a short README, and checksums for every file. The manifest is the important part. It should record the package identifier, the linked CAD revision and BOM state, the solver build and environment, the material card hashes, the convergence settings, the responsible engineer, the date, and the tolerance within which the result is considered reproducible.

The package should be signed or hashed at release time. That does not require a blockchain or a bespoke platform. A checksum recorded in the release record is enough to detect later tampering or accidental substitution. If the organization already has an artifact repository, the package belongs there with an immutable retention policy. PLM can hold the index record and the link; it does not have to hold the payload.

The README matters more than teams expect. It should state what the model is for, what it deliberately does not represent, and what a reviewer should check first. That is the difference between a data dump and a reproducible deliverable.

Where It Lives: PLM-Adjacent, Not PLM-Native

Most PLM systems can store files. Few can store the semantic relationships that make a simulation reproducible. A pragmatic architecture is PLM-adjacent: PLM remains the system of record for the released configuration, while a versioned artifact repository stores the provenance package and exposes a stable link back to the release.

This avoids the two common failure modes. The first is stuffing everything into PLM and discovering that the CAE payload is too large, too transient, or too poorly structured to manage there. The second is leaving everything in project folders and discovering that the thread depends on institutional memory.

The linkage should be bidirectional and enforced by workflow. A release that depends on simulation should not be marked complete until the provenance package is attached or a documented exemption is recorded. That single gate changes behavior more than any standards document.

Putting the Vendors on the Spot

Engineers should not wait for PLM and CAE vendors to solve this by acquisition or roadmap slide. Procurement teams can ask concrete questions. Can the solver emit a machine-readable environment lockfile at run time? Can the CAE tool export a manifest that includes material card hashes and solver controls? Can PLM link a simulation package to a CAD revision and a BOM state without custom middleware? Can two packages be diffed to show what changed between runs? Can the vendor demonstrate reproducibility across a solver upgrade?

These are reasonable requirements in 2026. They are also useful differentiators. A vendor that cannot answer them is asking the customer to pay for a thread that ends at the solver boundary.

Start With the Releases That Matter

A reproducibility program does not need to begin with a enterprise-wide mandate. It can begin with a short audit of the last quarter's released simulations. Pick the ten models that supported the most consequential decisions. Try to reproduce them. Document where the chain breaks. Then package the next release properly.

The digital thread is not a diagram. It is a chain of custody for engineering evidence. If the chain stops at the solver input deck, the release record is only telling part of the story. Packaging simulation provenance is how engineers make the rest of the story available to the people who will need it later.