Anyone can ship a model. Almost no one can prove how it was built.

A signature proves the file. It doesn’t prove the build.

Model signing is real, and it is a genuine step forward. In 2025 the OpenSSF shipped a Model Signing standard that signs a model’s files with the same proven machinery used to sign software, so anyone can confirm the artifact was not swapped or altered after release.

But signing the file answers one question — is this the model the publisher released? — and leaves the harder one untouched: how was it built, and can I check that myself? A signed model with an unknown history is still a black box. It is just a black box with a seal on it.

The record has a name: an AI bill of materials.

The thing that answers “how was it built” has a name now. Software has carried a bill of materials for years — a list of every component that went into a build — and AI is getting the same discipline. It is called an AI bill of materials, or AI-BOM, and the standards bodies are already here: SPDX 3.0 added support for AI bills of materials, and CycloneDX covers machine-learning components.

STEAV calls the full version model-build lineage. Not provenance, not an audit trail — those describe where a thing came from, or what got logged after the fact. Lineage is the complete, ordered account of the build itself: the data, the code, the weights, the training, the checks, and the sequence they happened in.

How STEAV builds the record.

STEAV’s platform, CID, builds and trains the model inside your own environment — on-premises, air-gapped, or sovereign cloud. The model is built, not rented, and it never leaves your walls.

The record is built in, not bolted on. The build runs as a seven-stage pipeline, and every stage signs what it did — the data it drew on, the training it ran, the validation it passed — with a cryptographic signature.

Each contribution to the model is then written to a tamper-evident ledger — a blockchain, used here in exactly one place: to hold the record of how the model was built, so an outside party can check it. It is there for auditability, not as anything to trade. The result is a signed, ordered, verifiable account of the whole build, produced automatically as a byproduct of building the model the right way — not reconstructed from memory once someone asks.

What the record actually looks like.

Two artifacts come out of a build. The first is the inventory — what went into the model — exported in the formats the standards bodies already defined, so it drops into whatever your supply-chain tooling already reads.

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "claims-triage-v4",
  "creationInfo": { "creators": ["Tool: steav-platform"] },
  "packages": [
    {
      "SPDXID": "SPDXRef-comp-faca7faa0b9a8a92",
      "name": "claims-triage",
      "versionInfo": "4.2.0",
      "supplier": "Northwind Mutual",
      "licenseDeclared": "LicenseRef-Proprietary",
      "checksum": "sha256:9f2c41d8a7b3e05c6d81f4a2938bc7e0…"
    },
    {
      "SPDXID": "SPDXRef-comp-90366299080b6184",
      "name": "claims-history-2019-2025",
      "versionInfo": "2025.11",
      "licenseDeclared": "LicenseRef-Internal",
      "checksum": "sha256:41ab09f2c7d4e8b5a0361f9c2d7e84b3…"
    }
  ]
}

The second is the part an inventory cannot carry: the ordered chain of what happened, each step hashed, the whole thing signed. This is the lineage.

"subject": "model-4.2.0",
"build_type": "steav-cid/federated-training@v1",
"slsa_level": 3,

"chain": [
  { "stage": "data_prep", "type": "data_version",   "name": "claims-history-2019-2025",
    "hash": "sha256:41ab09f2…", "records": "10442", "residency": "in-tenant" },
  { "stage": "data_prep", "type": "code_commit",    "name": "claims-triage/train.py@8f31c2a",
    "hash": "sha256:6b1d3f8e…" },
  { "stage": "train",     "type": "environment",    "name": "cid-trainer:2.4.1-cuda12.4",
    "hash": "sha256:2e7b4a8c…", "air_gapped": "true" },
  { "stage": "aggregate", "type": "training_run",   "name": "federated round 12/12",
    "hash": "sha256:d8c7e044…", "participants": "4", "raw_data_shared": "0 bytes" },
  { "stage": "validate",  "type": "training_run",   "name": "eval + benchmark gate",
    "hash": "sha256:0b3a6c9f…", "eval": "0.947", "threshold": "0.940", "result": "passed" },
  { "stage": "deploy",    "type": "model_artifact", "name": "claims-triage 4.2.0",
    "hash": "sha256:9f2c41d8…", "weights_left_perimeter": "false" }
],

"content_hash": "9ce3200a97768f3acbd4297be8e130f9c6ac819dbd263c980b17005ea5298fcf",
"signature":    "0cf7315e402f8b2176455c7f58ff7ce4049445d6b6a81947cb421a4004b56f50…",
"signed_by":    "4d0ec3a0d03fefff93a9bcce2a24b406d46f44aeff1f7787daedb13caafa402c"

Read the chain from the bottom and you get the question answered in order: this model came from that gate, which came from that training run, which ran in that environment, on that code, over that data. Every line hashed. The whole thing signed.

Independently verifiable, not custodial.

Here is the distinction that carries the whole argument. Most “proof” in AI is custodial: the vendor shows you a dashboard, and you can trust it exactly as much as you trust the vendor’s platform. Take the platform away and the proof goes with it.

STEAV’s record is independently verifiable. Because every stage is signed and every contribution is anchored to a tamper-evident ledger, an outside auditor can check the record without trusting STEAV — or anyone else. That is the difference between evidence you own and evidence you are shown.

It is also what the standards are converging on. The EU AI Act requires technical documentation of how a high-risk system was built; the NIST AI Risk Management Framework and ISO/IEC 42001 ask for the same kind of evidence.

The standards agree on what is needed. Shipping it as a signed record you can verify yourself is the part almost no one does.

Why this matters now.

If you cannot show how your model was built, you are asking everyone downstream — your regulator, your customer, your own board — to take your word for it. For a while, that was the only option on the table. It is not anymore.

The teams who will be asked the hardest questions about their AI are the ones who should stop relying on anyone’s word, including their own. Model-build lineage is how you stop.