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

# Recommendations and risk scoring

> How a 0–100 risk score maps to one of four recommendation tiers.

Every completed scan returns a `recommendation` and a `risk_score` (0–100).
The recommendation is derived from the score:

| Score range | Recommendation  | Suggested action                                                                      |
| ----------- | --------------- | ------------------------------------------------------------------------------------- |
| 0–10        | `no_flags`      | No automated signals of violation. Auto-approve unless your policy requires sampling. |
| 11–40       | `review_low`    | Borderline. Inspect on a capacity-permitting basis.                                   |
| 41–60       | `review_medium` | Likely a violation. Send to your review queue.                                        |
| 61–100      | `review_high`   | Strong signals. Priority review.                                                      |

See [Recommendation values](/reference/recommendation) for the canonical
reference.

## What the score means

`risk_score` reflects Tumban's **confidence that a policy violation is
present**, not uncertainty. A score of `0` means nothing in the profile
or its external footprint triggered a signal; `100` means the evidence
is overwhelming. Missing or unreachable data does not push the score
up — partial coverage is recorded transparently in the
[`coverage`](/concepts/coverage) object, never as inflated risk.

The exact internals that produce the score are not part of the public
contract and may change without notice. Build against the published
fields — `risk_score`, `recommendation`, `confidence`,
`reason_codes`, `reason_summary`, `review_targets`, `evidence_index`,
and `coverage` — and treat any other field on the response as opaque.

## What `no_flags` does and doesn't mean

`no_flags` means Tumban's automated analysis did not detect a violation.
It does **not** prove a profile is clean — your manual review process
may still catch something automation missed.

## Integration tips

* Sort review queues by `risk_score` descending to triage fastest.
* Watch for `confidence: "low"` ([more](/concepts/confidence)) — those
  decisions warrant a second look regardless of recommendation tier.
* Always check the [`coverage`](/concepts/coverage) object before
  acting on a result — partial pipelines surface there, not as a
  distinct status.