How to prove which model version produced an AI result

The problem: a result outlives the context that produced it

A model produces a number, a mask or a label. It is stored, shown in a report and relied on. Months later someone — an auditor, a customer, an engineer investigating an incident — asks where that number came from. By then the model has been retrained, the deployment has changed and the logs have rotated. What they need to establish, for that one result:

• Which model produced it, and which exact artifact — not just which name or tag.
• What input it received.
• Where it ran, on which runtime and on what hardware or environment.
• When it ran, and whether it succeeded.
• What exactly came out, and whether the result in hand is that output.
• Which of these facts were observed independently, and which were only reported.

Model versioning, training lineage, observability and execution provenance

Four practices are often mixed up when this question comes up. Each answers a different question, and none of them replaces the others.

Model versioning

Which model artifacts exist and how they are named: a registry entry, a tag, a version number. It tells you that “v7” exists, not that “v7” produced a particular result.

Training lineage

How an artifact was produced: training data, code, parameters, experiment. It explains where a model came from, before it ever runs.

Observability

How a running system behaves over time: latency, errors, throughput, drift. Aggregated and sampled by design, and usually not kept per result.

Execution provenance

What actually took part in one particular inference — model artifact, input, runtime, environment — and what it produced, with the source of each fact. This is the layer that links a result to a version.

What should an inference audit record contain?

A practical execution record, written once per run. This is not a legal or industry standard; names will differ between systems. What matters are its properties: immutable identifiers, captured when the model runs rather than reconstructed later, and each fact with its source.

Execution

execution_id, creation and completion timestamps, final status (succeeded, failed, cancelled) and the reason for a failure.

Model

model_name, model_version and model_hash — the SHA-256 of the exact file that was executed. The hash is the identity; the name and version are for people.

Input

input_reference (where the input is kept) and input_hash where appropriate, so the record can be checked against the data without copying it.

Runtime

runtime and runtime_version — for example the inference engine that loaded the model — when they are known.

Environment and hardware

The provider, the kind of environment (cloud, edge, simulated), region and device, when they are known.

Output

output_reference and output_hash for every result artifact.

Evidence

For each important fact: was it reported by the infrastructure, observed by the platform that ran the job, or verified by an independent check? Unknown values stay unknown, never zero.

Why hashes matter, and what they do not prove

A cryptographic hash such as SHA-256 is a fingerprint of a file’s exact bytes. Change one weight and the hash changes. That makes the hash, not the name, the reliable identity of a model: “detector-v2” can be overwritten, the hash of the file that was executed cannot be reassigned to different bytes.

Hashing the model, the input and the output, and writing the three hashes into the same execution record, lets someone later establish that the artifacts being discussed are byte-for-byte the ones that took part in the recorded run.

• A hash identifies bytes; it does not prove that those bytes were executed. That link comes from the record being written by the system that ran the job, at run time.
• A hash does not make a record tamper-proof. Protecting the record itself — append-only storage, signatures, external anchoring — is a separate decision.
• A matching output hash does not mean the computation is reproducible. Many runtimes and accelerators are not bit-for-bit deterministic; re-running the model may give a slightly different result.

model file   --SHA-256-->  model hash   which artifact ran
input        --SHA-256-->  input hash   what it received
result file  --SHA-256-->  result hash  what came out

execution record = { model hash, input hash, result hash,
                     runtime, environment, timeline, sources }

• Why an ONNX model gives different resultsWhich differences are expected and how to find the cause of the others.

Reported, observed, verified: keep them apart

The facts in an execution record do not deserve the same trust, and collapsing them hides exactly what an auditor needs to know.

Reported

What the infrastructure says about the run: the device it used, its region, how long the inference took. A claim, recorded as the provider’s.

Observed

What the platform that ran the job measured itself: when it submitted and received the job, end-to-end latency, the bytes and hashes of what it stored.

Verified

What an independent check established, such as an output matching a known expected output for a reference input.

Example: a result questioned six months later

Illustrative example; the model, values and hashes are invented for this page. An inspection model scores a photo and returns “damage probability: 0.87”. Six months later the score is disputed and someone asks which model produced it.

Without an execution record there may only be a database row: a photo ID, 0.87 and perhaps a column that says “model: damage-v3”, a tag that has since been re-pointed twice. With one, the answer is a lookup:

execution_id   exec_01J…
status         succeeded   2026-04-14T09:12:03Z → 09:12:44Z

model          damage-model.onnx  version 3
model_hash     sha256:9f2c…41ab
input          photos/claim-2291/front.jpg
input_hash     sha256:51d0…7c3e
result         damage_probability = 0.87
result_hash    sha256:c47a…09fd

reported   runtime ONNX Runtime 1.x · device CPU · inference 212 ms
observed   environment cloud · queued 2.1 s · total 41 s
verified   none — no expected output exists for this input

Why application logs alone are not enough

Logs answer “what happened in the application?”, and they are good at it. They are not designed to answer “which artifact produced this result?”: they are often sampled and rotated, they usually name a model by its label, and a log line rarely says where the run happened, which runtime executed it, or whether a timing came from the infrastructure or from the application itself.

Logs and execution provenance solve overlapping but different problems. Keep both: logs for operating the system, an execution record for explaining each result.

• AI observability vs inference audit trailThe same distinction for metrics, traces and dashboards.

Why it gets harder across environments

When a model always runs in one place, on one runtime, much of this is implicit. Once the same workload can run in more than one cloud, on edge devices, on different hardware or under different runtimes, “which version ran” is no longer enough: the same artifact can produce slightly different results or timings depending on where it ran, and each environment reports different facts in different formats.

The more heterogeneous the infrastructure, the more a consistent execution record matters — the same fields, the same sources, whatever ran the job.

Implementation checklist

• Identify models by the SHA-256 of the file, computed when it is uploaded or registered; store name and version beside it.
• Create the execution record before the job is submitted, and copy the environment into it — do not look it up later.
• Hash inputs and outputs, or store immutable references to them.
• Record runtime, hardware and region only when someone actually reports them, and say who.
• Keep reported, observed and verified facts in separate fields; never upgrade one to another.
• Store unknown as unknown, not as zero or empty string.
• Keep the record with the result it explains, and make it readable through an API, not only a dashboard.
• Decide separately how the record itself is protected (append-only storage, signing) if third parties must rely on it.

What an execution record does not prove

An execution record is sourced evidence, not a cryptographic proof of execution. It does not prove that a specific chip ran the model; hardware attestation through trusted execution environments and signed quotes is a separate, complementary layer. It does not guarantee that a model can be re-run to the same bits. And it does not make an AI system compliant with any regulation: it supports record-keeping and audit obligations, which is a different thing.

What Auvryn records today

Auvryn is execution infrastructure for ONNX models that keeps an execution record of this kind for every run.

• Upload an ONNX model; it is identified by its SHA-256, and validated before any run.
• Test it in an isolated sandbox, or run it through one execution lifecycle with a history per project.
• Every run records the model version, the input’s SHA-256 when you provide your own input, the environment and whether the run was simulated, and every result artifact with its SHA-256.
• Provenance in three groups — reported by the provider, observed by Auvryn, verified by Auvryn — with each telemetry value labelled by its source. Today the verified group covers an output check against a known expected output for a reference workload.
• The same record through the web app, REST API, TypeScript SDK, CLI and MCP server.

What is available to you

The guided sample is simulated and shows a complete run record in about a minute. Uploading, validating and sandbox-testing your own ONNX model is self-service. Runs on real cloud infrastructure are opened for approved pilots only. Edge execution is not offered to external users, and Auvryn does not run workloads in orbit.

From execution records to execution intelligence

Today

An execution record per run, with provenance and sourced evidence.

Next

Expected versus actual results, and evidence that can be compared across environments.

Future

Execution intelligence: using real execution evidence to help decide where and how a workload should run. Auvryn is building toward this; it does not do it today.

Try it

• Start with the sampleCreate an account and run the guided, simulated sample to see a full run record.
• Upload an ONNX modelAfter the sample, upload your own model, validate it and test it in a sandbox.
• Developer docsREST API, OpenAPI document, SDK, CLI and MCP server.

Frequently asked questions