In January the Linux kernel asked for the model’s name on every commit an AI tool helped write. In October it stopped asking. The human sign-off line next to it never moved.
The request landed on January 6 in a new process document. A patch developed with an assistant was to carry a trailer, Assisted-by: AGENT_NAME:MODEL_VERSION, and the example line named a Claude model. On August 3 a second commit cut the model out. Its reasoning fits in one sentence: naming the model “provides free advertising to proprietary software companies while adding little or no useful information.” The trailer became Assisted-by: LLM. On October 14 a third commit removed the tag from the process documents, the translations, and checkpatch.
The October message gives the count. Roughly 10% of the 18,533 non-merge commits in 7.3 through -rc7 carried the tag, “while actual LLM use is far more widespread.” So “its absence says nothing about how a patch was made, and for developers who use these tools for almost everything, its presence says little more.” Jonathan Corbet, writing up the Maintainers Summit for LWN, needed six words. “Assisted-by provides no useful signal.”
In September I asked for the model ID to sit beside the actor on every run’s audit line. The kernel tried that at the commit, at a scale I will never get near, and took the field back out within ten months. I read the three commits as a report on my own ask.
The field it kept is the other one. Signed-off-by stayed, and the October commit says so in a sentence of its own: “The rules on the DCO and on the submitter’s responsibility for the patch stay as they are.” The process document still reads “AI agents MUST NOT add Signed-off-by tags.” Only humans can certify the Developer Certificate of Origin.
Put the two trailers side by side and the difference is what happens when each one is missing. A patch without a sign-off doesn’t go in. A maintainer refuses it, and the refusal is the reader. A patch without an Assisted-by tag went in like any other. Checkpatch was the reader for that one, and what it checked was the spelling of the value when the tag was present. It had no way to notice when the tag wasn’t. One field had a step that stopped without it. The other had a format checker.
Last month I wrote that an adoption number isn’t a measurement until someone loses when it’s wrong. A provenance field is the same object with a name in it. The kernel’s model string had no step that failed on a missing value or a wrong one, so by August the model half was free advertising, and by October the rest was noise.
The pipeline case is easier than the kernel’s in one way and no easier in the other. The kernel’s tag was typed by a person, so the 10% was the first problem: coverage. A pipeline writes its own audit line, and the model ID lands on every run for free. Coverage is solved. That leaves the question the kernel answered. Who reads it, and what fails if it’s wrong?
I can name the job for my own ask. It’s what the September post was about. The vendor publishes a retirement date for every model. The model ID on an audit line gets a reader the day a check compares it against that page, fails the run when the string names a model past its date, and reopens the qualification evidence when the string changes. Wired to that, the field has a consequence. Unwired, it’s a string in a log that a format checker approves, which is the kernel’s tag with better coverage.
So, the test. Open your pipeline and name the job that reads the model string off the audit line and fails when it’s missing or stale. If the answer is a regex in the linter, the field will last until someone counts how often anyone looked at it.
The kernel kept the line a person has to sign and dropped the line that named the tool. Both were about who made the patch. Only one of them had someone waiting on it.