Byte-Identical Weights and Model Weight Provenance
Byte-identical weight provenance means the model weights running inside your perimeter are proven to match a specific, published open-weight artifact byte for byte. You confirm it by hashing the deployed weight files on your own hardware and comparing that hash to the public artifact's hash. A match ties the running model to a known, named release. It proves which artifact is running. It does not claim the model is clean or free of hidden behavior — that is a separate question, answered by separate controls.
Provenance is the first thing a serious buyer checks, because everything else you might claim about a model depends on knowing exactly which model you have.
What a byte-level match actually establishes
Open-weight models ship as a set of weight files with a published cryptographic hash. "Byte-identical" means every byte of the weights loaded into memory on your hardware matches that published artifact — not a fine-tune of it, not a re-quantized copy, not "basically the same version," but the exact bytes.
The check is mechanical and reproducible. You compute a hash (for example SHA-256) over the deployed weight files and compare it to the hash of the public release. If they match, the running model is provably that artifact. If a single byte differs — a swapped layer, an injected adapter, a silent re-pack — the hashes diverge and the check fails. There is no partial credit and no room for interpretation.
That is what ties the running system to a known, published, inspectable release. Anyone in the community can study the public artifact; provenance is the bridge that says the thing you can study is the thing you are actually running.
What it proves — and what it does not
This distinction is the whole point, and getting it wrong is how vendors mislead buyers. We are precise about it.
Provenance proves
- The running weights are the exact public artifact you named.
- No silent substitution, patch, or modified build slipped in between download and deployment.
- The model version can be stated precisely and re-verified at any time.
- You can confirm it yourself, on your hardware, without trusting anyone's attestation.
Provenance does not prove
- That the model is clean, safe, or backdoor-free.
- That the public artifact has no hidden or latent behavior.
- Anything about the training data or the model's intentions.
- That the model will never produce a harmful output.
Our honest posture. We do not scan the model and we do not claim the model is clean. A public open-weight artifact can still carry behavior no one has characterized. What provenance gives you is certainty about which artifact you are running. Trustworthiness of that artifact is addressed by the other controls — separately, and just as verifiably. Evidence, not our word.
How you verify it yourself
Provenance is meaningful only if the customer can check it independently. On Hyfstele the verification runs on the customer's own hardware, inside the air-gapped perimeter:
artifact = <org>/<model> —> published_hash = sha256(public release)
# 2. hash the weight files actually loaded on this box
deployed_hash = sha256(weights on customer hardware)
# 3. compare — this is the whole proof
deployed_hash == published_hash ? —> PROVENANCE ESTABLISHED
No network call is required, and none is permitted — the environment has no route to the internet. You are comparing bytes on your own disk to a hash you already hold. That is why the result is evidence rather than an assurance.
Provenance as one of four verifiable controls
Hyfstele runs open-weight models inside your own perimeter, air-gapped, with four independently verifiable controls. Provenance is the first. Each is checkable on the customer's hardware; none of them asks you to trust a vendor claim.
The controls are deliberately independent. Provenance says which model. Enumeration characterizes what it can do. No egress bounds where anything can go. The audit chain records what actually happened. A buyer verifies each one on its own terms; no control leans on another's assurances.
Why it matters for diligence
When a regulated buyer evaluates an AI system, the reviewer's first job is to establish the facts of what is deployed. "The vendor says it's Llama-3-70B" is not a fact a reviewer can sign off on. "I recomputed the hash of the weights on our own hardware and it matches the published artifact" is.
Byte-identical provenance converts a claim into a check. It lets security, quality, and compliance reviewers independently confirm what is running instead of accepting an attestation. That shortens diligence, survives audits, and holds up when someone challenges it a year later — because the check is reproducible on demand.
Connection to regulatory expectations
Frameworks such as 21 CFR Part 11 and broader GxP practice turn on knowing exactly which validated system version is in use and being able to demonstrate it under change control. A model's weights are the substance of that version. A verifiable byte-level identity gives you a precise, reproducible answer to "which version is running" — the kind of evidence that supports validation records, version control, and data-residency posture rather than resting on a vendor's say-so.
In practice. Hyfstele's pharmaceutical MLR (Medical, Legal, Regulatory) assist at mlr.hyfstele.com runs on this footing. The doctrine is "It flags. You decide." — Flag → Judge → Prove, with no LLM inside the flag decision plane. Provenance is what lets a reviewer state precisely which model produced a given flag, and prove it later.
See provenance verified on your own hardware
The honest version of secure AI for regulated work: open-weight models inside your perimeter, four controls you check yourself. No "trust us." Book a walkthrough or try the live MLR demo.
Talk to us Open the MLR demoFrequently asked questions
What are byte-identical weights?
Byte-identical weights means the model weight files running on your hardware match a specific published open-weight artifact byte for byte, with no difference at all. You verify it by computing a cryptographic hash (for example SHA-256) of the deployed weight files and confirming it matches the hash of the public artifact.
If a single byte differs, the hashes differ and the check fails. There is no partial match.
What does provenance prove, and what does it not prove?
It proves the running model is the exact public artifact you named — not a silently swapped or modified build. It does not prove the model is clean, safe, or free of hidden behavior.
Provenance answers "which artifact is running," not "is that artifact trustworthy." Those are separate questions, handled by separate controls.
Why can't I just take the vendor's word for it?
In regulated diligence, vendor word is not evidence. Byte-identical provenance lets you recompute the hash of what is actually running on your own hardware and compare it to the public artifact yourself. You confirm the fact rather than trusting an attestation you cannot check.
How does provenance relate to 21 CFR Part 11 and GxP?
Part 11 and GxP expectations require knowing exactly which validated system version is in use and being able to demonstrate it. A verifiable byte-level identity for the model weights gives you a precise, reproducible answer to "which version is running," supporting version control and change-control records.
Is provenance the only control Hyfstele offers?
No. Provenance is one of four independently verifiable controls, each checkable on your own hardware: (1) weights proven byte-identical to the public artifact, (2) dormant/latent capacity enumerated, (3) no egress — no route to the internet and no name to resolve, and (4) every inference call anchored to a tamper-evident audit chain signed with post-quantum cryptography (ML-DSA).