What Is Approvability? Auto-Approving Safe Pull Requests

Approvability is an AI code review check that evaluates whether a pull request is safe enough to auto-approve without a human reviewer. It is the missing primitive in modern code review: most pull requests are routine — a doc fix, a unit test, a copy update, a one-line null check — and the human review on those PRs is purely ceremonial. Approvability gives the +1 on the safe ones and routes everything else to a human, so reviewers stay in flow on the changes that actually need scrutiny.

This guide explains what Approvability is, how Macroscope decides which pull requests qualify, how the check appears on GitHub, and how it compares to seat-based code review tools like CodeRabbit and Greptile. It also covers compliance, configuration, and the broader trend of AI auto-approval for low-risk PRs.

TL;DR — Approvability

• Approvability is an AI check that auto-approves low-risk pull requests. Macroscope ships it as a GitHub Check Run named Macroscope - Approvability Check, paired with the existing correctness check.
• The default policy is conservative. Documentation, tests, code behind a disabled feature flag, simple bug fixes, mechanical renames, and minor CI tweaks are eligible. Schema changes, security, auth, billing, and major refactors are escalated to humans.
• Three hurdles must clear before approval. Ownership (configurable, off by default), Eligibility (LLM agent verdict against the policy), and Correctness (no MEDIUM-or-higher bugs found). All three pass → Macroscope posts a GitHub APPROVE review.
• Customers own the policy. A .macroscope/approvability.md file at the repo root overrides defaults — Macroscope follows the customer's policy with highest priority.
• Approvability is off by default. Teams opt in per repo or workspace. Macroscope cannot approve its own PRs.
• Industry data confirms the gain. Teams that auto-approve low-risk PRs cite 6.4x faster merge times and 2-3x throughput per developer. (Ona case study)

What Is Approvability?

Approvability is the AI code review primitive for auto-approving safe pull requests. It sits alongside correctness review (which finds bugs) and answers a different question: given this PR's scope, complexity, change type, author trust, and runtime impact, is it safe enough to merge without a human reviewer?

The answer is yes for a meaningful share of pull requests on a typical engineering team. A senior engineer reviewing a one-line README typo, a unit test addition, or a feature flag flip is paying a context-switch cost for thirty seconds of judgment that an AI can render reliably. Auto approve pull requests is the natural automation target — and the one that compounds most as coding agents (Claude Code, Codex, Cursor) start producing the bulk of pull requests.

Approvability is not a replacement for code review. It is a triage layer on top of code review. A human still reviews anything where the AI has any doubt, and a human still has final merge authority. The policy is conservative by default, and any team operating under SOC 2 or other compliance frameworks can configure or disable Approvability entirely.

How Macroscope Approvability Works

Macroscope's Approvability check evaluates three hurdles before posting a GitHub approval. All three must clear; if any fail, Macroscope either recommends approval (close call) or defers entirely to a human reviewer.

Hurdle 1: Ownership

The first hurdle checks whether the PR author owns all the files they're changing. Ownership is determined from the repository's CODEOWNERS file. If CODEOWNERS is absent and the gate is enabled, there is nothing to check against — the hurdle simply does not apply.

Ownership is off by default (pr_approvability_code_owners_required = false) — most teams keep it informational rather than blocking. When a team chooses to enable it, ownership becomes a hard gate: even a perfectly safe PR by an outside contributor will not be auto-approved.

Hurdle 2: Eligibility

The second hurdle is the LLM agent verdict — the substantive risk decision. A dedicated approvability agent (separate from the correctness agent) reads the diff, traces the call graph through Macroscope's AST reference graph, and classifies the PR as either SUGGEST_APPROVABLE or SUGGEST_HUMAN_REVIEW.

The agent considers:

• Change type and runtime impact — does this affect production behavior?
• Scope — is the diff self-contained or does it touch many subsystems?
• Complexity — new logic vs. mechanical edit
• Schema impact — additive vs. breaking
• Author trust — repo role, ownership of the changed files, and prior commit history in the touched paths
• Open review comments — substantive comments from human reviewers push the verdict toward human review
• Customer guidelines — when .macroscope/approvability.md exists, those rules win over defaults

Hurdle 3: Correctness

Approvability waits for the correctness review to finish. If the correctness check finds MEDIUM-or-higher severity issues, Approvability does not approve, regardless of how the eligibility verdict turned out. A safe-looking refactor with a real bug is still a PR that needs a human.

When all three hurdles pass and approval is enabled, Macroscope posts a real GitHub APPROVE review on the PR, alongside an issue comment headed #### Approvability with the verdict and reasoning.

What Gets Auto-Approved by Default

The default Approvability policy is intentionally conservative. Macroscope auto-approves only changes where the intent is obvious, the scope is narrow, and the production blast radius is small.

Examples of pull requests Macroscope typically approves:

• Non-runtime changes. Documentation updates. Unit and integration tests. Code behind a feature flag that is not enabled. These changes literally cannot affect production behavior — there is nothing to break in the live system.
• Simple, low-risk, self-contained changes. Updating UI copy. Adding a new endpoint that follows an existing pattern. Tweaking an error message. A new optional field in an additive API. Changes where the intent is obvious and consistent with the surrounding code.
• Straightforward bug fixes. A missing null check. An off-by-one error. An inverted conditional. Fixes where the resolution is obvious and the scope is limited to a single function or method.
• Mechanical edits. Renames, file moves, import path changes, formatter-driven whitespace cleanups. The kind of edit a tool produced and a human is asked to rubber-stamp.
• Minor CI/CD configuration tweaks. Bumping a tool version, adjusting a workflow timeout, splitting a job into two — provided the change is small and self-contained.

For these PRs, a human reviewer adds essentially zero value. Auto approve pull requests like these and the team's overall review queue shrinks measurably.

What Gets Escalated to Humans

Macroscope escalates anything where the change has meaningful blast radius beyond the diff. The default policy is built around a single rule: if there's any doubt about scope or side effects, defer to a human.

Categories Macroscope routes to human review:

• Schema changes with breaking impact. Additive schema changes (new column, new optional field) can sometimes qualify. Renames, drops, and contract modifications do not — their downstream effects extend well beyond the diff.
• Significant runtime behavior changes. Anything that meaningfully alters how the system behaves in production. New features, new components, new integrations.
• Gating logic. Code that decides whether something happens — feature flag definitions, permission checks, routing rules. Even small edits here have outsized impact.
• Major side effects. Toggling a feature switch that changes behavior for a subset of users. Breaking changes to a public interface. Anything where users will see different behavior after merge.
• Major refactors. Restructuring abstractions, moving responsibilities between modules, replacing a pattern across the codebase.
• Production deployment and infrastructure changes. Kubernetes manifests, Terraform, Helm charts, anything affecting how production runs.
• Security, authentication, billing, or sensitive data. Any change to these directories is escalated, full stop. The cost of an automatic approval going wrong is too high.
• CODEOWNERS edits (unless the author is themselves a code owner of the file).
• Changes to .macroscope/ configuration files — the rules that govern review can't be auto-approved by review.

For everything else, the rule is: if Macroscope has any doubt as to the scope or potential side effects, defer to a human.

How Approvability Appears on GitHub

When Macroscope's Approvability check runs, it posts to the pull request as a GitHub Check Run named Macroscope - Approvability Check, paired with Macroscope - Correctness Check (the bug-finding pass).

The check resolves to one of four verdicts, surfaced in a comment on the PR:

• Approved — all three hurdles passed and Approvability is enabled. Macroscope submits a GitHub APPROVE review.
• Would Approve — all hurdles pass, but Approvability is configured as informational (no auto-approval). The comment shows what would have happened.
• Recommend Approval — eligibility and correctness pass, but ownership failed. The PR looks safe; a code owner just needs to give the +1.
• Needs human review — eligibility or correctness blocked. A human reviews as normal.

Self-PRs are a special case: Macroscope cannot approve its own pull requests (PRs opened by the Macroscope GitHub App itself). The check still runs, but resolves with a note explaining the exclusion.

When a PR is rebased or force-pushed without changing the diff, Macroscope reuses the prior verdict via diff-hash caching — the same change does not get re-evaluated, and a rebase note is appended to the comment.

Configuring Approvability with .macroscope/approvability.md

Customers can override Macroscope's default policy by adding .macroscope/approvability.md at the repository root. This file is read at the merge-base commit and is treated as the highest-priority guideline by the approvability agent.

The file supports optional YAML front matter with two fields:

---
tools: [view, git_blame, git_diff]
conclusion: failure
---

# Our team's approvability policy

We approve:
- Documentation changes under /docs
- Test-only changes
- Storybook stories
- Translations under i18n/

We escalate to humans:
- Anything in /payments, /auth, or /infra
- Schema migrations of any kind
- Changes to feature-flag definitions in /flags
- PRs by first-time contributors

For PRs touching /experiments, approve only if the experiment is in
"draft" status — flag for human review otherwise.

The body of the file is markdown — write the policy in plain English. The agent reads it like a senior engineer would read a team handbook and applies it to the PR at hand.

The two front-matter fields:

• tools — additive list of agent tools the approvability agent is allowed to use. Defaults are sensible; teams rarely change this.
• conclusion — what GitHub Check Run conclusion to emit when the verdict is not approved. Defaults to neutral (informational). Setting failure makes a non-approval block merging via required status checks.

The legacy filename macroscope_approvability.md is still recognized but does not support YAML front matter.

How Approvability Compares to Other AI Code Review Tools

Auto-approval is starting to appear across the AI code review space, but the implementations differ sharply on what they actually classify, how conservative they are, and whether the system can be trusted with compliance.

Approvability vs CodeRabbit auto-approval

CodeRabbit ships an auto-approval feature configurable via .coderabbit.yaml. It approves a PR once CodeRabbit's own comments are resolved and pre-merge checks are passing. (CodeRabbit auto-approval reference)

This is a different design than Macroscope's Approvability:

• Trigger: CodeRabbit auto-approves when its comments are resolved. Approvability auto-approves when the PR's change profile is low-risk in the first place — comments don't have to exist for a PR to qualify.
• Risk classification: CodeRabbit does not classify changes by risk type (docs vs. schema vs. security). Approvability does — and applies different defaults to each.
• Customer policy: Approvability accepts a customer-authored markdown policy that overrides defaults. CodeRabbit's auto-approval is more of an on/off switch for the comment-resolution behavior.
• Compliance posture: Approvability ships with a documented eligibility framework and an explicit escalation list for security/auth/billing. Teams under SOC 2 can review the policy as written and adapt it.

For teams that want a real risk classifier for safe merge automation rather than a comment-resolution gate, Macroscope is the closer fit.

Approvability vs Greptile

Greptile does not currently ship a dedicated auto-approval feature. Its product focuses on bug detection and natural-language custom rules. Greptile-adjacent workflows tend to use GitHub branch protection plus required Greptile reviews to gate merges, but the tool itself does not classify pull requests as auto-approvable. (Greptile docs)

Teams looking for a Greptile alternative that auto-approves low-risk PRs typically end up at Macroscope or build the classifier themselves with custom GitHub Actions.

Approvability vs Dependabot auto-merge

GitHub's Dependabot auto-merge is the closest precedent in the existing ecosystem — patch and minor dependency updates get auto-approved and auto-merged via a workflow. (GitHub Dependabot docs)

The difference is scope. Dependabot auto-merge handles a single, narrow class of PR: dependency updates from Dependabot itself. Approvability handles any PR — written by a human, an agent, or a tool — and decides whether the change profile makes it safe to approve. The eligibility logic is general-purpose, not Dependabot-shaped.

Approvability vs in-house AI auto-approval

Several engineering teams have built in-house AI auto-approvers in 2026. Ona reported a 6.4x merge-time improvement on auto-approved PRs and a 2.9x throughput increase per merge developer. Intercom and Customer.io have published similar case studies.

These in-house systems work — and they validate the demand. Approvability is the productized version: instead of building the classifier, the policy framework, and the GitHub integration in-house, teams adopt Macroscope and customize the policy file.

A Note on Compliance and SOC 2

For many teams, approving a PR without a human reviewer means revisiting their SOC 2 (or equivalent) policy. The original policies were written when humans were the only ones writing and reviewing code — agents reviewing code, much less doing it more thoroughly than people, was not on the table.

That assumption no longer matches reality. AI review pipelines now catch bugs at rates that exceed what human reviewers typically find, especially on the subtle cross-file issues that cause real production damage. The bar that compliance frameworks are protecting — every change is reviewed by a competent reviewer before merge — is achievable with an AI reviewer that meets the bar. The policies just need to acknowledge that.

What matters for compliance is governance, not the reviewer's identity:

• Explicit eligibility criteria documented in the customer-controlled policy file
• Audit trail — every Approvability decision is a GitHub Check Run with a verdict comment, retrievable indefinitely
• Human override — any team member can request changes, and the policy can be tightened or disabled instantly
• Conservative defaults — security, auth, billing, and infrastructure are escalated by default, regardless of customer policy

Whatever bar a team's compliance framework sets, Approvability is built to enforce it automatically. Teams stay in compliance and stay in flow.

Getting Started with Approvability

Approvability is off by default. Teams opt in per repository or per workspace.

To turn it on:

1. Install Macroscope — Macroscope - Approvability Check and Macroscope - Correctness Check start running on every PR immediately.
2. Run with the default policy for a week. The check will post Would Approve on PRs that meet the default criteria, without actually approving. This gives the team a feel for what the default policy approves before it actually approves anything.
3. Adjust the policy. Add .macroscope/approvability.md if the defaults are too aggressive or too conservative for the team's domain. Common additions: stricter rules for /payments or /infra paths, or explicit allowlists for low-risk directories.
4. Enable approval. Flip pr_approvability_enabled to true for the workspace or repository. From this point forward, qualifying PRs are auto-approved with a real GitHub APPROVE review.
5. (Optional) Enable ownership gate. If the team requires that authors only auto-approve files they own, enable pr_approvability_code_owners_required.

The full setup walks through in under five minutes. The GitHub setup guide covers the rest of the AI review pipeline.

Why Approvability Matters Now

The volume of pull requests on a typical engineering team is rising fast. Coding agents — Claude Code, Codex, Cursor, Macroscope's own Agent — are now producing a non-trivial share of PRs on many teams, and the share keeps growing. Reviewing every one of them with a human is neither scalable nor sensible. Most of those agent-produced PRs are routine: a focused change, well-scoped, with the test that proves it works.

The math is straightforward:

• A team shipping 200 PRs a week with an average of 30 minutes of reviewer time per PR is spending 100 reviewer-hours a week on review.
• If 30% of those PRs are routine (docs, tests, simple fixes, agent-produced refactors), that's 30 reviewer-hours a week of context switches that produce essentially zero value.
• Auto approve pull requests in that 30% and a team of 10 engineers reclaims roughly 3 reviewer-hours per engineer per week.

Multiply that across an engineering org and the savings compound. More importantly, the reviewer time that remains gets spent on the PRs that actually need careful eyes — the schema changes, the auth refactors, the architectural decisions. Reviewer attention follows risk.

The future of code review is one where agents do the heavy lifting on writing and reviewing, and humans stay in the loop on what matters. Approvability is the first step in that direction: not removing humans from review, but making sure every human review is a review the PR actually needed.

Frequently Asked Questions

What is Approvability in AI code review?

Approvability is an AI code review check that evaluates whether a pull request is safe to auto-approve without a human reviewer. It classifies the PR by change type (docs, tests, simple fix, schema, security, etc.), evaluates author trust signals, traces runtime impact through the codebase, and checks for correctness issues. If all three hurdles pass — ownership, eligibility, and correctness — Macroscope posts a real GitHub APPROVE review. The default policy is conservative; teams can override it with a .macroscope/approvability.md file at the repo root.

How does AI auto-approve pull requests safely?

A safe AI PR approval system has three properties: an explicit risk classifier with documented criteria, a conservative default policy that escalates anything risky, and an audit trail for every decision. Macroscope's Approvability check meets all three — it runs as a GitHub Check Run, posts a verdict comment with reasoning, and only approves PRs whose change profile is unambiguously low-risk. Schema changes, security/auth/billing edits, major refactors, and infrastructure changes are escalated to humans by default, regardless of how clean the diff looks.

What kinds of pull requests get auto-approved?

Macroscope's default Approvability policy auto-approves: documentation updates, unit and integration tests, code behind a disabled feature flag, simple low-risk self-contained changes (UI copy edits, additive API fields, minor UI tweaks), straightforward bug fixes (missing null check, off-by-one, inverted conditional), mechanical renames and file moves, and minor CI/CD configuration tweaks. Anything outside this list is escalated to a human reviewer.

What pull requests get escalated to a human reviewer?

Macroscope escalates: schema changes with breaking impact, significant runtime behavior changes, gating logic (feature flag definitions, permission checks), major side effects, major refactors, production deployment and infrastructure changes, anything in security/auth/billing/sensitive-data paths, CODEOWNERS edits (unless authored by an owner), and changes to .macroscope/ configuration files. The default rule is: if Macroscope has any doubt about scope or side effects, escalate.

How is Approvability different from CodeRabbit's auto-approval?

CodeRabbit's auto-approval triggers when its review comments are resolved and pre-merge checks pass — it does not classify the PR by risk type. Approvability classifies the PR's change profile (docs, schema, security, etc.) and applies different defaults to each, plus accepts a customer-authored markdown policy that overrides defaults. For teams that want a real risk classifier rather than a comment-resolution gate, Approvability is the closer fit. CodeRabbit alternatives that include risk-based auto-approval are still rare in the market.

Can I configure my own Approvability policy?

Yes. Add a .macroscope/approvability.md file at the root of your repository with a markdown description of your team's policy. Macroscope reads it at the merge-base commit and treats it as the highest-priority guideline — it overrides defaults when the two conflict. The file supports optional YAML front matter for tools (the agent's allowed tool list) and conclusion (whether a non-approval should emit a failure GitHub Check Run conclusion that can block merge via required status checks).

Does Approvability affect compliance frameworks like SOC 2?

It can, depending on how the policy is written. Most existing SOC 2 controls assume human review — teams adopting AI auto-approval typically update those controls to acknowledge AI as a competent reviewer with documented criteria, an audit trail, and human override authority. Approvability is built to enforce whatever policy the team's compliance framework sets: conservative defaults, explicit escalation for sensitive paths (security, auth, billing), and a Check Run record for every decision. Teams under stricter frameworks can keep Approvability disabled or restrict it to specific repos and paths.

Does Approvability replace human code review?

No. Approvability is a triage layer on top of code review, not a replacement. A human still reviews any PR that fails the eligibility, correctness, or ownership hurdles. The goal is to make sure every human review is a review the PR actually needed — not a 30-second rubber stamp on a doc fix that pulled the reviewer out of deep work for half an hour.

Is Approvability available on GitHub?

Yes. Approvability runs as a GitHub Check Run named Macroscope - Approvability Check, paired with Macroscope - Correctness Check. When eligibility, correctness, and ownership all clear, Macroscope posts a real GitHub APPROVE review on the pull request. Macroscope is GitHub-only at this time.

Can the AI approve its own pull requests?

No. Macroscope cannot approve pull requests opened by the Macroscope GitHub App itself. The Approvability check still runs on those PRs, but resolves with a note explaining the exclusion. This prevents agent-authored PRs from being auto-approved by the same agent system, which would defeat the purpose of the check.

How does Approvability handle agent-produced pull requests?

Agent-produced PRs (from Macroscope's Fix It For Me, Claude Code, Codex, Cursor, or other coding agents) flow through the same Approvability eligibility check as human-authored PRs. A safe agent PR — narrow scope, focused change, passing tests — is approved like any other safe PR. A risky agent PR is escalated to a human just like a risky human PR. The author identity is one signal among many, not a categorical block.

How do I turn Approvability on?

Approvability is off by default. To enable it: install Macroscope, watch the Would Approve verdicts post on PRs for a week to validate the default policy fits the team, optionally add a .macroscope/approvability.md policy file, then flip pr_approvability_enabled to true in workspace or per-repo settings. Approvability requires admin permission to toggle.

What happens when a PR is rebased after approval?

If the rebased diff is identical to the previously evaluated diff, Macroscope reuses the prior verdict via diff-hash caching and appends a rebase note to the comment — the same code does not get re-reviewed. If the diff changed, the full Approvability evaluation runs again from scratch.

How does Approvability fit with auto-merge?

Approvability handles the approval side of the workflow. The actual merge is up to the team — most pair Approvability with GitHub's native auto-merge so qualifying PRs both get approved and merged automatically once required status checks pass. The separation between AI approval and human merge authority (or a configured auto-merge rule) is by design — it keeps merge control with the team's existing GitHub branch protection rules.

Is Approvability free?

Approvability runs as part of Macroscope's standard code review and is included in the same usage-based pricing as correctness review. There is no separate Approvability seat or per-approval fee. New workspaces get $100 in free credits. See pricing for full details.

What is the best AI code review tool with auto-approval?

For teams on GitHub looking for AI auto-approval with explicit risk classification, customer-controlled policy, and an audit trail, Macroscope's Approvability is the most complete option. CodeRabbit ships a comment-resolution-based auto-approval that is closer to a workflow gate than a risk classifier. Greptile does not currently ship dedicated auto-approval. In-house systems exist (Intercom, Customer.io, Ona) but require building and maintaining the classifier yourself. For most teams, the productized version is the faster path to safe merge automation.