The reviewer and approver role — the human gate

The reviewer and the approver are two distinct human roles in an otherwise automated pipeline. The reviewer checks the change: is the code correct, is the test coverage adequate, does the change match the rationale. The approver takes responsibility for the change: does the change belong in production at this moment, does the risk match the impact, is the rollback plan in place. The four-eyes principle is the structural reason both roles exist: every production change is read by two humans with different lenses before it merges. CODEOWNERS is the source of truth for who is eligible to fill each role.

Two distinct roles

The reviewer and the approver are not the same person wearing two hats. The reviewer understands the code; the approver owns the service. The reviewer checks the technical correctness of the change; the approver checks the production readiness.

flowchart LR
    PR["Pull request opened\nby author"] --> REV["Reviewer:\ntechnical correctness"]
    REV -->|"approved"| APP["Approver:\nproduction readiness"]
    REV -->|"changes requested"| AUT["Author revises"]
    AUT --> REV
    APP -->|"approved"| MERGE["Merge to default branch"]
    APP -->|"rejected"| HOLD["Held for revision"]
    MERGE --> CI["CI runs"]

The reviewer’s checklist: does the diff match the description, are tests adequate, is the change consistent with surrounding code, are there obvious failure modes the author missed. The approver’s checklist: is this safe to ship right now, is the rollback plan documented and tested, is the change window appropriate, is the on-call rotation aware.

The reviewer is a peer; the approver is an owner. The reviewer can be any engineer on the team; the approver is named in CODEOWNERS for the directory the change touches.

The four-eyes principle

The four-eyes principle is the structural reason the two roles exist. Every production change is read by two humans before merge. The first is the reviewer; the second is the approver. The two have different lenses, different incentives, different accountability. The principle is not redundancy; it is separation of concerns.

Implemented by the branch-protection rule, a pull request against the default branch requires:

1. A reviewer approval from any engineer on the team.
2. An approver approval from a CODEOWNERS-listed owner for the directory the change touches.
3. A passing CI run that includes the platform team’s paved-road checks and the security team’s policy as code.

The rule is enforced by the platform, not by humans. A pull request that meets the rule can merge; a pull request that does not cannot.

CODEOWNERS as the source of truth

CODEOWNERS is the file that names the approver for each directory. The file is read by the platform - GitHub, GitLab, or Bitbucket - and enforced by the branch-protection rule. A pull request that touches a directory listed in CODEOWNERS cannot merge until a user listed in that directory’s entry approves.

The CODEOWNERS file format:

# Platform-owned directories
/platform/                 @platform-team
/clusters/                @platform-team
/.github/workflows/       @platform-team

# Application-owned directories
/services/api/             @api-team
/services/worker/          @worker-team
/services/cron/            @cron-team

# Default owner for everything else
*                          @on-call-rotation

The file is owned by the platform team; the entries that name the application teams are pull requests from those teams. A CODEOWNERS file that is out of date is a CODEOWNERS file that produces wrong approvers; the audit gap is silent until an incident reveals it.

The rubber-stamp failure mode

The reviewer or approver who approves every change without reading the diff is a rubber stamp - the most common failure mode of the human gate. The signal is approval latency: an engineer who approves every pull request in under 60 seconds is an engineer who is not reading the diff.

The fix is structural:

• Require a review comment on every pull request that touches a CODEOWNERS-listed directory. An approval with no comment is the rubber-stamp signal; CI fails the merge.
• Require the reviewer to differ from the author. A self-approval is not a review.
• Sample-review for audit. A random 10 percent of pull requests are reviewed by a second-pass auditor; findings become dashboard metrics.

The rubber-stamp failure mode is silent: the pipeline runs, the changes ship, the audit chain looks intact. The fix is to surface the failure mode in the same pipeline that surfaces the technical failure modes.

Production discipline

1. Enforce the four-eyes principle in the branch-protection rule. Two distinct approvals from two distinct humans.
2. Source approvers from CODEOWNERS. The file is the source of truth; the branch-protection rule enforces it.
3. Require a review comment on every approval. A rubber-stamp is an approval without a comment.
4. Audit rubber-stamp rates monthly. Sample-review 10 percent of pull requests; report the finding.
5. Treat the human gate as part of the audit chain. The reviewer’s name and the approver’s name are on every change record.

Cross-course references

• This course, Part CVI-03 (ChangeAuthorApprover) covers the change record that names the reviewer and approver.
• This course, Part CVII-02 (TrustBoundaries) covers the trust boundary the human gate sits on.
• Ansible for Production Sysadmins - Part XXXVII (RepoArch) covers the same CODEOWNERS pattern at the Ansible repository level.

Quiz