Should AI-generated patches carry a reproducibility manifest?

I’m using coding agents often enough that I’m starting to think every generated change needs a machine-readable provenance manifest. Not a transcript dumped into the repository, but a compact record of model and tool versions, retrieved sources, commands run, dependency changes, and the environment needed to rebuild or investigate it. Existing provenance approaches such as SLSA and in-toto point in this direction.

A green test suite and clean diff only tell us which checks passed. They don’t necessarily preserve the context needed to explain an odd dependency, reproduce a bug six months later, or investigate a security incident. The counterargument is fair: mandatory metadata creates noise, may expose proprietary prompts or code, and is disproportionate for a tiny project. I’d favor redaction and graduated detail, but where should the line be: required by code-hosting platforms, optional for trusted repositories, or generated only for production-bound changes?

The distinction I’d make is between provenance and prompt history. The former is useful audit metadata; the latter may contain sensitive material and should not be treated as automatically shareable. A schema that requires hashes, versions, inputs, and commands while permitting redacted context seems more defensible than preserving every conversation.

For incident response, “the tests passed” is a weak receipt. I care about what tools had access to, which sources were retrieved, and what dependencies changed. I would not require raw prompts, though. Those can contain secrets or proprietary code and are a new data-exposure surface.

For a two-person project, making every throwaway patch produce a formal artifact sounds like process cosplay. I’d keep the manifest lightweight and trigger it on release branches, published packages, or changes touching security-sensitive code. Otherwise people will disable the whole thing to save time.

Redaction is not a complete answer if the manifest itself proves too much about the repository or workflow. I’d separate public attestations from restricted internal records, with stable identifiers and hashes in the public part. “Machine-readable” should not quietly become “machine-readable by everyone.”

The rebuild environment is the field most likely to be hand-waved. A model version and command log are useful, but without pinned dependencies and a meaningful environment description, reproducibility remains aspirational. I’d rather have a small honest manifest than a comprehensive one full of unverifiable claims.

Adoption probably depends on whether this feels like a developer aid or compliance paperwork. If the agent can generate a concise manifest automatically and show what will be shared before commit, teams may accept it. Hide it behind a policy dashboard and it becomes another box people click through.

I’m wary of requiring platforms to understand every workflow. Put the format in the repository and let projects decide when it is mandatory. A platform can verify or display it, but making the host enforce it sounds like a good way to create elaborate exceptions.

Production-bound is the sensible default for enforcement. Released binaries, packages, and containers have a clear accountability boundary; individual source edits usually do not. Trusted repositories can opt into stricter recording when their risk model justifies the operational cost.

One concern: provenance can create a false sense of certainty. A perfectly recorded agent run does not establish that the generated code is safe, and an unrecorded manual fix can still be the real cause of a defect. I support manifests as investigative evidence, not as a substitute for review.

I’d define tiers: local-only metadata for experiments, retained manifests for merges, and signed attestations for production artifacts. The policy should say what gets retained, who can read it, and how long. Without those operational details, “just record everything” will eventually collide with storage, privacy, and support reality.