Findings and their lifecycle

Anatomy

Every finding has a scope (site, template, page), a category (access, technical, content, entity, citability, intent gap, trust, i18n, commercial), a severity, a summary with the site-specific evidence inline, a recommendation, the evidence it rests on (URLs, chunks, metrics, simulation results), the knowledge-base hypotheses it cites with their grades, and three numbers: confidence, impact and effort.

Three sources

• Deterministic — rules over the crawl data: access refusals, JavaScript dependence, content-use policy signals, snippet directives, duplicate content, sitemap composition, canonical and hreflang integrity, structured data, performance. Evidence-bearing and aggregated to the right scope.
• Simulator — derived from the retrieval simulation: uncovered intent classes, cannibalisation, never-retrieved pages, cross-language leakage.
• Agents — seven specialists (access, citability, entity graph, intent coverage, technical architecture, internationalisation, commercial) reasoning over a pre-aggregated dossier of everything above.

Review

An adversarial reviewer sees every candidate and tries to discard it: unsupported by the evidence, a hypothesis that does not apply to this site, wrong scope, a duplicate, or generic advice. Only survivors reach the report. The discard count is shown; a healthy run rejects roughly half.

Lifecycle

Findings carry a stable key derived from category, scope and title, so the same finding in the next run is recognised as the same finding. Statuses you set — accepted, implemented, won’t fix — carry over. A finding that no longer fires is reported as resolved; one that appears for the first time as new. The site’s run history shows both per run.

The intended loop is: a finding is implemented → the next run verifies whether the named metric moved on the named cohort. Automatic verification against control cohorts is on the roadmap; today the run history gives you the before-and-after.