Track AI-generated code provenance and review

The useful question about AI-generated code is often not “Can a detector recognize it?” It is “Can we establish where this change came from, what ran, and why we accepted it?”

Code may mix human edits, model suggestions, templates, and formatting tools. A style-based label cannot replace that history. In Polyaxon, make provenance an explicit output of the generation and review workflow.

Capture origin when the change is created

A coding assistant that proposes a data-validation function should record the base commit, task identifier, generator configuration, and resulting patch. Later edits should produce new revisions rather than overwrite the original proposal.

Keep source attribution separate from quality. Human-written code can be unsafe, and generated code can be correct. Neither origin is a reason to skip the same functional and security review required for other changes.

A useful provenance record contains:

Store sensitive prompt content separately, under an appropriate retention policy. A public task description or digest may be sufficient for routine review.

Bind review evidence to exact bytes

The following example runs inside a trusted Polyaxon job with tracking configured. It assumes candidate.patch has already been collected from the generation workspace.

import hashlib
from pathlib import Path

from polyaxon import tracking

patch = Path("candidate.patch").read_bytes()
tracking.init()
tracking.log_outputs(
    candidate_sha256=hashlib.sha256(patch).hexdigest(),
    candidate_bytes=len(patch),
)

This records an identifier, not the patch itself. Persist the patch through the artifact workflow and associate the evaluator with that same digest.

A digest is also not a signature or an immutable audit log. Its value comes from comparing the evaluated artifact with the artifact actually released. If tamper-resistant retention is required, configure it in the evidence storage and signing systems.

Evaluate behavior without guessing authorship

Run an approved evaluation component against the candidate. Include contract checks, dependency review, sensitive-data handling, and expected failure behavior. The evaluator should be maintained separately from the generated code.

For a feature-engineering change, compare outputs on fixed fixtures and inspect how missing or malformed values are handled. For a tool wrapper, verify authorization failures and output limits. A successful process exit is only one piece of evidence.

Use run comparisons to inspect evaluation results across proposals. Compare like-for-like datasets and evaluator revisions; otherwise the ranking can reflect changed conditions.

Preserve the chain through release

Before promotion, verify that the patch being merged matches the reviewed digest and still applies to the intended base. Reevaluate after a rebase or material edit.

Package approved code in a reviewed image and versioned Polyaxon component. Record those versions in later execution runs so an incident can be traced back to the accepted implementation.

Provenance works best when collected automatically at each handoff. It gives the team stronger evidence than a retrospective guess about whether a particular function “looks AI-generated.”