What should AI-code provenance actually record?

As I review more AI-assisted pull requests, I’m increasingly unsure whether “AI was involved” is useful metadata or just another checkbox. I’d rather see machine-readable provenance that records the tool and model version, affected commit range, whether code was generated or transformed, checks run, and the human approver. Prompt hashes could preserve linkage without publishing proprietary prompts.

For example: an engineer accepts an AI-generated parser patch, logs the model and commit range in a restricted JSON record, runs tests and license scans, then signs the commit. A release attestation can link the artifact back to that commit. That helps security and incident response, but detailed logs may expose workflows or create an “AI-written” stigma. They must not become an excuse to move responsibility from the reviewer.

I’m leaning toward a minimal public indicator and restricted detail, not a universal mandate. Maintainers, developers, and security engineers: disagree, share existing tooling, or propose a better standard.

I’d separate provenance from trust. A signed commit proves who signed it; it does not prove the code is safe. The useful record is the review boundary: what changed, what checks ran, and who accepted the risk. AI metadata is one input, not a verdict.

Restricted logs sound right, but “restricted” needs a real access policy. Prompts can contain customer data, architecture details, or credentials pasted by mistake. I’d keep public metadata to an opaque record ID, tool class, and commit range, with the sensitive material under retention controls.

SLSA already gives a reasonable vocabulary for provenance describing where, when, and how software was produced, including source-change processes. Its attestation formats are recommendations, not a mandate. I’d extend that model rather than create an AI-only label with unclear semantics.

The concrete workflow is workable, but I’d make the log generated by the development system, not typed by the engineer after the fact. Manual provenance will drift immediately. Also record “suggestion only” versus accepted output; treating those as equivalent will make the data noisy.

I’m less worried about stigma than accountability theater. A repository can have immaculate provenance and still merge an obviously bad patch. Mandatory metadata may help audits, but only if the policy says what reviewers must do with it. Otherwise it is paperwork with cryptographic decoration.

Start with a trailer or sidecar containing tool, model version, commit range, and reviewer, then see what incident investigations actually use. Don’t put private prompts in Git history. If nobody can name a decision this data improves, the standard is probably premature.