> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gitar.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Risk Triage

> Classify whole-PR risk and apply team policy to review, approval, and merge decisions

export const ThemeImage = ({src, alt, width}) => {
  let lightSrc, darkSrc;
  if (src.includes("-light.")) {
    lightSrc = src;
    darkSrc = src.replace("-light.", "-dark.");
  } else if (src.includes("-dark.")) {
    darkSrc = src;
    lightSrc = src.replace("-dark.", "-light.");
  } else {
    lightSrc = src;
    darkSrc = src;
  }
  const style = width ? {
    maxWidth: width,
    marginInline: "auto"
  } : undefined;
  return <span>
      <img className="block dark:hidden rounded-lg border" src={lightSrc} alt={alt} style={style} />
      <img className="hidden dark:block rounded-lg border" src={darkSrc} alt={alt} style={style} />
    </span>;
};

Gitar classifies each PR as Low, Medium, or High risk to help reviewers decide where to focus attention. The assessment reflects the impact of the whole change, including sensitive behavior that a small diff can affect.

## What the risk levels mean

Risk describes the change's potential impact. It is separate from the severity of an individual finding and the overall review verdict.

| Level  | Default meaning                                                              | Example                                                            |
| ------ | ---------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Low    | Narrow changes with little behavior or interface impact.                     | A documentation correction.                                        |
| Medium | Bounded behavior changes, substantial internal changes, or uncertain impact. | A localized bug fix outside sensitive behavior.                    |
| High   | Sensitive behavior or broad impact.                                          | Authorization changes, payment calculations, or schema migrations. |

A PR can have no reported defects and still be high risk. For example, a correct change to payment calculations may need closer human review because of the behavior it affects.

## Where risk appears

The risk label appears inside the expanded **Code Review** section of the PR dashboard comment. It also appears in expanded activity details in the Gitar dashboard.

<ThemeImage src="/assets/images/risk-triage-light.png" alt="Example expanded Code Review with a risk assessment and review verdict" />

Gitar hides the previous label while a review is processing. Older reviews without an assessment gain one when another review runs.

## How Gitar assesses risk

Gitar uses the whole PR diff and file-change information, so a small follow-up push does not hide the risk of earlier changes in the same PR.

<Steps>
  <Step title="Assess the whole change">
    Gitar applies the default definitions and the organization's risk instructions to the PR.
  </Step>

  <Step title="Apply repository guidance">
    Repository instructions can raise the risk level to reflect local constraints. They cannot lower the organization's assessment.
  </Step>

  <Step title="Refresh before automated decisions">
    When the change needs reassessment, including after a Gitar fix, Gitar refreshes risk before evaluating approval or merge criteria.
  </Step>
</Steps>

Uncertain impact normally produces Medium risk. If Gitar cannot complete the assessment, it uses High risk so a failed assessment cannot satisfy a low-risk approval condition.

## Define risk for the organization

Organization admins set policy under **Settings -> Configuration -> Custom Instructions**. **Risk classification** turns assessment on or off, and **Risk instructions** refines what each level means for the team.

Risk classification is on by default. Leaving the instructions empty uses Gitar's default definitions.

For example:

```text theme={null}
Changes to payment calculations or authorization decisions are high risk.
Documentation-only changes are low risk.
```

Turning classification off hides risk labels and retains saved instructions. Risk-dependent approval or merge criteria require an assessment unless those criteria explicitly allow unavailable risk.

## Add repository guidance

The file `.gitar/config/risk.md` adds risk instructions for one repository.

```markdown theme={null}
Changes to the settlement schedule are high risk.
Changes to exported client interfaces require at least medium risk.
```

| Organization assessment | Repository guidance                 | Final level |
| ----------------------- | ----------------------------------- | ----------- |
| Low                     | The changed subsystem is high risk. | High        |
| Medium                  | The change is low risk.             | Medium      |
| High                    | No additional guidance.             | High        |

Gitar considers both the default-branch policy and additions in the PR. Deleting or emptying the PR's copy does not remove the default-branch policy from that review.

Policy changes apply when a review runs. Saving instructions does not reclassify every historical PR.

## Use risk in approval and merge criteria

Risk can restrict existing automation after code review. Low risk alone does not approve or merge a PR.

| Setting                                            | Example criterion                         |
| -------------------------------------------------- | ----------------------------------------- |
| [Auto-approve](/features/code-review/auto-approve) | Approve only low- or medium-risk changes. |
| [Auto-merge](/features/code-review/auto-merge)     | Merge only low-risk changes.              |

Blocking findings and platform checks still apply. The same assessment feeds these decisions, so the approval step does not invent a different risk level from a clean verdict.

## Related

<CardGroup cols={2}>
  <Card title="Code Review" icon="magnifying-glass" href="/features/code-review">
    Findings, verdicts, and review coverage.
  </Card>

  <Card title="Functional Validation" icon="list-check" href="/features/functional-validation">
    Track whether the change implements the linked issue's requirements.
  </Card>
</CardGroup>