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. Each new free scan starts its own same-origin browser stage after static collection: it reads the rendered public page to see whether a first-time visitor can understand the product and identify a visible next step. The report waits for that stage so the visitor receives one complete free scan. It cannot click, type, run page scripts, search, leave the submitted page, or make non-idempotent requests; it may load same-origin public GET/HEAD resources needed to render that page. It is never a score input.

How scoring works

The free check earns up to 75 launch-readiness points. It first calculates the public-web result from every applicable positive-weight check—100 × earned weighted points ÷ applicable weighted points, rounded and clamped—then scales that result to the 75-point free-check portion. Categories show earned and available points only; they are not additional scores.

The public API retains that first 0–100 mechanical result as score; report and listing interfaces show its scaled 0–75 free-score portion within the full 100-point launch-readiness score. The browser stage is explanatory evidence only; it cannot earn or remove the 25 points reserved for deep review.

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. A failed or unreadable homepage reduces the score rather than preventing a review. The result always retains its coverage so collection uncertainty remains visible.

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.

A completed deep review can add up to 25 points. It scores applicable public journey quality, independent public trust research, and any detected developer or commercial path. A website is not penalized for a capability it does not expose. If an applicable deep check cannot be completed, it receives no points and the report explains why.

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. 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. Outside the one bounded read-only browser stage described above, the free scan does not query external search or package registries, execute API operations, connect to MCP servers, call MCP tools, start OAuth, use authenticated accounts, run product journeys, perform writes, or initiate payments. The observation is not presented as proof that a flow works; static markup evidence is not presented as browser-confirmed accessibility or runtime behavior.