"Provenance" already means something in software. There are good, established standards for it. So when I say I built a provenance discipline, the fair question is: how is this not a reinvention of work that already exists?
The short answer: the existing standards secure where an artifact came from and whether it was tampered with. Mine secures something they don't touch — whether the claims made about an artifact have outrun what was actually demonstrated. Different layer. They're complementary, not competing.
Here's the map.
C2PA is content provenance for media. It attaches signed manifests to an image, audio file, or video that record where it originated and how it was edited. The question it answers: where did this media come from, and what was done to it? It's the right tool for "is this photo what it claims to be." It says nothing about software claims.
in-toto secures the software supply chain. It produces cryptographic attestations that each step from source to finished artifact was carried out by the authorized party, in the prescribed order. The question it answers: was the pipeline tampered with between the developer and the package I just installed?
SLSA is the supply-chain-levels framework — a graded set of requirements for how strong your build-provenance guarantees are. The question it answers: how confident can I be that this artifact was built from the source it claims, through a build that wasn't subverted?
Notice what all three have in common. They secure the artifact's lineage and integrity — origin, authorship, tamper-evidence. That's real and it matters. But it's a different question from the one that bites you when an LLM is writing the code.
Because an artifact can have flawless supply-chain provenance and still ship documentation describing behavior it doesn't have. SLSA will tell you the build wasn't subverted. It won't tell you the README claims a feature the code only stubs. in-toto will prove the right party ran the right step. It won't prove the test that step "passed" actually exercised anything. The lineage is clean; the claim is inflated. And when the same model writes both the code and the prose about the code, that gap isn't the edge case — it's the default.
That gap is the whole target of the Lindsey Provenance Discipline. It secures the claim-to-evidence relationship:
- A six-state proof-state ledger — every artifact sits at exactly one state (idea, planned, implemented, simulated, artifact-generated, physically-validated), and the ledger is monotonic. You can't describe something "simulated" as "physically validated." The word has to match the state.
- A phase-chain freeze — each phase emits a SHA-256 manifest that inherits the previous phase's hash, so silent drift between what was built and what's described fails loudly instead of slipping through.
So the honest positioning isn't "better than SLSA." It's a layer those standards don't cover. You could — and arguably should — run supply-chain provenance for build integrity and a proof-state ledger for claim integrity. One proves the artifact is what its lineage says. The other proves the story about the artifact never ran ahead of the work.
| Standard | Secures | The question it answers |
|---|---|---|
| C2PA | Media origin + edit history | Where did this media come from? |
| in-toto | Supply-chain step integrity | Was the pipeline tampered with? |
| SLSA | Build-provenance strength | Was this built from the source it claims? |
| Lindsey Provenance Discipline | Claim-to-evidence integrity | Has the description outrun the work? |
I came to this from the trades, not from supply-chain security — and that's probably why it reads as a different layer. On a federal electrical job, the standard isn't "did the right person sign off." It's "does what's behind the wall actually do what the paperwork says." That's a claim-versus-evidence question. I just moved it into code.
→ The discipline is open source, MIT licensed. The methodology paper is on Zenodo.