Every recommendation arrives with its receipts.
This is the structure of a Revvye report before a customer scan supplies the evidence. Nothing here is scored, estimated, or presented as a business result.
Scores and findings render only from observed scan evidence.
A finding is not a headline. It is a chain of inspectable claims.
No verdict exists until the scan engine completes.
- Evidence
- Pending
- Severity
- Pending
- Confidence
- Pending
The report can only say what the instrument can show.
Each named check maps to scanner code, an observable source, a severity range, and an explicit limitation. The report adds judgment and ordering without pretending public-page evidence is private revenue analytics.
From observation to a verifiable next move.
- 01Observed signal
What the scanner actually found
A public URL, response, element, header, or machine-readable signal stays attached to the finding.
- 02Buyer-path consequence
Why the signal deserves attention
The report names the customer action at risk without presenting an estimate as measured revenue.
- 03Fix direction
What should change next
Plain-English direction turns the evidence into an ordered action, not another generic audit list.
- 04Verification
How to prove the change worked
Re-scan the same public path and compare the same observable signal after the fix ships.
Proof first. Paid depth only after the result exists.
The free result establishes whether Revvye found anything worth pursuing. The report unlock adds depth to that same scan instead of selling a detached template.
Score, strongest visible findings, and their severity
Complete finding register, evidence, fix direction, and ordering
Rule identity, observed source, limitation, and re-scan protocol
Want to inspect the system before scanning? Read every published rule and limitation →