Reading your scan report

The report is generated, not written. Nothing on it is an opinion: every line is a check that passed, failed or warned, and every number comes from a committed file that can be re-read.

There are two kinds of report. A named one, handed to the business it is about. And a published one at /scan/<slug>, which is the same measurement with the business removed. This page describes both; the published ones are the fifteen you can read right now.

The top of the page: the number and the verdict #

A score out of 100, a grade, and one sentence saying what the grade means for a customer sent here by an assistant. Underneath: when it was scanned, which version of the scanner did it, and where the site sits in the fifteen-site sample.

The grade bands are fixed at 70 and 40. agent-ready at 70 and above, partially ready from 40 to 69, invisible to agents below 40.

01 — What an agent can actually do here #

Every way in the scanner found on the page it fetched, and whether software could drive it. This is the section that decides whether a customer sent by an assistant becomes a job.

Each row is one detected action. Its columns:

{
  "kind": "booking",
  "label": "booking form",
  "detail": "8 fields",
  "agentCallable": false,
  "blockers": [
    "a CAPTCHA on this page blocks legitimate agents"
  ]
}

That row is worth reading twice. The form has eight fields, every one of them fine, and the action is still closed to agents — because a CAPTCHA sits in front of it. The score is not what stops a booking. The wall at the end of the form is.

If the section is empty, the scanner found no way in at all on the page it fetched: no form, no widget, no phone link. Two of the fifteen sampled sites are in that state — source: packages/scanner/benchmark/reports/summary.json, breakdown.overall.sitesWithNoAction.

02 — Where the score came from #

Five categories, twenty points each, with every individual check listed underneath as a pass, a warning, a failure or a note. Each category also carries one sentence explaining what it is measuring, aimed at an owner rather than a developer.

Findings carry a status and, where any tooling counts them, a stable code. The prose of a message is for humans and may be reworded; nothing should ever be tallied by matching message text.

03 — The fix list #

Everything the scanner found that has a named remedy, in the order the score reads them. These are instructions for whoever maintains the site. They are free, and they are the whole list — nothing is held back for a paid tier.

On a published report the fix text is rewritten on the way out, and the reason is worth stating plainly. Six fix strings in the committed 25 August evidence are written in the first person and advertise a hosted layer, a snippet and verified actions that do not exist. On a private report handed over by a founder who explains the state of things, that is a sales conversation. On a public page it is a claim we cannot support. So the publication path rewrites all six into instruction-only text, and refuses to publish a report in which one survives.

The wording was corrected at source in the scanner on 26 August 2026, so any scan run after that date produces instruction-only text directly. The fifteen committed reports were produced the day before and still carry the old wording, because regenerating them would mean re-fetching fifteen live sites that never asked to be scanned twice.

04 — How this compares #

The same scanner, the same day, run over a sample of Sydney service businesses found the way a customer’s agent would find them: plain searches for a plumber, a physio and a real estate agent. Nobody was screened for looking bookable.

The section shows this site against the sample mean, the best and the lowest score in the sample, and a per-vertical table of mean score and how many sites had an action an agent could complete.

05 — What this report is, and what it is not #

This block is on every report and it does not get softened. It is reproduced here because it is the most important part of the page and the part a reader skimming a number will skip.

• It measures one page, fetched once, read-only. The scanner requested the page and read the HTML it was handed. It did not run scripts, click anything, fill a field or submit a form, and it did not crawl the rest of the site. A site with a booking flow two clicks deep scores as if it were not there — because that is what an agent reading the fetched page gets.
• It understates most sites, and we know by how much. Opening the same sample in a real browser — rendering, waiting for scripts, clicking, following a link — reached actions a fetch of the entry page could not see, on almost every site in it. Discovery is not the wall. The wall is the CAPTCHA and the consent tick at the end of the form.
• It is version 0.1 of an instrument, not an audit. The scanner is early and its known defects are recorded in the repository rather than in a footnote. Treat a category score as a direction, not a verdict, and treat the fix list as the useful part.
• Frontlatch cannot fix this site today. The hosted layer that would make these actions callable is being built and is not running. What exists is the measurement you are reading.
• No action would ever fire without the owner turning it on. When that layer does exist, no live action runs on a business that has not verified that action type itself, set its own limits and connected its own notifications. Test mode is the default. That is a design rule, not a policy page.

What was removed, and why nobody is named #

Every published report states its own redactions rather than leaving a reader to wonder. Three lines, on every one of the fifteen: the business name and website address are withheld; phone numbers and booking-widget URLs are withheld; and the raw page markup — the scanner’s evidence trail — is withheld.

The businesses in the sample are real trading companies. They did not ask to be scanned, they have no right of reply on these pages, and the instrument that scored them is early enough that we publish its defects. A named low score would allege something about a business that has done nothing wrong, and the argument does not need it: a real estate agency in Sydney scoring twelve out of a hundred says exactly as much without a name on it. The only report that carries a name is one handed to the business it is about.

That twelve is the lowest score in the sample and it is real. Source: packages/scanner/publish/public-reports.json, the report published at /scan/real-estate-05.

The removal is structural rather than a find-and-replace pass. Identifying fields are rebuilt from a safe vocabulary instead of filtered, and any free-text field that does not match a known-safe shape is replaced wholesale. A final check throws on a surviving hostname, business-name token or phone number before anything can be published, and the test suite greps the generated bundle for every one of those and fails if a single one survives.

The subject a reader sees is an editorial descriptor and a placeholder host — "Sydney plumber", <sydney-plumber>.com.au — and descriptors are deliberately shared by more than one site in the sample. A descriptor that narrowed to one business would be a name with extra steps. Slugs are assigned by score rank within a vertical, deliberately not by the order of the site list.

Where the numbers came from #

The report pages render a committed file; they never re-score anything. That file carries its own provenance, so a claim on a page can always be walked back to the run that produced it.

{
  "experiment": "Experiment 1 — technical spike: can we map real sites? (docs/02-validation-sprint.md)",
  "scanner": "agent-readiness-scanner v0.1.0",
  "scannedAt": "2026-08-25T10:42:04.906Z",
  "sites": 15,
  "scanned": 15,
  "failed": 0,
  "politeness": "Read-only. Sequential, 2000ms between sites, 45000ms per-site timeout. No form was filled and nothing was submitted.",
  "artefact": "packages/scanner/benchmark/reports/"
}