Provenance

Provenance is verifiable information about software artifacts that describes where, when and how they were produced. That's the SLSA definition, and it's the sense used in supply-chain security.

What it is

Build provenance is the best-known kind. In SLSA it's an in-toto attestation with two main parts: the build definition (the build type, its parameters and the dependencies it resolved) and the run details (which builder ran it). The artifacts it covers are listed as the attestation's subject, by digest.

The same idea applies earlier in the life of a change: who asked for it, what produced it, who reviewed it and which checks it passed.

Why it matters

Provenance turns "we trust our pipeline" into something a third party can check. Signed provenance can be verified without trusting the system that sent it, which matters for audits and for the people who consume your software.

In AI CodeOps

AI CodeOps records the provenance of a change in a signed evidence pack. A pack holds the change record, its sessions (the task, model, provider and tier, and the diff's SHA-256 hash, not the code), agent steps, approvals, policy decisions, findings, test runs, deployments and the audit trail.

The whole pack is signed with Ed25519. Anyone can check a pack on the public verify page, and retired keys still verify older packs. Build provenance stays with your CI.