---
title: "Report"
description: "The results of the scan. Findings, blind spots, score and what a broken run looks like."
---

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

# Report

## Findings

Every finding carries:

- **The claim** — the observable condition the check states, e.g.
  "Fetch call does not provide an AbortSignal."
- **The check** — `doctor/check-id`, the rule that fired.
- **The location** — `file:line`, and the count when the same shape
  appears more than once.
- **Severity** — `error`, `warning`, or `info`.

Checks also explain themselves: `impact` (what goes wrong), `why` (the
mechanism), and `fix` (what to do). These fields ride along in the
[JSON output](/agents/json-reference) so your agent reads the same
explanations you do.

## Blind spots

Blind spots are written by your agent for each doctor. When your agent
builds a doctor, it declares what that doctor cannot catch. They are
there to guide your agents through the code review process. Think of it
as your agent consulting with your doctor, so it can make the educated
decisions itself.

Where blind spots come from — and how agents are taught to probe their
own — is covered in [honest checks](/authoring/honest-checks).

## The score

A 0–100 number at the end of a run. Severity is weighted across findings
and files, with a grade:

| Range | Grade |
| ----- | ----- |
| 90–100 | Excellent |
| 75–89 | Good |
| 50–74 | Fair |
| 25–49 | Poor |
| 0–24 | Critical |

An empty scan (zero files checked) doesn't score a perfect 100 —
nothing checked is a warning, not a win.

## Broken doctors are infrastructure failures

A doctor that fails to load or crashes mid-scan is reported as broken,
fails the run outright, and the score renders as null. Broken tooling
never reads as a clean codebase.

Source: https://anydoctor.dev/scans/report/index.mdx