The minimum record for AI-written code

On Friday the clock starts. From 11 September 2026, a manufacturer of a product with digital elements has 24 hours from becoming aware of an actively exploited vulnerability to file an early warning, 72 hours to submit a full notification, and 14 days after a corrective measure is available to file a final report. Severe incidents run to the same first two deadlines with a month for the final report. Reports go once, through the CRA Single Reporting Platform, to the CSIRT where the manufacturer has its main establishment, and reach ENISA at the same time.

These are the Cyber Resilience Act’s reporting obligations, and they land more than a year ahead of the rest of the regulation, which applies in full from 11 December 2027. Most planning has been pointed at the later date. The earlier one is the one with a stopwatch attached.

Twenty-four hours does not leave room for archaeology.

What the clock actually asks of you

An early warning is not a full diagnosis. But even a thin first report requires you to know which of your products is affected, and that means locating the change that carries the defect and working out where it shipped. When a person wrote the change, that trail exists as a matter of course: an author, a review, a merge, a release.

When an agent wrote it, most repositories hold none of that. The commit carries a bot identity. The instruction that produced the change has gone. The model version is whatever the team happened to be using that month, which nobody wrote down. Whether a human read the diff, or approved it on a green build, is not recorded anywhere that survives.

None of this matters on an ordinary Tuesday. It matters on the day you have a day.

The research answer is not available to you

There is serious work under way on this. A research vision paper published in August, from a group at William and Mary working under a US National Science Foundation grant, argues that the origins of AI-generated code are opaque to the developers who use it, the organisations that deploy it, and the compliance professionals responsible for its legal and quality standards. Their proposal is explainable provenance: automated, post-hoc traceability linking generated code back to the prompt components, training data instances, global data features and internal model components that caused it. They ground the argument in studies of developers, model users and legal professionals showing that provenance information is a practical necessity current tools do not provide.

That is the right problem. It is also a research programme, spanning causal and interpretability techniques that do not yet exist in deployable form. It is a preprint describing an agenda, not a specification you can adopt. Nothing in it helps you on Friday.

The useful move is to separate two questions that keep getting merged. Why did the model produce this code is a research question. What produced this code, from what, accepted by whom is a bookkeeping question. The second one is answerable now, and it is the one the reporting clock asks.

What the standards already carry, and what they do not

Teams reasonably assume their supply chain tooling has this covered. It does not, and the reason is structural rather than an oversight.

SLSA defines provenance as verifiable information describing where, when and how an artefact was produced. Its predicate records the build type, the external and internal parameters, the resolved dependencies, and the identity of the build platform. Its stated purpose is to let a consumer verify the artefact was built as expected, and to let someone rebuild it. Every one of those fields describes the build.

Authorship of the change that went into the build is not there. It is not there in the adjacent formats either, at the level of a single commit. This was a sensible omission when the author was a person with a git identity and a review trail. It is a gap now.

The minimum record

Four fields, captured per change rather than per pull request.

• Model and version. Written at the point of generation, not reconstructed later. A class of defect frequently tracks back to a single model version, and that query is impossible without the field.
• Instruction and context. Not the transcript. The instruction, the rule files in force, and a digest of each. Months later, when a defect surfaces, the digest is what tells you where else that same context was used.
• The named accepter. A person, recorded separately from the identity that made the commit. Bot commits with the human buried in a trailer are the common failure and they defeat the search.
• Review evidence. Whether somebody read the change, as distinct from what the pipeline reports. A green build is not a review, and this is the field an incident asks for first.

Then the part that gets skipped. Four perfect fields sitting on a pull request still leave you unable to say which shipped product contains the change. Pull-request metadata dies in a squash. Make the unit the commit, carry the record into the build attestation, and join it to the release, because the release is what the regulator will ask about.

No new standard is required

SLSA permits extension fields on any object in the predicate, under a vendor-namespaced naming convention. The specification’s own worked example of such a field concerns code review, which suggests the authors anticipated exactly this kind of addition. A commit trailer written by the agent harness, and one pipeline step that lifts the trailer into the attestation, carries all four values to the artefact without waiting for anybody to ratify anything.

The work is small. The reason it does not get done is that nothing has yet forced the question, and a control with no forcing function stays on the backlog.

The claim, and how it could be wrong

My claim is that within a year, teams shipping software into the EU will keep an authorship record on every change, and that the reporting clock rather than a scheduled audit is what will force it.

I could be wrong about the trigger. It is possible the gap surfaces first in conformity assessment work ahead of December 2027, in a slower and more procedural way, and that teams build the record to satisfy a checklist rather than an incident. I doubt it. An audit gives you notice and a scope. An incident arrives with neither, and it is the unplanned event that exposes which records were only ever written for the auditor.

One caveat in the other direction, because a control that only argues one side is an advert. Recording authorship proves nothing about quality. A logged model version and a named accepter is a search index, not a safety property. It will shorten the worst day. It will not prevent it. The prevention question belongs at the promotion gate, which is a separate control and a separate argument, and it is the one I made in the reviewer ships with the author.

A useful test before Friday. Take the last ten merged changes an agent wrote, and try to answer all five questions from existing artefacts alone: which model and version, from what context, accepted by whom, read by anybody, shipped in which release. No asking the author. If the answers are not there, that is the size of the job, and it is smaller than it looks.

Jason Cruz Falzon is the creator of the Cognitive Delivery Framework and the Cognitive Delivery Index. More at cognitivedelivery.co.uk, or write to jason@cognitivedelivery.co.uk.