Policy Fields

Policies control how Critique reviews pull requests. They can be set at two levels — installation (applies to all repos under that GitHub App installation) and repository (overrides installation defaults for a specific repo).

Policy resolution

Policies resolve in layers:

1. System defaults — hardcoded safe values used when no stored policy exists.
2. Installation policy — overrides system defaults for all repos under the installation.
3. Repository policy — overrides installation policy for a specific repo.

For most fields, the repository value fully replaces the installation value. For pathEscalations, the repository value wins if non-empty, otherwise it inherits from the installation. For model fields (reviewLeadModel, reviewSpecialistModel, remedyModel), the repository value wins if non-null, otherwise it inherits from the installation.

Field reference

enabledSpecialists

Controls which specialist agents run during a review. SCOUT and LEAD always run and cannot be disabled — they are structural stages, not optional specialists.

Path escalations can dynamically add specialists to this set at review time, even if they were not in the base configuration.

strictness

The severity threshold that triggers a FAIL verdict. Each severity has a weight:

If any finding's severity weight meets or exceeds the strictness weight, the verdict is FAIL. With the default of 'FAIL' (weight 3), only FAIL-severity findings trigger a failing verdict. Setting strictness to 'WARNING' means WARNING findings will also cause a FAIL verdict.

This value is also injected into specialist prompts as Policy threshold: {strictness} and passed to Remedy blueprints as review.strictness.

rerunAllowed

Gates whether a user can re-trigger a review run from the dashboard. When false, the rerun API endpoint returns HTTP 403 with "Reruns are disabled for this repository policy.".

pathEscalations

Path-based rules that dynamically force additional specialists when changed file paths match patterns. Each escalation has three fields:

Default escalations:

auth-boundaries
  patterns: auth, session, permission, rbac
  requireSpecialists: SECURITY, TESTS

billing-mutators
  patterns: billing, invoice, stripe, subscription
  requireSpecialists: SECURITY, TESTS, ARCHITECTURE

At review time, every changed file path is lowercased and checked against each escalation's patterns. When matched, the required specialists are added to the enabled set regardless of the base enabledSpecialists configuration.

Escalation matches are recorded in the execution audit trail and visible in the "Why this ran" board entry.

reviewLeadModel

Overrides the default lead model for the review pipeline. Validated against the runtime model catalog via isRuntimeModelSupported(value, 'review-lead') and against the entitlement plan via isRuntimeModelAllowed(planKey, 'review-lead', value).

When set, replaces the system-wide lead model and its fallback chain.

reviewSpecialistModel

Overrides the default specialist model. When set, this also clears per-specialist model overrides — all four specialists will use this single model instead of having individual model assignments.

remedyModel

Overrides the Remedy execution model. Used when building the Remedy blueprint and stored in the execution explanation.

API endpoints

Both endpoints accept the same body schema and follow the same flow:

1. Parse the request body against the Zod schema.
2. Validate each model field against the entitlement plan.
3. Coerce through coercePolicyRuleSet() to sanitize and default any invalid input.
4. Upsert the ReviewPolicy row (update if exists, create if not).
5. Return { ok: true, policyId: string }.

Policy consumers