ADO Pilot evaluates settings at three scopes — **organization**, **project**, and **repository**. You set defaults at the organization level, narrow them at the project level, and lock down individual repositories where needed. The resolved configuration for any pull request is the merge of all three.

## The three scopes

- **Organization** — Widest scope. Acts as the default for every project and repository.
- **Project** — Inherits from the organization. Overlays its own values on top.
- **Repository** — Narrowest scope. Wins over project and organization for any field it sets.

Each scope can leave a field unset, in which case the next-broader scope provides the value.

## Merge rules

ADO Pilot merges settings differently depending on the field type.

**Scalar fields** use override semantics — the most-specific scope wins.

| Field          | Type    | Default | Scopes that take effect |
| -------------- | ------- | ------- | ----------------------- |
| `enabled`      | boolean | `true`  | Org / project / repo    |
| `reviewOnPush` | boolean | `true`  | Org / project / repo    |

Static-analysis enrichment (additional findings merged into the review context from automated code scanning) is an operator/tenant-level setting and is not customer-configurable from the org, project, or repository scopes.

If the organization sets `enabled: true` and a repository sets `enabled: false`, that repository is disabled. The repository value wins outright.

**Org-only scalar fields** are defined only at the organization scope. Setting them at the project or repository level has no effect.

| Field                   | Type    | Default | Scope    | Status                   |
| ----------------------- | ------- | ------- | -------- | ------------------------ |
| `allowManualInvocation` | boolean | `true`  | Org only | Stored, not yet enforced |

`allowManualInvocation` is stored with your organization's configuration, but the review engine does not yet read it — changing it has no effect on whether manual triggers are accepted. See [Manual vs automatic reviews](manual-vs-automatic.md) for how manual triggering is actually controlled today.

### Exception — `enabled: false` short-circuits

When `enabled` is `false` at any scope, evaluation stops there. ADO Pilot does not consult narrower scopes — a project with `enabled: false` skips review even if a repository underneath it sets `enabled: true`. This makes `enabled: false` a clean way to pause reviews at any level without rewriting downstream configuration.

**Array fields** use additive semantics — patterns from every scope combine.

| Field                   | Type         | Default |
| ----------------------- | ------------ | ------- |
| `targetBranchFilters`   | string array | `["*"]` |
| `fileExclusionPatterns` | string array | `[]`    |

If the organization excludes `*.lock` and a repository excludes `*.generated.cs`, both patterns are active for that repository.

## How effective settings are computed

For every PR webhook, ADO Pilot resolves settings in this order:

1. Load organization-level settings.
2. Overlay project-level settings.
3. Overlay repository-level settings.
4. The result is the **effective settings** used for that review.

## Example: a multi-project organization

```text
Organization defaults
  enabled: true
  targetBranchFilters: ["main", "release/*"]
  fileExclusionPatterns: ["*.lock", "**/node_modules/**"]

  Project A  (no overrides)
    Backend repo
      effective enabled: true
      effective targetBranchFilters: ["main", "release/*"]
      effective fileExclusionPatterns: ["*.lock", "**/node_modules/**"]

  Project B
    targetBranchFilters: ["main", "release/v*", "hotfix/*"]
    Frontend repo
      enabled: false
      effective enabled: false   (repo wins)
      effective targetBranchFilters: ["main", "release/*", "release/v*", "hotfix/*"]
      effective fileExclusionPatterns: ["*.lock", "**/node_modules/**"]
```

## Choosing a starting point

- Set company-wide rules at the **organization** level — branch filters that match your release model, exclusions for build artifacts that every team produces.
- Use the **project** level for team-specific workflows — for example, a backend project that needs to exclude generated protobuf files.
- Use the **repository** level for one-off cases — disabling reviews on an experimental repo, or adding exclusions for a vendored library.

{% callout type="tip" title="Read these next" %}
The merge rules above are referenced from most other pages in this section. See [Choosing which repositories get reviewed](enabling-repositories.md), [Targeting branches](branch-filters.md), and [Excluding files from review](file-exclusions.md) for how each setting is configured in practice.
{% /callout %}