> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zenable.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Risk-Based Reviews

> Let authors merge low-risk, Zenable-reviewed PRs without waiting on peer review

Many teams have decided that low-risk changes reviewed by Zenable's coding verifiers are able to merge to main without human review. Stop queueing low-risk, routine changes behind human review, significantly reducing lead time for changes and end-to-end cycle time. To implement this for yourself, enable the [PR risk assessment](/integrations/vcs-reviewers/configuration#prmr-risk-assessment), publish it as a required check, and update your rulesets — then you're all set.

<Note>
  GitHub only today. On GitHub the checks are native check runs (rich output, re-runnable from the PR's checks tab); on GitLab they publish as commit statuses, and merge execution is GitHub-specific.
</Note>

## Enable It

1. Go to [Settings → Configuration](https://www.zenable.app/settings?utm_source=docs\&utm_medium=risk-based-reviews\&utm_content=settings\&tab=configuration) and pick the profile your repos use.
2. Under **PR/MR risk assessment** (mode must not be Off), switch on **Merge gate**.
3. Set your knobs:
   * **Auto-merge risk threshold** — highest assessed risk an author may merge without review (default `low`)
   * **Ready to merge label** — the label an author applies to say "merge this" (default `Ready to merge`)
   * **Needs-review label** — always forces peer review, at any risk level (default `zenable/needs-review`)

To guarantee certain changes always get peer review regardless of the AI assessment, add [risk floors](/integrations/vcs-reviewers/configuration#risk-floors) — deterministic rules like "more than 1,000 changed lines is at least medium risk" that ensure a minimum risk.

Once enabled, Zenable posts a `zenable/risk-assessment` check on every PR: **pending** while reviewing, **passing** with the assessed level (and a findings summary in the check's output) once done. The assessment rides the PR — a push carries the latest result forward to the new commit, so nothing goes red or pending mid-iteration. Review timing is unchanged and configured in one place — see [Reviewer Configuration](/integrations/vcs-reviewers/configuration#review-check-on-commits) for when reviews run and how to request one. Before moving on, open a small test PR and confirm the configuration works as expected: the check goes **pending**, then **passes** with an assessed level, the risk label lands on the PR, and the assessment summary appears in the check's output.

## Wire It Into Branch Protection

We recommend creating three rulesets on your default branch (**Repo → Settings → Rules → Rulesets**): your CI baseline, an AI review ruleset, and a human review ruleset:

<Steps>
  <Step title="CI baseline">
    Your existing required checks, such as requiring linear history, and a **Require a pull request** rule with **0 approvals**.
  </Step>

  <Step title="Automated Risk Assessment">
    One required status check: `zenable/risk-assessment`, with the **Zenable App selected as the source**. Consider adding org admins as bypass actors (*For pull requests only*) as a break-glass if Zenable is ever unavailable.
  </Step>

  <Step title="Human review">
    Your human review requirements, when they apply (for instance, approval count and code owners). Add the **Zenable App** as a bypass actor, *For pull requests only*. This is the only ruleset Zenable can bypass, and only for acceptable levels of risk after the author requests to merge (by attaching the appropriate label) so they maintain full control over timing.
  </Step>
</Steps>

## Merging a Low-Risk PR

As the PR author, once the check shows your PR at or below the threshold, and if you'd like to merge your PR:

* **Enable auto-merge** on the PR (to define the merge method and commit message you want Zenable to use), or
* **Apply the Ready to merge label** yourself. Importantly, the label must be applied by the PR author for it to be considered.

Zenable re-verifies that the assessment is within your configured risk threshold and the needs-review label is absent, then merges. CI and the risk assessment still apply in full; only peer review is waived. Anything above the threshold goes through your normal review flow untouched.

To force review on a specific PR regardless of risk, apply the needs-review label.

## Review Check (no gating)

Want visibility without any merge policy? Enable **Review check on commits** under **PR Reviews** in the same configuration profile. Zenable adds a `zenable/review` check on all PRs that are enabled for PR reviews, set as **passing** when the review has completed (naming the assessed risk level) and **skipped** for each commit that hasn't been reviewed. Because skipped counts as passing on GitHub, it informs without gating, and it works alongside or entirely independent of risk-based merging.