Decision provenance for AI-generated code is the traceable link from a change to the repository commit, accepted decision IDs, retrieval results and validation evidence used during its creation. It explains which project authority governed the patch without treating the model's narrative as authoritative.
Why model attribution is not enough
Knowing which model generated a patch does not explain why the implementation follows a particular retention rule, API boundary or compatibility promise. Reviewers need project provenance: the human-approved decisions and objective evidence connected to the change.
Capture a minimal evidence chain
Record the base commit, task or issue, cited decision IDs and statuses, and the commands or policy checks executed. Keep retrieval results reproducible where possible. The patch itself remains subject to normal review regardless of whether a human or agent authored it.
- Immutable base and resulting commit identifiers.
- Current decision records cited by stable ID.
- Missing or conflicting authority disclosed explicitly.
- Test and enforcement results with declared scope.
Keep provenance close to the change
A pull-request description or machine-readable attestation can carry the summary while linking to repository records. Avoid storing sensitive prompt transcripts by default; they are noisy, may contain private data and do not substitute for reviewed authority.
Use provenance during review
Reviewers can verify that cited decisions were accepted at the base commit, that no relevant superseding record was omitted and that checks actually cover the changed paths. If the patch requires a new decision, create or supersede that record through review before presenting the implementation as compliant.