Light-scan methodology

What is measured

The light scan reviews one universal public-web baseline, grouped for explanation into product clarity, trust, technical delivery, and discoverability. It checks public HTML, HTTP behavior, redirect evidence, common discovery files, DNS records, static semantics, metadata, and detected public API descriptions.

It can sample bounded same-origin public pages and compare common crawler responses. A deterministic surface profile records whether web, docs, API, GraphQL, OAuth, MCP, MCP App, SDK, and commerce evidence was detected, not detected, or could not be determined. Pricing copy alone does not activate commerce, and a generic mention does not activate API, OAuth, or MCP applicability.

It does not sign in or perform product actions.

How scoring works

Launch Ready publishes one integer score from 1 to 100. It is calculated directly from every applicable positive-weight check: 100 × earned weighted points ÷ applicable weighted points, rounded and clamped to the product range. Categories show earned and available points only; they are not additional scores.

Passes receive full credit, failures receive none, and every partial result carries a deterministic measured or finite-rubric fraction. Not-applicable checks are excluded only with a reason. Unknown, error, and blocked checks earn nothing and reduce weighted evidence coverage. This initial scoring model requires 100% weighted evidence coverage; otherwise the score is withheld instead of estimating from the checks that happened to finish. A failed or unreadable homepage also receives no score.

The registry emphasizes launch-critical signals: readable public content, clear identity and action, trust pages, HTTPS, usable controls, correct error responses, crawler access, and indexing. Optional or emerging formats such as llms.txt, ARD catalogs, Agent Skills, A2A cards, MCP cards, and Markdown negotiation remain useful evidence, but their absence does not lower the general website score. API, OAuth, MCP, and commerce checks should affect a future capability score only after that surface is positively detected.

Crawler policy is also applicability-aware. User-requested retrieval and search access affect discoverability; a site's choice to opt out of model training is reported without being treated as a launch defect.

A current result distinguishes pass, partial, fail, unknown, error, blocked, and not applicable. Reports label checks as scored or diagnostic, show each score fraction and contribution, and include applicability and error reasons. Historical reports can still contain the legacy info status and retain their original score rather than being silently rescored. A specialized capability is not treated as a failure when the scan cannot establish that the capability applies.

Evidence and budgets

Every scan records methodology, check-set, scoring-model, and collector versions; scan depth; score-basis ID; evidence timestamp; weighted coverage; evidence URLs; and discovery provenance. Discovery records distinguish a submitted target, redirect, HTML link, HTTP Link declaration, sitemap location, and conventional-path probe.

Requests, response bodies, redirects, time, and concurrency are capped to keep the scan low impact.

The scanner validates submitted targets, redirects, and extracted links before requesting them. It rejects private, reserved, credential-bearing, IP-literal, local, and non-standard-port targets.

Explicitly unsupported in the light scan

Planned capability families remain metadata only. The light scan does not run a browser, query external search or package registries, execute API operations, connect to MCP servers, call MCP tools, start OAuth, use authenticated accounts, run model journeys, perform writes, or initiate payments. Static markup evidence is not presented as browser-confirmed accessibility or runtime behavior.