Glossary

ADO Pilot uses specialized terminology across configuration, billing, and integration. Every term defined here has an explicit anchor (#kebab-case) so other pages can deep-link to a single definition.

Terms are listed alphabetically. Each entry is one to three sentences; follow the cross-links for full treatment.

A

Auto-overage

The overage policy that lets reviews continue after included review credits are exhausted by billing the excess at the tier's overage rate. Contrasts with hard-block; see Overage behavior.

B

Batch API

Anthropic's asynchronous batch processing API, used for Pass 1 and Pass 2 reviews at a 50% discount versus the synchronous Messages API. ADO Pilot routes batch-first and falls back to the Messages API only if a batch exceeds the timeout budget.

Billing period

A recurring monthly interval anchored to your Stripe subscription start date. Review credit consumption resets at the period boundary; unused RCs do not carry over. See Review credits explained.

Blocker

The highest severity level for a finding — an issue the reviewer believes must be fixed before merge. One or more blockers force a FAIL verdict.

D

Delegated OAuth

An authentication method where users sign in with their Microsoft / Entra ID credentials and ADO Pilot acts on their behalf. Requires tenant admin consent. Deferred to v2; not shipped in v1. The current v1 onboarding flow only accepts a PAT — see Creating a PAT.

F

File exclusion patterns

Glob patterns (org / project / repo, additive merge) that exclude files from review and from review credit billing. Defaults like *.min.js and package-lock.json skip review-unworthy content. See File exclusions.

Finding

A specific code issue identified by an AI review. Each finding has a severity, a category (security, bug, performance, error-handling, maintainability, testing), and an optional code suggestion. Only Pass 2–confirmed findings are posted as inline comments.

H

Hard-block

The default overage policy on Starter and Team tiers — when included review credits are exhausted, new reviews are rejected silently and no RC is consumed. See Overage behavior.

I

Iteration

An Azure DevOps concept representing a single push to a pull request's source branch. Iterations are numbered sequentially (1, 2, 3, …) and are the unit of change ADO Pilot reviews.

O

Org

Short for organization — an Azure DevOps cloud organization. Internally identified by orgId (the ADO organization GUID). One org maps to one ADO Pilot tenant.

Overage cap

An optional per-tenant ceiling on auto-overage spending. Once overage RCs consumed reach the cap, reviews hard-block even on auto-overage tiers. Configured on the Billing page.

Overage rate

The per-RC price for reviews beyond a tier's included allocation, applied while the subscription is in auto-overage mode. See Pricing.

P

Pass 1

The initial broad-scan review phase. Pass 1 is tuned for high recall and may over-report; it uses the Batch API with forced tool choice. Typically 30–50% of Pass 1 candidates are rescinded by Pass 2.

Pass 2

The refinement phase. Pass 2 re-evaluates Pass 1 candidates, confirms true issues, rescinds false positives, and writes the user-facing comment text. Uses Batch API with Messages API fallback.

Personal access token (PAT)

A long-lived credential issued by Azure DevOps. ADO Pilot requires the scopes Code (read & write), Pull Request Threads (read & write), Build (read), and Project / Team (read). Required scopes are enforced during onboarding — see Creating a PAT.

R

Rescission

A Pass 2 action that drops a Pass 1 finding from the final review because it is a false positive or low-value. Rescinded findings are never posted to the PR.

Review credit (RC)

The billing unit for AI reviews. One RC corresponds to roughly 500 billing diff lines, with a one-RC minimum per review. Consumption is metered monthly and unused RCs do not roll over. See Review credits explained.

S

Service hook

The Azure DevOps mechanism that fires HTTP webhooks when a subscribed event occurs (for ADO Pilot, git.pullrequest.created and git.pullrequest.updated). Two hooks are registered per project at install time; each call carries the webhook JWT for authentication.

Service principal

An Entra ID app identity. Customers grant admin consent to ADO Pilot's multi-tenant app registration, which creates a service principal in their tenant and lets the backend mint short-lived (≈1 h) tokens without storing customer secrets. Roadmapped as the primary auth method post-v1.

Severity

The importance of a finding — blocker (must fix), warning (strongly suggested), or suggestion (nice-to-have). Severities roll up into the final verdict. See Severities and categories.

Status check

A PR status indicator posted by ADO Pilot with genre: adopilot and name: ai-pr-review. It can be wired up as a required branch policy in Azure DevOps. See Status check reference.

T

Target branch filters

Glob patterns (org / project / repo, scalar override) specifying which target branches trigger reviews — for example main, release/*, or * for all branches. Matching happens after the refs/heads/ prefix is stripped.

Tenant

One ADO Pilot customer, mapped one-to-one with an Azure DevOps organization. Each tenant has isolated data, settings, and billing in Cosmos DB, keyed by the ADO organization GUID.

Trial

The initial free allocation: 20 review credits granted to every new signup. Trial RCs are consumed before paid-plan RCs; once exhausted with no payment method on file, reviews hard-block.

V

Verdict

The final outcome of a review — PASS (no blockers or warnings), ADVISORY (warnings, no blockers), or FAIL (one or more blockers). Determines the status check state and, when configured as a required branch policy, gates PR completion.

W

Webhook JWT

The per-tenant HS256-signed JSON Web Token issued at onboarding. It carries a 90-day lifetime; the rotator re-issues a fresh JWT once fewer than 30 days remain before expiry, so JWTs are typically rotated at age ~60 days. Stored on each Azure DevOps service hook subscription as consumerInputs.webhookJwt (isConfidential: true) and validated by API Management before the webhook is forwarded to the backend.