Command Palette

Search for a command to run...

Arbtr

Command Palette

Search for a command to run...

PR Policy Enforcement

Feature

Turn your architecture decisions into automated PR checks. Prevent drift before it merges.

PR Policy Enforcement transforms your architecture decisions into automated guardrails. When a PR violates a decision, Arbtr blocks or warns the developer—with a direct link to the relevant decision.

Zero Configuration

AI automatically infers enforceable rules from your decision content. No manual setup required.

GitHub Integration

Results appear as GitHub Check Runs and PR comments with violation details.

Flexible Enforcement

Choose to warn developers or block PRs entirely. Configure per-decision or team-wide.

How It Works

1

Create a Decision

Write your architecture decision as usual. Include specifics like "We will use TypeScript instead of JavaScript" or "Do not use moment.js, prefer date-fns".

2

AI Infers Rules

When you click "Infer Rules" on the decision page, AI analyzes your decision and extracts enforceable patterns: blocked dependencies, blocked file patterns, and required patterns.

3

PRs Are Checked

When a PR is opened or updated, Arbtr receives a webhook from GitHub, analyzes the changed files and dependencies, and checks them against all active enforcement rules.

4

Results Posted to GitHub

A GitHub Check Run shows pass/fail status. Optionally, a PR comment lists all violations with links to the relevant decisions.

What Can Be Enforced

Blocked Dependencies

Prevent specific packages from being added to your project. Works with npm, pip, and Go modules.

Example decision text:

"We will not use moment.js due to its large bundle size. Use date-fns instead."

Inferred rule:

Block: moment (npm) → Suggest: date-fns

Blocked File Patterns

Block files matching certain patterns. Useful for enforcing TypeScript-only, preventing certain file types, or restricting directories.

Example decision text:

"All new code must be written in TypeScript. No new JavaScript files should be added."

Inferred rule:

Block: *.js files
tip
Patterns use glob syntax. Use *.js for root files or **/*.js for all directories.

Required Patterns

Require certain files or patterns to exist when specific conditions are met.

Example decision text:

"Every API endpoint must have a corresponding test file."

Inferred rule:

Require: *.test.ts when modifying api/**/*.ts

Setup Guide

1

Connect GitHub with Full Access

PR enforcement requires Full Access mode for GitHub integration to post check results.

Go to Settings → Integrations → GitHub and ensure you have Full Access mode enabled. If you only have Read-Only mode, you'll need to install the Full Access GitHub App.

GitHub Setup Guide
2

Enable PR Policy Enforcement

Turn on the PR Policy Enforcement feature for your team.

In Settings → Integrations, configure:

  • PR Policy Enforcement:Toggle ON
  • Enforcement Mode:Warn (yellow warnings) or Block (red failures)
  • Decision Threshold:Which decisions to enforce (All, Important+, or Anchor only)
  • Report As:GitHub Check (required for blocking) and/or PR Comment
3

Webhook (Automatic)

The webhook that notifies Arbtr about new PRs is configured automatically when you connect your GitHub repository.

No action needed. Just enable PR Policy Enforcement in your team settings and you're ready to go.

4

Infer Rules from Decisions

Go to each decision you want to enforce and generate the rules.

  1. Open a decision that contains technical constraints
  2. Scroll down to the "PR Policy Enforcement" section
  3. Click "Infer Rules from Decision"
  4. Review the AI-generated rules
  5. Toggle Active to enable enforcement
  6. Optionally adjust the enforcement level per-decision
5

Test with a PR

Create a test PR that violates one of your rules to verify everything works.

For example, if you have a "No JavaScript files" rule, create a PR that adds a .js file. You should see the Arbtr Policy Check appear as a GitHub Check Run.

Enforcement Levels

Enforcement can be configured at two levels: team-wide and per-decision. The stricter level always wins.

Off

No enforcement. The rule is tracked but won't affect PRs.

Warn

Shows a warning on the PR but doesn't block merging. Good for gradual rollout.

Block

Fails the GitHub Check. If branch protection requires passing checks, the PR cannot be merged.

i
Team vs Decision levels: If the team is set to "Block" but a decision is set to "Warn", violations will be treated as "Block". This lets you enforce a minimum strictness team-wide.

Understanding Check Results

All Checks Passed

No violations found. The PR is compliant with all active architecture decisions.

Warnings Found

Violations detected but enforcement is set to "Warn". The check passes but issues are flagged. The PR comment will list what to fix.

Check Failed

At least one violation has "Block" severity. The PR cannot be merged until the issues are resolved or the rules are adjusted.

Sample PR Comment

Arbtr Policy Check Results

Found 1 violation(s) against your team's architecture decisions.

File 'src/utils/helpers.js' matches blocked pattern '*.js'

Decision: Adopt TypeScript for all new code

Reason: All new code must be written in TypeScript.

Per-Decision Configuration

Each decision has its own enforcement settings in the "PR Policy Enforcement" section:

  • Active:Toggle to enable/disable this decision's rules entirely.
  • Level:Off, Warn, or Block for this specific decision.
  • Confidence:How confident the AI is about the inferred rules (0-100%).
  • Refresh:Re-run AI inference if you've updated the decision content.
tip
Refresh rules after updating a decision's content to capture any new constraints you've added.

Best Practices

Write Specific Decisions

The AI works best with concrete, specific constraints. Instead of "Use modern JavaScript features", write "Do not use var; use const or let. Do not use callback-based APIs; use async/await."

Start with Warn Mode

Roll out new rules in "Warn" mode first to see what would be caught without blocking developers. Once you're confident the rules are correct, switch to "Block".

Review AI-Inferred Rules

Always review the rules the AI generates. Check the confidence score—lower confidence might indicate the decision text wasn't specific enough or the AI made incorrect assumptions.

Use Decision Links

PR comments include links to the relevant decision. Encourage developers to read the full context before requesting exceptions or changes.

Enable Branch Protection

For "Block" mode to actually prevent merging, enable GitHub branch protection rules that require the "Arbtr Policy Check" to pass before merging.

Troubleshooting

!

Check not appearing on PR

Verify that: (1) PR Policy Enforcement is enabled in team settings, (2) The GitHub webhook is configured, (3) At least one decision has active enforcement rules, (4) The PR is on a repository connected to Arbtr.
!

Rules not detecting violations

Check that: (1) The rule is marked as "Active", (2) The enforcement level isn't "Off", (3) The pattern syntax is correct (e.g., **/*.js for all directories vs *.js for root only), (4) The decision status isn't "Archived" or "Deferred".
!

No rules inferred from decision

The AI couldn't find specific, enforceable constraints in the decision text. Try adding more concrete statements like "Do not use X", "All files must be Y", or "Never add Z dependency".
i

Excluding files from checks

Currently, patterns apply to all files. If you need to exclude certain paths (like test fixtures), consider adjusting your glob patterns to be more specific.

Next

MCP Integration
    PR Policy Enforcement | Arbtr Docs