No pages match that search.
Product / TensorLynx / Provenance
Record · Provenance and engineering historyMonths after a study closes, someone asks where a number came from: a design review, a supplier query, an authority's question to your compliance team. TensorLynx answers from the record, not from memory. Every result is tied to the geometry version, mesh, solver version, settings, seeds and environment that produced it, and the record states how closely a re-run is expected to match.
Seed, fingerprint and environment sealed per study run Reports refuse to export an untraceable claim Verdicts and decisions are never rewritten
Simulation results outlive the people and the machines that made them. When the question comes back, the number is usually still there. The chain behind it is not.
Practitioners describe traceability as a central pain point which is experienced in all simulation domains
(NAFEMS World Congress 2021, source 1). The FAIR principles ask that data be associated with detailed provenance
(source 3).
Nobody fills in a provenance form. Each step of the loop writes its part of the record as a side effect of doing the engineering, and each step refuses to continue when the record would be incomplete.
Every physical parameter is declared with a unit, bounds and a default, and a platform default reads “missing, declare”, never a silent number. Computation is SI inside. A quantity with no declared unit is never written unitless, and a decimal comma is refused with a one-click fix.
A design study is versioned data. Once it has runs, an edit writes version n+1, so every run stays bound to the exact limits that judged it. The model fingerprint changes whenever the model, the mesh or a case file changes. Clone and branch, including a branch from a single candidate, keep their lineage.
A surrogate-based study run records its seeds, the study snapshot (SHA-256), the driver host code, the model fingerprint, versions, threads and an environment lock: the hash and the full package list. Run state lives in an append-only log, flushed to disk at every transition. Kept field files get checksums, verified again at close.
Geometry versions, meshes, cases, runs, campaigns, dataset versions, models and reports are nodes; “derived from”, “member of” and “follows” are edges. Upstream answers how did we get here. Downstream answers what does this change touch. Finished solver cases are recorded as they finish, without anybody remembering to import them.
A traced report checks every number, figure and verdict against the provenance store. A claim with no evidence, a cited node the store has never seen, or an export with no store at all: each stops the export and names what failed. The report’s identity is a digest of its claims, so the same analysis exported twice is one report.
Resume starts a new run linked to its parent and replays the parent’s recorded fits as it goes. A changed study, seed, engine or driver code, or a replay that drifts from the record, refuses with the reason. The run states its reproducibility class (bitwise, within tolerance or order-dependent) as measured, never inferred.
Provenance in TensorLynx is plain, inspectable files and one graph. Hover or focus any file to see what it holds.
Bitwise for deterministic sequential computation. Within tolerance for parallel solvers, whose rank count and build are recorded. Order-dependent where the result depends on the order of evaluation, as with a warm-started evaluator. A run’s class is the weaker of the evaluator’s and the driver host’s. A pack may supply its own measured wording, but the platform never shows that label without the case it was measured on.
Node kinds: project, geometry version, mesh, case, simulation run, campaign, dataset version, model, report and optimisation trajectory. Relations: derived from (a run is derived from a mesh and belongs to a case, which one parent pointer cannot express), member of, and follows. Node identity is a hash of kind and natural key. Lineage queries run recursively upstream or downstream.
Each number travels with its quantity and unit, so a value cannot reach a reader without them. Each verdict carries the rule that produced it and that rule’s citation in the block, not in a tooltip a printed page loses. The exported file has no scripts, external styles or fetches and prints from any browser. Levels carry a word and a glyph as well as a colour: PASS, CAUTION, FAIL, NOT MEASURED.
A digest of the acceptance limits identifies what judged each verdict. Change the limits and the recorded verdicts keep theirs and read Stale, re-judged on an explicit click. Rankings recompute live, but a recorded decision and its ranking are never changed: a later decision supersedes the earlier one, and both stay on record.
Reproducibility is measured on the platform’s own records against bars declared before the measurement, and each figure is reported with the case it came from.
When a study returns the same objective run after run, the record calls that determinism, not correctness. Correctness is the job of mesh verification and of the independent re-run in high-fidelity reassessment. Method
All three export refusals (no evidence, unknown node, no store) and the traced path are covered by tests, including publishing a report into a real provenance store and reading its lineage back. Method · test suite
The record closes the TensorLynx loop. The decision it holds is where the next design question starts, back in geometry-driven design exploration, with every earlier study still open to inspection.
Walk into a design review with every number traceable to its inputs, versions and checks. When the review changes a limit, you see which verdicts went stale instead of discovering it in the next meeting.
Reopen last year’s study, branch from its best candidate, or resume an interrupted run without rebuilding the set-up from notes. The platform tells you when a resume would not be faithful, and why.
Assemble evidence packages for design gates and certification from reports that cannot export an unsupported claim. Your engineers sign off; the record shows what they signed off on.
The intake shape behind a performance figure is questioned at a later milestone. The report walks back to its geometry version, mesh and the solver build that produced it.
A target tightens late. The new study version marks earlier verdicts stale and leaves the original record intact, so the gate sees both.
Long-life equipment is revisited years after design. Run records keep units and operating points, so a re-rating starts from the old case.
Surrogates trained on past campaigns carry the lineage of every sample. When a source run is questioned, the models that learned from it can be found downstream.
| Question | Typical workflow | With TensorLynx |
|---|---|---|
| Where did this number come from? | Folder names, slide notes, memory | Run record and provenance graph, upstream to the geometry version |
| Will a re-run match? | Assumed, then argued | A stated class with the case it was measured on |
| Did the limits change after the run? | Silent: the table reads current settings | New study version; old verdicts keep their limits and read Stale |
| Can the report be trusted out of context? | Whatever was pasted in | Export refused unless every claim resolves to evidence |
| Who decided, and on what? | Minutes, if kept | Appended decision with ranking and weights, as on the Pareto selection page |
It depends on the computation, and the record says which case you are in. Each design-study run carries a reproducibility class (bitwise, within tolerance or order-dependent) taken from what was measured, never inferred. Parallel solvers are tolerance-bounded, so a re-run is judged against a stated tolerance. Regenerating a campaign or a surrogate training run from its record reproduced every number exactly in the platform's end-to-end acceptance test.
A solver-neutral run record: solver and solver version, image digest, units basis, mesh size, conditions, operating points, the convergence verdict and who decided it, and the design and case it belongs to. Design-study runs add the seed, model fingerprint, study snapshot, driver host code, environment lock and thread count. Kept field files get SHA-256 checksums, verified again when the run closes.
Yes, as evidence your team assembles and signs. TensorLynx keeps the traceability: which inputs, versions and checks stand behind each number, and reports that will not export a claim without it. Neither OLTRION nor the platform signs off a design, and simulation never replaces the tests or approvals your programme requires.
The study is not edited in place: the change writes a new study version. Verdicts recorded under the old limits keep them and read Stale until an engineer asks for a re-check. Recorded decisions are appended and superseded, never rewritten.
Yes. Resume creates a new run linked to its parent and leaves the parent's state untouched. It is refused, with the reason, if the study version, seed, engine or driver code changed, or if replaying the parent's recorded fits does not reproduce them.
It is not meant to. TensorLynx keeps provenance inside the engineering loop, where results are made. Run records are plain JSON and reports are self-contained HTML files that open without a server, so they can be archived in whichever system your organisation already uses.
See how the record fits the whole platform on the TensorLynx overview.
Every capability hands its result to the next on the same model, the same units and the same record: geometry feeds physics, physics feeds sensitivities and learning, optimisation proposes, verification confirms, and the history keeps every step reproducible.
TensorLynx is built and run by the engineers who use it on client work. You can start small, with one geometry and one question, and grow into a workflow your own team owns.
Send a geometry, the objective and the constraints. We tell you which TensorLynx route answers it, what it needs from you, and what you will get back.
Our engineers run the loop on your problem: physics, sensitivities, optimisation and full-model verification, handed over with every setting on record.
A TensorLynx workflow, surrogate and verification gates set up around your product family, so the next design cycle starts where the last one ended.
Your team on TensorLynx, trained on your own cases, with OLTRION engineers behind it for the questions that need a specialist.
Simulation and AI predictions support engineering decisions; they do not replace the testing, approval and sign-off a product requires. Figures marked measured come from recorded TensorLynx runs on the stated case; figures marked synthetic or schematic illustrate a method.
