High-Risk Code Review Escalation Rules

Purpose

Use these rules when an AI coding assistant, maintainer bot, or human reviewer is asked to approve a change that could affect production safety, user data, security boundaries, public APIs, dependency trust, or release automation.

The goal is not to slow every PR. The goal is to identify the small set of changes that need a named owner, fresher evidence, and an explicit merge decision before they become production behavior.

Escalation Triggers

Escalate a review when the change touches any of these areas.

1. Authentication or authorization. Login, sessions, tokens, cookies, OAuth, SSO, permissions, tenant isolation, admin checks, or access policy.
2. Secrets and credentials. Secret storage, environment variables, key rotation, CI secrets, cloud credentials, webhook tokens, signing keys, or generated config that can reveal secrets.
3. Production infrastructure. Terraform, Kubernetes, network policy, DNS, storage buckets, queues, databases, caches, deployment workflows, or autoscaling.
4. Data handling. PII, payment data, customer records, logs, analytics, prompts, embeddings, retention, deletion, exports, backups, or migrations.
5. Dependency and build trust. Package updates, lockfiles, generated clients, build scripts, provenance, artifact signing, publish workflows, or install-time scripts.
6. Public contracts. API schemas, GraphQL types, event payloads, database migrations, CLI flags, file formats, webhooks, or backward compatibility.
7. Release gates. Branch protection, required checks, CI bypasses, deployment approvals, feature flags, rollback tooling, or incident response paths.

If the risk class is unclear, escalate for classification before reviewing style, naming, or convenience improvements.

Required Evidence

A high-risk review should have enough evidence for another reviewer to understand the decision later.

• The affected owner or domain reviewer is named.
• Required checks are current for the reviewed head commit.
• Tests cover the risky behavior, not only formatting or snapshots.
• Security-sensitive diffs are reviewed from source, not only from summaries.
• Generated files are tied to a reviewed source input and regeneration command.
• Rollback, disablement, migration backout, or incident response path is stated.
• Public API, schema, or data model changes name compatibility expectations.
• Privacy-sensitive examples, logs, and screenshots are redacted or avoided.

Do not approve a high-risk PR when the evidence is stale, detached from the current head commit, or hidden in private context that future maintainers cannot audit.

Reviewer Rules

• Start with risk classification, then review correctness, tests, and design.
• Ask who owns the affected system before approving cross-boundary changes.
• Require a second reviewer for auth, data, infrastructure, release, and dependency trust changes.
• Treat CI configuration changes as production changes when they can weaken required checks, publish artifacts, expose secrets, or deploy code.
• Compare generated code, lockfiles, schema outputs, and migrations against the source change that produced them.
• Verify that branch protection or required checks still apply to the merge path.
• Separate "needs author fix" from "needs owner escalation" so risky PRs do not pass because all inline comments were resolved.

Merge Blockers

Block merge until resolved when:

• the PR changes auth, data, infrastructure, dependencies, or release gates without owner review;
• required checks are skipped, stale, failing, or not tied to the current head;
• a generated artifact changed but the source file, generator, or command is missing;
• a migration, deployment, or feature flag has no rollback or disablement path;
• a security or privacy claim is based on AI summary text rather than source evidence;
• logs, screenshots, fixtures, prompts, or review notes reveal secrets or private user data;
• the PR weakens branch protection, bypasses CI, or changes publish credentials without explicit release-owner approval.

Review Checklist

• {"task": "Risk class named", "description": "The reviewer classified whether the PR touches security, data, infrastructure, dependencies, contracts, or release gates"}
• {"task": "Owner review present", "description": "A named owner or domain reviewer approved the affected risk area"}
• {"task": "Checks are fresh", "description": "Required checks ran on the reviewed head commit and cover the risky behavior"}
• {"task": "Rollback is clear", "description": "The PR explains rollback, disablement, backout, or incident response for production-facing changes"}
• {"task": "Generated output traced", "description": "Generated code, lockfiles, schemas, clients, or migrations are tied to reviewed source inputs"}
• {"task": "Privacy notes safe", "description": "Review notes avoid secrets, raw customer data, exploit details, and private operational context"}

AI Review Rules

AI reviewers can help find risk signals, but they should not be the final authority for high-risk merge decisions.

• Ask the assistant to classify touched risk areas before asking for style feedback.
• Require file paths, line references, and check names for every blocking recommendation.
• Have the assistant list unknowns separately from confirmed findings.
• Do not accept "looks safe" when the assistant could not inspect CI output, branch protection, source docs, or owner policy.
• Re-run review after rebases or force pushes that change the head commit.

Troubleshooting

• The PR is mostly generated: review the source input and generator first; block merge if reviewers cannot reproduce or explain the generated diff.
• The author says checks passed locally: require current CI or reproducible command output tied to the reviewed commit.
• The risk owner is unavailable: defer merge or split the risky portion into a separate PR rather than approving by silence.
• The change is urgent: record the emergency owner, time-bound approval, rollback path, and follow-up review issue.
• Security details cannot be public: keep sensitive evidence in the private security channel and leave a minimal public note that owner review occurred.

Duplicate And History Check

Checked existing rules, guides, collections, hooks, agents, skills, commands, open PRs, and closed PR history for high-risk review escalation, code review escalation, branch protection review, security owner signoff, production change review, and AI-assisted PR risk review.

Adjacent content includes a general code review expert rule, production codebase auditor rule, review-AI-generated-code guide, secure workflow guide, dependency risk command, and API contract review collection. This entry is distinct because it is a portable escalation policy for deciding when a risky PR needs owner signoff, fresh checks, rollback evidence, and privacy-safe review notes before merge.

The previously closed PR for this slot was closed for branch shape because it included generated/output churn and no canonical source MDX file for the submitted item. This submission adds exactly one source rules file.

What a Reviewer Looks For

Beyond the escalation triggers above, ground routine review depth in the Google Engineering Practices code review guidance. It enumerates what a reviewer examines in every change, in rough priority order.

References

• Google Engineering Practices code review guidance: https://google.github.io/eng-practices/review/reviewer/looking-for.html
• OWASP Code Review Guide: https://owasp.org/www-project-code-review-guide/
• GitHub protected branches documentation: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• SLSA requirements: https://slsa.dev/spec/v1.1/requirements

• Source repositorygithub.com 2026-07-19T11:20:19-07:00
• Documentationgoogle.github.io
• Submitted by MkDev112026-06-04