How to run a scan, read what comes back, and know what the numbers do and don't claim.
The form is four decisions, in order.
example.com, not a URL and not an IP. Enter several
(one per line, or comma-separated) and each gets its own independent scan;
one failing never affects the others.
Scans run two at a time; the rest queue. A queued scan can be cancelled before it starts, and cancelling a running one stops its tools rather than just abandoning them.
This is the distinction the tool is built around, and the only one it enforces in code.
| Tool | Method |
|---|---|
{{ info.display_name }} |
{{ info.default_method }} |
Only scan what you own or have written permission to assess. That constraint is yours to honour — the tool records your stated basis but cannot check it.
Every scan produces one page, split in two. Top priorities is the highest-ranked {{ top_n }} findings, each with a sentence on what it is, why it ranked there, and which tools saw it. Also found is everything else — sortable, filterable and searchable, because on a large target it runs to hundreds of rows.
The split is by score, not importance-in-general: a finding lands in the tail because nothing about it scored, which is not the same as it being irrelevant to you. The filters exist so you can go looking.
Ranking is computed in code, never by a model. Each finding accumulates points from signals that either did or did not fire; the total is its priority. Hovering a score in a brief shows exactly which signals produced it.
That is the whole rubric, below — there is no hidden component, and the same input always produces the same ranking.
| Signal | Weight | Means |
|---|---|---|
{{ s.name }} |
{{ "%+d" | format(s.weight) }} | {{ s.phrase }} |
Negative weights are deprioritisers — a renewed certificate or a host that stopped resolving is recorded, but pushed down rather than dropped.
Every finding names the tools that reported it under Seen by. Those are links: following one opens the exact record in that tool's archived output that produced the finding — not the whole file, the line.
That is the point of the tool. If a finding looks wrong, you can see what it was derived from without re-running anything.
Any scan with an earlier run of the same target offers Compare to previous scan: what is new, what disappeared, and what changed score or signals since last time. Findings are matched by identity, not position, so a host that moved rank is not reported as a new discovery.
glean eval reports faithfulness, provenance retention and prioritisation
quality. Two of those need reading carefully.
Content-level fabrication — a real entity described with a false claim — is measured only
by stage 2, which needs --llm and uses a second model as a judge. That
judge makes real mistakes of its own, so its score is a lower bound rather than an exact
figure. A real narrated brief has scored 1.000 on stage 1 and 0.455 on stage 2
for the same text.
How loose a lower bound is measured, not guessed. Scored against 90 claims labelled by hand, the judge flagged 28 as unsupported where a person found 9 — it catches most real problems (recall 0.778) but over-flags roughly three to one, so about three quarters of what pulls stage 2 down is judge error rather than fabrication. The mistake runs in the safe direction: the number never makes the prose look better than it is.
Three later audits moved that a long way, ending at flag precision 0.800. Each swing traced to how the evidence was presented or what got scored, never to the judge's reasoning — the last fix simply stopped counting "claims" the judge had copied out of its own evidence rather than read from the brief. The safe direction holds throughout, so read stage 2 as a floor rather than a figure, and check ADR-0006 for which audit a given number came from.
Both limits are stated in the tool's own output rather than left to documentation, because the numbers are what gets pasted into a report.