Understand a report

Read the finding first

The overall score is a launch-facing summary. A light report can contribute up to 75 of the full 100 launch-readiness points; the remaining 25 are reserved for a completed deep review. Use the score 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. An unresolved applicable weighted check earns no points and lowers evidence coverage; it does not suppress the score. 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.