How it works — Unattended Works

Five stages, no conversation

Purchase not built yet

You pay the published price and supply one public URL. That is the whole intake. No account is created, no questionnaire is served, and no call is scheduled. This stage does not exist yet — checkout is not open.

Scope resolution designed

The runner resolves the entry URL, reads robots.txt, and expands the route list up to the published crawl budget. The resolved list — including what was excluded and why — is written into the report before any evidence is collected, so scope is a recorded fact rather than an afterthought.

Evidence collection designed

Each route is loaded in a real browser engine at a desktop viewport and a mobile viewport. Screenshots, request ledgers, storage ledgers, console transcripts, computed styles, and DOM assertions are recorded as they happen. Interaction probes run last, and only the non-destructive ones.

Verification designed

Findings are derived from the recorded artifacts, not from the live site. Any candidate finding without a referenced artifact is dropped rather than described. Severity is applied from the published rubric, and findings sharing a cause are grouped before ranking.

Delivery not built yet

The HTML report and the JSON document are packaged with a content hash per artifact and made available as a download. Delivery has no email step and no dashboard login. This stage does not exist yet.

What happens when a run cannot finish

The site cannot be reached

If the entry URL does not resolve or the origin refuses the runner, the run stops and reports that it stopped. No partial report is delivered as though it were complete.

Some routes cannot be reached

Routes that time out, rate-limit, or require authentication are recorded with status not_reached and appear in the report's not_covered list. They are never silently omitted and never counted as passing.

The site is larger than the crawl budget

The budget is stated in the report along with the exact routes visited. A truncated crawl is reported as truncated.

The runner itself fails

A run that cannot produce a verifiable report is a failed run, and a failed run is refunded rather than delivered with caveats.

Why the whole run is written down

An unattended product is only trustworthy if you can describe what it does without being in the room. That is why every stage above is published, in the order it happens, with the two that do not exist yet marked as not built rather than quietly implied.

Why evidence first, findings second

Most automated site tooling inverts this: it runs a rule engine against a live page and reports the rule output. That is fast and it is unreproducible — rerun it an hour later against a changed page and the finding cannot be defended.

Here the artifacts are captured first and the findings are derived from the artifacts afterwards. That ordering has two consequences worth stating. A finding can always be traced to the exact recorded observation behind it, and a report can be re-derived from its own artifacts without touching your site again.

What you do afterwards

Nothing, unless you want to. The ledger is ordered so that reading it top-down is a reasonable plan, and every entry is written as an outcome to reach rather than as a patch to apply. Whoever maintains the site does the fixing. This product does not write code, open merge requests, or deploy anything.