There is no provenance standard for generated code

Here is a gap I find genuinely striking, and it is barely discussed outside compliance circles.

For generated images there is an established approach to provenance. Machine-readable marks, content credentials, watermarking: contested, imperfect, easily stripped by a determined person, and nonetheless real enough that you can point at a format and say what it asserts.

For generated code there is no documented equivalent. A function written by an agent, committed, reviewed and merged carries nothing that distinguishes it from one a person typed. With something on the order of 41 percent of production code now agent-generated, that is a large hole in the middle of the industry.

My position is that the hole is real, and that the obvious fix is the wrong one. Marking the code is a dead end. Provenance for software attaches to the change, not to the artifact, and teams should stop waiting for a standard that would have to solve an unsolvable problem.

Why marking the code cannot work

Images are terminal artifacts. A JPEG is delivered, viewed and largely left alone. Its bytes at the point of consumption are close to its bytes at the point of creation, which is what makes an embedded mark meaningful.

Source code is the opposite of terminal. It is continuously rewritten by processes that are indifferent to anything you embedded in it.

A comment marking a block as generated survives until the first formatter run, the first refactor that extracts a method, the first rename, the first merge conflict resolved by taking the other side. Move a function to a new file and the mark either travels with something nobody tracks or is silently dropped. Split a generated function in half and mark both halves, and now you have two claims about a lineage that no longer exists. Have a person rewrite two lines of a generated block: what is the artifact now, and who would decide?

There is also a second-order problem that makes in-file marking actively harmful. If the mark lives in the file, the mark can be written by anything that can write the file, including the agent. Self-asserted provenance in a mutable artifact is not evidence, it is a comment.

Marking the artifact

• Destroyed by formatters, refactors and merges
• Ambiguous once a human edits part of it
• Writable by whatever wrote the file
• Requires a global format nobody has agreed
• Says nothing about criteria or authority

Recording the change

• Immutable once the commit exists
• Already has boundaries, identity and time
• Recorded by the forge, not by the author
• Works with conventions you can adopt today
• Carries intent, verification and approval

The change is the right unit

A commit has properties an artifact does not. It is bounded, it is timestamped, it has an identity attached by a system outside the author’s control, and crucially it is immutable in the way that matters: rewriting history is possible but detectable and rare, whereas rewriting a file is the entire job.

More importantly, a change can carry the things anybody actually wants to know. “This line was generated” is close to useless on its own. The questions that get asked are: what was this change meant to achieve, what generated it and under what direction, what checked it, and who accepted the result. All of those are properties of an event, not of a text.

So a workable convention looks like a structured record attached at commit or merge time, naming the generation involved, the criteria the change was built against, the verification that ran, and the human who approved. No new file format, no global agreement required, and nothing that a reformatting pass can erase.

Why nobody will standardise this soon

It is worth being honest about the incentives, because “the industry should agree a format” is the sort of sentence that gets written for a decade without anything happening.

Image provenance had a coalition with a shared and urgent interest: platforms facing a flood of synthetic media, and model providers facing regulatory pressure over exactly that. Both benefit from a mark that survives distribution.

Generated code has no equivalent coalition. Model providers gain nothing from making their output identifiable inside a customer’s private repository, and arguably lose something. Forges have no obvious commercial reason to lead. Enterprises want the record but individually cannot create a standard. And unlike synthetic media, there is no public-facing harm loud enough to force the issue: bad generated code causes incidents, and incidents are handled privately.

That leaves a gap that is not waiting on legislators. It is waiting on someone with the incentive to spend the coordination cost, and at the moment nobody has it.

ImagesTerminal artifact, distributed publicly, coalition of platforms and providers with aligned interests.

CodeContinuously rewritten, held privately, no party benefits enough to bear the coordination cost.

ConsequenceProvenance for code will be conventional and local before it is ever standard.

Adopt a local convention now

The argument for acting before a standard exists is simple: provenance cannot be backfilled. Whatever you fail to record at merge time is gone, and no future format will recover it. A team that starts a convention now has a record from now. A team that waits has a record starting from whenever the waiting ends.

The convention does not need to be sophisticated. It needs to be automatic, emitted by the pipeline rather than by the person, stable enough to be queried a year later, and written where the agent cannot edit it. That is a week of plumbing, not a programme.

I will note that our own product produces this kind of change-level record, and immediately note that it is not a standard either, and that no vendor’s format will become one by being good. If a standard emerges it will come from a forge or a coalition, not from us. What a local convention buys you is not interoperability. It is having the data at all.

Where this breaks down

A local convention is not portable, and that is a real cost. If your team moves between forges or your vendor changes, your provenance record may not travel. A standard would solve that, and my argument amounts to accepting fragmentation in exchange for having something. Somebody could reasonably prefer to wait.

Change-level records lose granularity. For a commit containing both generated and hand-written work, “this change involved generation” is coarser than a per-line mark would be, and there are questions where line-level attribution genuinely matters, particularly around licensing. I do not have a good answer for those.

Marking may be mandated anyway. Transparency obligations require generated content to carry machine-readable marks, and I have argued the mechanism for code is impractical. If a regulator or a court reads that requirement as covering source, impracticality will not be a defence, and the industry will have to build something bad rather than nothing.

And I may be wrong about the incentives. A single large forge shipping a change-level provenance field by default would create a de facto standard in a year, without any coalition. That is a plausible path and it would make most of this article moot.

The takeaway

The provenance gap for generated code is real and it is not going to close on its own, because the object being marked is continuously rewritten and no party has enough incentive to bear the coordination cost.

Marking the code is the wrong shape of fix. Formatters, refactors and merges destroy embedded marks, partial human edits make them ambiguous, and anything that can write the file can write the mark. The unit that survives is the change, and the change also happens to carry the things people actually ask about: intent, direction, verification, authority.

If you take one thing into next week: pick a file in your repository that you know was largely generated, and try to establish from your existing records that it was. The point at which you give up is the size of the gap.