# Understand a report

> Read scores, evidence, findings, and limits without overclaiming what a scan proves.

## Read the finding first

The overall score is a launch-facing summary. Use it to prioritize, but make changes from the finding detail: observed value, evidence URL, why it matters, and recommended fix.

A missing signal can be intentional. A passing signal can still be incomplete. Treat the report as public evidence collected at one point in time.

## Outcomes

- **Pass** — the expected public signal was observed.
- **Partial** — some, but not all, of the expected signal was observed.
- **Fail** — the expected signal was not observed.
- **Unknown** — the scan could not safely or reliably determine the signal.
- **Error** — collection failed; this is uncertainty, not a product failure.
- **Blocked** — the safety policy or required authorization prevented execution.
- **Not applicable** — a deterministic rule excludes the check and records why.

Every applicable scored check contributes its published weight multiplied by its explicit score fraction. Categories show explanatory earned/available points, not separate scores. Diagnostic checks cannot raise or lower the single headline score. This keeps optional agent formats and product-specific API, MCP, authentication, or commerce capabilities from distorting a general public-web result.

The report also records weighted evidence coverage and methodology, check-set, scoring-model, and collector versions. If any applicable weighted check is unresolved, no score is shown. Compare changes only when their score basis matches, and use the evidence rather than score movement alone.

## Rescan after a change

Fix one high-impact issue, deploy it, and run a new scan. A fresh scan can reuse a recent public result for the same hostname, so wait for the short reuse window to pass when you need to verify a just-deployed change.