Make review and approval requirements actor-neutral

    Context["Context\nAGENTS.md + Skills"] -.->|loaded at\nsession start| Agent

    Agent --> CI{"CI Pipeline\n(Constraints)"}

    CI -- Fail --> Agent

    CI -- Pass --> Review["Human reviews"]

    CI -- Pass --> Review["Independent review"]

    Review -- Changes needed --> Agent

    Review -- Approved --> Merge["Merge"]

    Merge --> GC["Garbage Collection\nTODO scan + coverage check + doc sync"]

You can also help community contributors get their merge requests ready, by becoming a [Merge Request Coach](/job-description-library/expert/merge-request-coach/).

Note that while all engineers can review all merge requests, the ability to *accept* merge requests is restricted to maintainers.

All engineers can review merge requests, but only maintainers can accept them. Maintainers may delegate the approving review to an independent review agent under the requirements below.

### Managing Review Assignments Before PTO

Maintainers are GitLab engineers who are experts at code review, know the GitLab product and codebase very well, and are empowered to accept merge requests in one or several [GitLab Engineering Projects](/handbook/engineering/projects/).

A maintainer may delegate merge-request review and approval to an independent review agent. A separate assessment agent, deterministic rules, or both must evaluate each merge request against maintainer-approved risk criteria and record the decision and rationale. The maintainer remains accountable for the delegation.

Meeting the risk criteria alone does not qualify a merge request for agent approval. Before an agent approves a merge request, the eligibility evaluator must also verify:

- The author and source project meet the trust-boundary requirements.

- The repository and merge request satisfy the controls required for the assigned risk tier.

- Qualified, independent review agents cover every domain affected by the change.

The evaluator must record these results for the merge request's current commit. If any check fails or lacks evidence, an independent human must approve the change. New commits invalidate the eligibility decision.

Authors must not control the assessment criteria, assessment configuration, or review agent configuration used for their own changes. Authors must not direct the independent review. Nobody may approve a change they wrote or directed an agent to write.

Existing requirements for human review or approval remain unchanged. A person must approve:

- Changes subject to SOX or FedRAMP controls.

- Contributions from the wider community.

- Changes for which law, regulation, or contract requires explicit human approval.

When in doubt, require human approval and consult the Compliance team.

Automated assessments must not override these requirements.

To define the risk criteria, use:

- The [Crawl-Walk-Run framework](/handbook/eta/ai/strategy/guiding-principles/#the-crawl-walk-run-framework).

- The [permission tiers for AI actions](/handbook/eta/ai/strategy/guiding-principles/#permission-tiers-for-ai-actions).

- The guidance to [match scrutiny to impact](/handbook/engineering/infrastructure-platforms/ai_usage_principles/#match-scrutiny-to-impact).

The maintainer must document and approve the following in the project:

- The risk criteria that determine which changes qualify for agent approval.

- The assessment agent, deterministic rules, or combination used to evaluate changes.

- The independent review agent and its configuration.

- The accountable maintainer.

- The deadline for human review of merged changes that received no human approval.

Each assessment must record the versions of the criteria, rules, and agent configurations used.

Assessment and review agents must load their instructions from the protected default branch. A person must approve changes to assessment criteria, deterministic rules, agent instructions and configurations, CODEOWNERS, or approval rules.

When one agent writes a change and another approves it, the accountable maintainer must review the merged change within the documented deadline and record the findings.

Every project should have at least two maintainers, but most should have more. Some projects have separate maintainers for different specialties. For example, [the main GitLab codebase](https://gitlab.com/gitlab-org/gitlab) has separate maintainers for frontend, backend, and database.

Great engineers are often also great reviewers, but code review is a skill in and of itself and not every engineer, no matter their seniority, will have had the same opportunities to hone that skill. It's also important to note that a big part of being a good maintainer comes from knowing the existing product and codebase extremely well, which lets them spot inconsistencies, edge cases, or non-obvious interactions with other features that would otherwise be missed easily.

### 3) Code Review Assistance

Run Duo review before human reviewers to accelerate the review process and catch more issues. Add to review checklists and collect developer feedback when Duo's review doesn't meet quality standards. Ask for specific Duo reviews before sending to reviewers (e.g. "Outline the database-specific implications for the database reviewer", "Pull out and describe the frontend changes to streamline the frontend review")

Use Duo review to accelerate the review process and catch more issues. Add to review checklists and collect developer feedback when Duo's review doesn't meet quality standards. Ask for specific Duo reviews before sending to reviewers (e.g. "Outline the database-specific implications for the database reviewer", "Pull out and describe the frontend changes to streamline the frontend review")

### 4) Test Case Generation

## Protected Branch Baseline Configurations

As a general rule, we want to protect our branches in such a way that we [require everyone to submit MRs for that protected branch](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html#require-everyone-to-submit-merge-requests-for-a-protected-branch). This requirement to use an MR allows for an easier trail to follow of changes made and rationale behind them, and most importantly, it requires an MR to be used to make changes to the protected branch which works hand-in-hand with our configured MR Approval Rules. If accounts can push direct to the protected branch, that account does not have to use an MR and can make changes without another team member's involvement.

As a general rule, we want to protect our branches in such a way that we [require everyone to submit MRs for that protected branch](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html#require-everyone-to-submit-merge-requests-for-a-protected-branch). This requirement to use an MR allows for an easier trail to follow of changes made and rationale behind them, and most importantly, it requires an MR to be used to make changes to the protected branch which works hand-in-hand with our configured MR Approval Rules. If accounts can push direct to the protected branch, that account does not have to use an MR and can make changes without an independent review.

When law, regulation, or contract requires explicit human approval, a person must approve the change. Examples include changes subject to SOX or FedRAMP controls.

### Example 1 of Protected Branch Settings configured to Require an MR

Development work must undergo testing and approval prior to deployment to production. This includes configuration changes and other related changes that may not be considered "development" work.

GitLab must record the identity of each merge request's reviewers and approvers, including whether each identity belongs to a person or an agent. GitLab must retain these records as evidence.

When agents both write and approve a change, a person must review the change after it merges.

### Deployment

Deployment of software at GitLab must adhere to all defined staging, testing, release, and rollback processes. Details on GitLab's deployment process can be found [here](/handbook/engineering/deployments-and-releases/deployments/).