Change provenance and risk routing
An “AI-authored” label is useful for adoption analysis, but it is a weak proxy for change risk. Human-written changes can be dangerous; AI-assisted changes can be trivial. Route review using provenance that matters: accepted intent, systems and data touched, reversibility, evidence, and named approvals. Record AI assistance when useful, but never let authorship replace technical risk classification.
Q11 · Quality gates Max-score evidence: structured change provenance, risk-based gates, retained authorship metadata for measurement, and named authority for consequential decisions.
Use a change manifest
Section titled “Use a change manifest”Add a PR template or machine-readable manifest that captures the decision context:
intent: "Link to accepted intent.md"systems: ["billing-api"]data_classes: ["customer-contact"]reversibility: "feature flag + documented rollback"risk: "high"evidence: - "npm test" - "migration dry-run artifact"ai_assistance: used: true tools: ["Codex"]approvals_required: ["billing-owner", "security"]The exact fields may differ, but they must be reviewable and auditable. Derive risk from code paths, data class, blast radius, external effects, and rollback difficulty—not from the model name or percentage of generated lines.
Route the manifest into controls
Section titled “Route the manifest into controls”| Signal | Example response |
|---|---|
| Sensitive data | privacy/security review and scoped test data |
| Migration or destructive operation | dry run, backup check, tested rollback, production approval |
| Public contract | compatibility tests and consumer review |
| Hard-to-reverse behavior | staged rollout and observation window |
| Missing evidence | block advancement regardless of author |
Use the same classification for human-only, AI-assisted, and agent-produced changes. An optional label can support measurement or incident analysis, but it must not become the sole gate.
Prompts for provenance review
Section titled “Prompts for provenance review”From the accepted intent and diff, propose values for systems, data classes, external effects, reversibility, and evidence. Mark unknowns explicitly. Do not infer low risk from the size or authorship of the change.Audit this change manifest against the diff. Identify omitted systems, data, migrations, public contracts, or irreversible effects. Cite files and lines for every correction.Given this risk classification and repository policy, list the required deterministic checks and named human approvals. Do not create approval on anyone's behalf.Acceptance evidence
Section titled “Acceptance evidence”- The manifest is generated or validated from the actual diff, then reviewed by the change owner.
- Unknown or conflicting fields fail explicitly instead of defaulting to low risk.
- Gate policy is versioned and tested with low-, medium-, high-, and forbidden-change fixtures.
- AI-assistance metadata is used for measurement or audit, not as proof of safety or danger.
- The PR and release records preserve who accepted intent, merge, and production exposure.
Failure pattern: authorship as risk
Section titled “Failure pattern: authorship as risk”Mandatory extra review for every AI-assisted change creates noise and invites people to hide the label; relaxed review for “human” code creates a blind spot. Keep provenance, but route on impact and reversibility. If authorship correlates with defects in your measured data, treat it as one input and revisit the evidence regularly.
Continue with review policy
Section titled “Continue with review policy”Connect the manifest to Gates and guardrails and the evidence-producing Team PR review workflow.