The pull request for faster account recovery arrived with everything a reviewer is trained to want. A clear description. A small diff. Passing tests. A plan comment that matched the code line for line. The reviewer read it in one sitting, found nothing wrong, and approved, because nothing in it was wrong.

Nothing in it pointed at the rule, either: an account holding a payment method requires step-up verification before account recovery can issue a new session. The new path omitted that rule, and the pull request said nothing about payment methods because the plan, the criteria, and the ticket had said nothing about them. The reviewer was asked to judge code, judged it correctly, and approved a change the product could not accept.

This scenario is fictional end to end, carried through this series from ticket to dashboard, and it describes no real system, team, incident, deployment, or measurement. It is here because it shows what changes about review and release when the author is an agent: the reviewer's trust in the author is gone, and something has to take its place.

Why a Clean Diff Is Not Evidence

Your first guess is a more careful reviewer, a second reviewer, or an AI reviewer alongside the human. None of those touch the failure, because the failure is not in the diff. A human author carries evidence that never appears in a pull request: they were in the meeting where the rule was set, they remember the chat thread, they know which module owns policy. Reviewers lean on that without noticing. An agent carries none of it. Its diff is exactly as good as the artifacts it was given, and in the fixture those artifacts were clean, complete, and missing one rule.

So a clean diff from an agent tells you only that the review found no defect in the implementation it saw. It does not establish that the diff matches the intended change. Review has to test what the agent was asked against the accepted artifacts. That means the evidence a reviewer needs is no longer in the code alone. It is in the links from the pull request back to the intent record, the acceptance criteria, the plan, and the results of the checks, and in the question of whether every constraint that applies to this path was consulted. If the pull request cannot answer that question, the answer is not "probably fine". The answer is unknown.

At every handoff in a delivery system that admits agents, four things are fixed in advance: what the agent may do, what artifact persists, who decides, and what evidence permits progression. This article is about the third of those, at the three handoffs where the answer is a person's signature. It is a recommendation, not a policy; your organization's security policy, repository rules, release process, and incident runbooks take precedence wherever they disagree. Every vendor reference in it was last reviewed on 2026-09-02.

Two Reviews, One Signature

The model this series uses splits what most teams call "review" into two reviews and one decision, each with a different owner. The three rows below are quoted from its ownership table, with their wording unchanged.

The first review is about intent. A product or domain owner asks whether the change does what the product needs and whether every constraint that applies to this path was consulted. In the fixture that review did not happen at the pull request, because everyone assumed it had happened upstream, and upstream had nothing to say about payment methods. The second review is about implementation and risk. A code owner asks whether the implementation is sound, whether the test and eval evidence is real rather than described, and what the blast radius is if the change is wrong. That review did happen in the fixture, and it was done well. One good review out of two is how correct code for the wrong product gets approved.

The signature is not a review. A named release authority authorizes the irreversible or production action, based on both reviews and on the release record described below. It is a decision by someone accountable for the consequence, and the agent can prepare everything that feeds it without being allowed to make it. The diagram is a conceptual representation of the sequence.

A rejection at any of the three points sends the change back to the earliest thing that failed: intent or criteria for a product mismatch, the plan for a design error, the implementation for a code defect, or the release record for missing authority or evidence. It does not simply send the agent back to its editor. This separation is this series' analysis rather than a standard. For a neutral reference point, NIST's Secure Software Development Framework, version 1.1 from February 2022, describes a set of secure development practices that can be integrated into any SDLC and frames them as practices rather than requirements; the model here is compatible with that posture and does not claim its authority. The boundary argument that an agent needs owned limits rather than a prompt is made in the first article of this series, and this is that argument applied to the moment the change leaves the author's hands.

Reviewable Is Not Enforced

The two reviews need mechanisms, and the mechanisms are ordinary. A change-request template makes the author, human or agent, answer the intent question before a reviewer reads a line. The record below is a worked template for the fixture's change, filled in the way it should have been. The constraints line is the one to read.

# Change request: faster account recovery
 
Intent: intent-faster-account-recovery.md
Acceptance criteria covered: AC1, AC2, AC3, AC4
Constraints consulted: C1 (step-up for payment-method accounts), C2 (lockout rules)
Open items carried forward: Q2 (link lifetime), owner support lead, before release
 
Surfaces touched: RecoveryService, RecoveryController
Surfaces consulted but unchanged: StepUpPolicy
 
Evidence:
- tests: RecoveryDecisionTest, RecoveryLinkTest, run in CI on this change
- evals: eval-recovery-step-up, all runs passed, cases last confirmed by the
  product owner against current criteria
 
Reviews requested:
- intent: product owner, account access
- implementation and risk: code owner, auth
 
Rollback: recovery.fast-path flag off, no data migration

In the fixture, the constraints line would have read "none", and "none" is a claim a product owner can be asked to confirm. The template's entire value is that it turns an omission into a sentence someone has to sign.

A code-ownership rule makes the second review reach the right person. The rule below is a configuration example in the path-to-owner convention that several hosting platforms support; use it where your host supports one, and use your host's syntax. The second line routes any change to the policy module to the security owner even when the change request forgot to mention it.

# code-ownership rule (path-to-owner convention; configuration example)
/auth/recovery/**   @account-access-owners  @security-owners
/auth/policy/**     @security-owners

A rule like this is reviewable, which is where most teams stop thinking about it. Anyone can read it, and a reviewer is requested when a matching path changes. It is not, by itself, enforced. GitHub's documentation, reviewed on 2026-09-02, states that a code-owners file causes owners to be requested for review automatically, and that approval from a code owner can be required only after an administrator has enabled required reviews through branch protection rules or rulesets. It is one host's mechanism, cited here as a dated example of a general fact: the file routes, and the policy requires. Without a required-review policy on the release branch, the security owner's review is a convention, and a convention is what the fixture's process ran on.

If you cannot change the repository's policy, the lighter equivalents still buy something. The change-request template costs nothing and works on any host. A code-ownership rule that only requests review still puts the right name on the pull request. Asking for one required-review rule on one branch is a much smaller request than asking for a platform, and the cost of the interim is worth stating plainly: until the rule exists, the gate is enforced by habit, and habit is what the fixture defeated.

The Signature Depends on What Can Be Undone

Who may sign, and what the record has to contain, follows from one question: what can be undone, and how. The model uses four reversibility classes, and they are a recommendation, not a taxonomy any source defines. Reversible by flag or configuration, where future behavior returns to the previous path and no data changed. Reversible by redeploying the previous build, with no data changed. Reversible with repair, where data changed and returning needs a migration or backfill. Irreversible as an event, where an external effect occurred: a session was issued, an email was sent, or money moved. Later mitigation may reduce the consequence; it does not make the event unhappen.

The class decides the signature. A flag-reversible change on a low-risk path can be authorized by the code owner who reviewed it. An irreversible change needs the named release authority, whoever that is on your team, and needs the two reviews recorded before that person is asked. The fixture is the instructive case: the code is flag-reversible, and the flag would have restored the old path for future attempts, but it could not erase the occurrence of sessions already issued to payment-method accounts. Whether those credentials can be invalidated is a separate mitigation that the fixture does not establish. The code path was reversible. The issuance events were not. So the constraint had to enter before the signature, and a release record has to name the class explicitly rather than let the reader infer it from the presence of a flag.

The record below is a worked template for the fixture's release, filled in as the model requires. The reversibility line and the two names under rollback are the parts to read.

# Release decision: faster account recovery
 
Change: recovery fast path behind recovery.fast-path
Intent: intent-faster-account-recovery.md
Criteria covered: AC1, AC2, AC3, AC4
Open items: none; support lead resolved Q2 by retaining the existing link-lifetime policy
 
Evidence:
- product review of intent: recorded, product owner, account access
- technical review of implementation and risk: recorded, code owner, auth
- tests: RecoveryDecisionTest, RecoveryLinkTest, passed in CI on this change
- evals: eval-recovery-step-up, all runs passed
 
Reversibility: code reversible by flag; session issuance is irreversible as an event
Approver: release authority, account access
Rollback reference: recovery.fast-path off; no data migration
Rollback authorized by: release authority, account access
Rollback executed by: operations on call
Watch after release: AC4 log, recovery decisions by account class

Two roles appear under rollback, deliberately. The person who may decide to roll back is not always the person who can run it, and both have to be named before the release rather than found during the incident. The watch line matters as much: it names the signal that would show the constraint failing, which in the fixture is the log of every recovery decision with its account class.

Any delivery metric this record feeds should use a definition your team did not invent. DORA's guide to its delivery metrics, reviewed on 2026-09-02, defines change fail rate as the proportion of deployments requiring immediate corrective action, and failed deployment recovery time as the time to restore service after a failed deployment. Those definitions are used here for vocabulary only. This article attaches no number to them.

The Signal That Becomes the Next Intent

The last handoff is the one most processes treat as an ending. Something goes wrong in production, the fix ships, and the incident closes. In this model the incident closes when its lesson has become a new intent record with an owner, because a fix that does not change the artifacts upstream leaves the next agent to repeat the omission. The record below is a worked template for the fixture's incident, and it is the continuation of the fictional scenario rather than a claim about anything real. The last block is the one to read.

# Incident: recovery sessions issued without step-up verification
 
Signal: AC4 log shows payment-method accounts receiving IssueSession
Impact: sessions issued to payment-method accounts without step-up verification
Reversibility: code reversible by flag; session issuance is irreversible as an event
 
Actions completed:
- recovery.fast-path off; authorized by release authority, executed by operations
- Q1 definition of payment-method accounts re-confirmed
 
Assessment required:
- determine whether affected sessions can be invalidated; owner security lead
 
New intent stub:
  Wanted: recovery decisions consult StepUpPolicy for every account class
  Owner: security lead
  Constraint carried: C1
  Eval case to add: eval-recovery-step-up as a regression case

The stub is what makes this a record rather than a closed ticket. It carries C1 forward as a constraint with an owner, it names the eval case that would have caught the omission, and it sends the next change into the chain at the top, where the fixture's change should have entered in the first place.

Where This Is Too Much

Two reviews and a signature are proportionate to a change that can issue sessions to accounts holding a payment method. They are not proportionate to most changes. A routine patch update inside an approved dependency policy needs the existing pull request process and one reviewer. A typo in a log message needs no release record. A configuration change whose owner is already named in the repository needs that owner's review, not a signature ceremony. The rule that decides is the same one used everywhere in this series: ceremony scales with how open-ended the reasoning was and how expensive a plausible wrong result would be.

On a small team the two reviewers and the release authority may be one person, and that is fine. Two things should survive: the reversibility class still gets written on the record, and the rollback reference still names what to turn off and who may decide to turn it off. A team of three that writes those two lines has more control than a large team whose process assumes them. How many agents produced the change is a separate question from any of this, and the multi-agent topology of an investigation pipeline is its own subject in this series.

The sources cited here document mechanisms and definitions: how one host's code-ownership rule behaves, what a neutral secure-development framework recommends, how a delivery research program defines its measures. None of them shows that two reviews and a named signature reduce failures of the fixture's kind, and this article does not claim they do. The model's claim is narrower: without them, nobody is asked the question that would have caught it.

Who Signs When Nobody Holds the Role

The part I cannot resolve is the release authority on teams where the role exists on paper and nobody holds it in practice: the on-call engineer signs because they are there, or the product owner signs because the code owner is on leave. The obvious substitutes either create a bottleneck or quietly return to convention. What I would do first is smaller than fixing that. On the next release record your team writes, add the reversibility class and the two rollback names, and see who objects.