A PR review policy that clears routine work and escalates real risk

A documentation typo and a billing change can both pass CI, then wait in the same review queue. The first may require little judgment; the second may change who gets charged. Reviewing both alike wastes attention, but green checks alone cannot authorize the billing change.

The useful automation is a policy for *which decision is needed*. Gather evidence for every PR. Let a narrow, reversible class proceed without a fresh human merge decision only under owner-approved, verified controls. Send uncertain behavior to a named owner with an answerable question. Block failed controls. A merge is not permission to deploy.

This is a proposal, not an executed trial. Owners must verify repository rules and deployment paths before changing authority.

Two PRs, two decisions

In the illustrative *before* workflow, a developer opens a PR, CI runs, and a reviewer takes it from a common queue. The reviewer reconstructs intent, asks questions, and may repeat the review after a new commit. The typo waits even when its scope is plain. The billing change may receive a quick approval despite a question tests cannot answer. Track queue wait separately from active review and author-response time.

In the proposed *after* workflow, automation inventories the diff against an owner-approved, versioned policy and collects checks, outputs and findings. The typo enters A, eligible for bounded automatic merge, only if it changes plain prose, not executable examples, configuration or operating instructions; the class is preapproved, evidence fresh and repository gates satisfied. A billing flag enters B, named-human review, even with passing tests: the owner decides acceptable behavior. C means block: failed checks, absent mandatory evidence or suspected compromise must be addressed first. Apply C before B, then A. A mixed PR takes the stricter route.

Local tests or diff-aware review can help gather evidence before the PR opens. They cannot supply a missing billing rule or replace required hosted checks on the submitted revision.

These are proposed routes, not GitHub classifications. A one-line change can redirect money; author-written labels cannot establish eligibility. B remains blocked from merge while awaiting its owner, but that wait is not a failed-control C. Treat a PR prompt asking for secrets as untrusted: isolate the run and seek security assessment; block suspected compromise.

Make the route enforceable

GitHub auto-merge waits for configured requirements; it does not know A/B/C. A needs a trusted, required policy check that permits only positively established A changes under an approved version, holds B for its human decision, and blocks C. Bind the result to the revision considered for merge. Protect policy, check producer and workflows from self-approval; restrict automation actors. Without verified enforcement, retain manual merge. Existing required human or code-owner approvals still apply; changing them is a separate, explicit owner decision.

Inspect effective branch rules, direct-push rights and bypass actors. CODEOWNERS requests reviewers; a branch rule or ruleset must require approval. Any one of several listed owners may suffice, but not for a policy naming a particular billing owner. Protect policy and ownership files.

Check what ran, not a green wrapper: a status may be successful, skipped or neutral, while a path-filtered required workflow may remain pending. Merge-queue workflows need evidence for the merge-group revision; see required-check guidance. Keep untrusted PR code and artifacts out of privileged workflows with write tokens or secrets; see Actions security guidance. Settings cannot decide the billing rule.

Give the billing owner a decision, not a verdict

Suppose the billing PR changes config/flags.yml and src/billing/renewal.ts for an enrolled cohort. In this fictional example, renewal unit tests pass on the head revision, but production account selection is untested. One agent finds no calculation issue; another flags the default fallback. Neither decides who should be enrolled. The packet links the full diff, base and head, run records, outputs, uncovered behavior, findings with line references, policy version and proposed B route.

Ask the billing owner: “May this exact revision merge while deployment remains held, given the unverified account selection and fallback?” Record yes or no, rationale, inspected evidence, conditions and time. Silence is not approval. An undefined rule needs an owner decision, not a guessed test expectation. Disabling the flag may limit later exposure, but reverting code cannot undo processed charges; name the remediation and release owners.

A new commit makes this packet stale under the proposed policy; GitHub does not automatically dismiss an earlier approval. Configure stale-approval dismissal or latest-push approval where needed. Rerun checks on the current head/base or merge-group state, refresh evidence and seek the required decision again. The human inspects disputed findings, not merely an agent summary.

Merge is not deployment

Merge admits a revision to a branch. Production deployment and billing-flag exposure may require separate decisions. A release owner should authorize revision, cohort, observation window, charge-correctness and service-health signals, stop condition and remediation. The billing owner might approve merge while deployment stays held pending account-selection verification.

GitHub deployment environments can provide separate protection and reviewers, subject to configuration and plan. Verify the real approver, self-review and bypass settings, and that *every* production route passes through the protected job or an equivalent external gate. Merely naming an environment does not constrain a different job that deploys around it. If merge itself triggers an unprotected production deployment or flag exposure, do not turn on autonomous merging until that path is closed.

Earn the narrower policy

Start in shadow mode: keep approvals while the policy proposes routes and packets. Compare proposals with human decisions, but audit diffs and outcomes too. Include apparently clean A proposals in a risk-stratified audit; report eligible and audited counts and misses by stratum. Next use packets in supervised review without changing merge authority. Only after owner acceptance and verified enforcement should A receive limited autonomy. Expanding it requires another approval.

Measure the queue wait, active reviewer and alert-triage minutes, and total merge wait by comparable risk class over stated windows. Record counts, a median and a declared tail percentile, defects and reverts, audit denominators, and all-in agent, CI and human cost. Predeclare stop thresholds and a suspension owner; bypassed controls, unauthorized merges, suspected credential exposure or revision-unlinked decisions should suspend autonomy. A small clean sample is not proof of safety. Track production time separately: DORA's change lead time ends at production deployment, not merge. Link the measured change to the deployed revision, including any squash or rebase mapping.

Automated reviewers may share a blind spot or produce warnings that turn human review into a rubber stamp. An operator's account of three automated reviewers and a human merge is an anecdote, not a safety measurement; the “stampfest” concern is the counterpressure. If the packet adds more reconstruction work than it saves, or the audit cannot support the proposed A boundary, leave human merge authorization in place.

For the next PR, record the revision and full diff; check C, then B, then the approved A criteria. Note what ran and what did not, the owner and explicit question for an exception, and the separate deployment decision. You can do that without changing a repository setting. The Majestic Labs workflow diagnostic addresses broader coordination handoffs, not a PR-specific audit; the first useful experiment here is to find where the queue consumes attention without improving the decision.