Every couple of decades, software discovers it cannot prove where its own code came from, and every time the fix turns out to be a line of text rather than a technology. That is happening again right now, and the pattern is not confined to engineering — a recent examination of how technology companies are rebuilding trust after the era of automated communication describes reporters who now insist on primary documents before they will print a number, which is the same instinct a maintainer has when a stranger sends a patch with no reproducer. The difference is that one community has already shipped a working answer, in reStructuredText, with no launch event and no vendor behind it. It is worth reading closely, because almost every corporate AI policy currently being drafted gets the same problem wrong.
The Last Time Nobody Could Prove Anything
In 2003, SCO began asserting that proprietary UNIX code had found its way into Linux. The claim was legally weak and eventually collapsed, but it was expensive precisely because it was hard to refute. The kernel had changelogs, yes, but no systematic record of the path a patch travelled: who wrote it, who passed it along, who asserted the right to contribute it. Absence of documentation is not evidence of theft, but it is an excellent place to stand while you allege one.
On 23 May 2004, Torvalds sent a request for discussion about explicitly documenting patch submission. Within about a week, the sign-off procedure was in the tree. The solution was not a code scanner, not an audit firm, not a contributor licence agreement with a signature page. It was a trailer at the bottom of a commit message — a short, human-made certification, permanently attached, trivially greppable, and cheap enough that nobody could argue about the overhead. Twenty-two years later it is still load-bearing infrastructure across an enormous slice of open source.
Keep that shape in mind, because it repeats.
Two Trailers Doing Two Different Jobs
In December 2025, following consensus reached at that year's Maintainers Summit, the kernel merged an official policy on machine assistance. The kernel's AI coding assistants documentation is short, and its central move is a separation most organisations never make.
Agents are forbidden from adding a Signed-off-by line. Only a human can certify the Developer Certificate of Origin, and the human submitter carries the whole load: reviewing generated code, confirming licence compatibility, signing off, and owning the result. Attribution goes somewhere else entirely, into a new trailer:
Assisted-by: LLM coccinelle sparse
The format is Assisted-by: LLM followed by optional specialised analysis tools — coccinelle, sparse, smatch, clang-tidy. Ordinary tooling like git, gcc, make and your editor is explicitly excluded, because listing it would be noise.
Notice what the trailer does not contain: a vendor, a product, a model string. That reads like an oversight until you think about maintenance. Model identifiers churn every few months, and naming a vendor invites an argument about which brand to blame instead of a conversation about whether the patch is correct. The trailer records that a class of tool participated. That is the fact a reviewer can actually use.
The deeper design decision is the split itself. Assisted-by is descriptive: it says how the change came to exist. Signed-off-by is a certification: it says a named person accepts responsibility. Most AI policies being written this year fuse these into a single disclosure checkbox, which produces a field that is simultaneously legally meaningless and operationally useless. Provenance and liability are different data types. Store them separately.
The Constraint Is Bandwidth, Not Authenticity
The kernel's companion document on tool-generated content opens by naming the real problem rather than moralising about it: reviewer and maintainer bandwidth is a scarce resource. That single framing does enormous work. Once the question is resource allocation rather than authenticity, the rules stop being philosophy and become scheduling.
It also lets the document draw a boundary that almost everyone else fumbles. "AI-assisted" is a worthless category if it stretches to cover autocomplete, so the guidelines explicitly exclude trivial tool use: spelling and grammar cleanups, identifier completion and boilerplate, mechanical renames, running a formatter. What falls in scope is any case where a meaningful amount of the contribution was not written by a person in the sign-off chain — a generated function, a machine-drafted file cleaned up afterwards, a changelog produced by handing the patch to a model, even a changelog translated from another language. If a tool found the bug, that belongs in the changelog too, partly as credit and partly so other developers learn the tool exists. When it is ambiguous, the instruction is to disclose.
Proportional Scrutiny Instead of a Ban
Several projects responded to the same pressure by banning generated contributions outright. The kernel did something harder and more durable: it made scrutiny scale with the proportion of generated content, and it published the maintainer's menu of legitimate responses. A maintainer may treat the patch like any other, reject it outright, demand extra testing, review it at lower priority than human-written work, ask the contributor to explain how the model was trained, ask them to demonstrate they understand the code, or — my favourite — respond with a better prompt instead of a code suggestion.
That last option quietly promotes the prompt to a reviewable artifact. And the disclosure the guidelines request is not a checkbox but a description: which tools, what input those tools received (the Coccinelle script itself, for instance), the prompts or a summary of them for longer sessions, which portions of the change were affected, and how the result was tested. A reviewer can act on that. A checkbox tells them nothing except that someone read a policy.
The enforcement clause is equally plain: you are expected to understand and defend everything you submit, and if you cannot, maintainers may reject the series without detailed review. Cost lands on the claimant, which is the only arrangement that has ever survived contact with volume.
The Procedure Reads Like an Interface Contract
The bug-fixing procedure attached to the policy is nine mandatory steps, and it is the most quietly radical part of the document. Read the process documentation in full rather than keyword-searching fragments of it. Record the commit ID. For any non-trivial bug, build a reproducer, and abandon the report if the bug evaporates under one. Write the fix — declared explicitly not optional, on the reasoning that anything capable of finding a bug is capable of fixing it, and that a fix written in the same session inherits the reasoning context. Build it, run checkpatch, discard fixes that fail. Find maintainers with get_maintainer.pl. Consult the threat model to classify the issue, and leave the classification to a human. Never send anything yourself.
Then step eight, which carries more weight than the other eight combined: state explicitly what could not be done. Untested, unbuilt, unreproduced — say so. The document is blunt about why, noting how much time maintainers currently lose to unverified reports and untested fixes.
This inverts the default. Normally a reviewer must discover what is missing from a submission. Here the submitter is contractually required to enumerate their own gaps. Declared uncertainty is the single cheapest trust signal in existence, and it is nearly impossible to fake convincingly, because fabrications never volunteer their own limits.
Regulators Arrived at the Same Primitive
While the kernel worked this out from first principles, Brussels arrived somewhere structurally identical from the opposite direction. Article 50 of the AI Act applies from 2 August 2026, and the European Commission's guidelines on AI transparency obligations were finalised on 20 July 2026 alongside a code of practice on marking generated content. Providers of systems producing synthetic audio, image, video or text must mark outputs in a machine-readable format that makes them detectable as generated. People must be told when they are interacting with a system directly. Systems already on the market got until 2 December 2026 for the marking requirement; content produced before the deadline needs no retroactive labelling. Infringements carry fines up to €15 million or 3% of worldwide turnover.
The scope is different — Article 50 binds providers and deployers of systems, not your commit messages — but the mechanism is the same, and it is the interesting part. Both regimes mark at the moment of generation rather than guessing afterwards with a classifier. Detection is an arms race you lose slowly and then all at once. Declaration is a protocol, and protocols compose.
Porting This Into a Repository You Actually Own
The kernel's version is tuned for an email-based workflow with strong maintainer authority, but the primitives transfer cleanly to any project with a review process.
- Split provenance from accountability. One trailer describes how the change was produced; a different, human-only signature accepts responsibility for it. Never collapse them into one field.
- Write your out-of-scope list before your in-scope list. If a policy technically covers autocomplete, nobody will follow it, and selective non-compliance corrodes the whole thing.
- Ask for prompts and inputs, not a yes/no flag. Store what a reviewer would need to reproduce the generation, not merely the fact that generation occurred.
- Require a reproducer and require a gap statement. "I could not test this on hardware" belongs in the pull request body, not in a reviewer's discovery process three days later.
- State the scrutiny curve openly. Contributors should know in advance that a mostly generated patch gets slower, harder review — that is information, not punishment.
- Keep it greppable and plain-text. The value compounds only if you can query five years of history without a bespoke tool.
What It Does Not Fix
Worth being honest about the limits, because the enthusiasm around provenance metadata is starting to outrun its capabilities. These trailers are self-reported and cryptographically unverified; nothing stops someone omitting one. They function in the kernel because there is a named maintainer with a reputation, a review culture with teeth, and a credible threat of having your series ignored. Bolt the same trailers onto a repository where nobody reviews anything and you have manufactured a compliance artifact, not trust.
But that is exactly the point, and it is why this pattern keeps recurring. The 2004 sign-off did not verify anything either. It created a durable, attributable record of a human being making a claim, and it made that claim cheap to record and expensive to walk back. Twenty-two years later, faced with a machine that can produce infinite plausible text, the kernel's answer is a second line in the same commit message, written by the same accountable person.
Not glamorous. Still the only thing anybody has found that works.
Top comments (0)