How verdicts are computed

Last updated: September 2026

A security finding is only worth as much as the answer to two questions: what was actually read, and what was it compared against. This page answers both, and describes the mechanism rather than the intention — where the two would differ, what follows is the mechanism.

The model does not decide anything

The load-bearing part of an answer — the verdict, the status of each step in an attack path, the counts and the citations — is rendered from engine data before the model is called, and it is emitted to you exactly as rendered. The model is then given a bounded job: narrate what is already there, without restating it. It never rewrites the verdict, and it never supplies one.

This is a structural choice rather than a filter. A system that lets a model write the verdict and then inspects the prose for mistakes can only catch the mistakes it thought to look for. Rendering the verdict first makes whole categories of error impossible to emit: the verdict comes from the engine's own status field, the grounding is the set of confirmed findings, the counts come from the finding records, and citations are rendered from a catalogue. Any sentence the model produces that states a verdict of its own is removed before you see it, whether it agrees with the computed one or not — because a model that happens to agree today is not a model that can be relied on to agree tomorrow.

The same rule is enforced once more at the boundary where a response leaves the server: a value that looks like a verdict must carry the mark that only the gate applies. An unmarked verdict is refused rather than served.

What a verdict is compared against

Every property name we ship is checked against a version-pinned sys_properties capture from a live Personal Developer Instance, and every table reference against a full sys_db_object capture — not generated from training data. The property pins are Zurich Patch 6 and Zurich Patch 10 PDIs (3,585 and 3,595 properties, each capture archived): the 90 verified system properties are distilled from the Zurich Patch 6 capture, and an instance is verified against the capture that matches its own build — a build no capture covers is said so, not assumed. Table existence is checked against a 6,419-table capture from a Australia Patch 3 PDI. The 143 per-table field catalogs we ground answers on are compiled from our own checks and detection scripts; they are a catalog, not a PDI capture, and a table they name that no capture confirms is reported to you as unconfirmed.

The pin is deliberately not the newest release. Australia has been GA since May 2026 and our baseline has not moved to it yet, so we name the release we actually tested rather than the newest one. Naming only the current release would imply our verification tracks general availability; it tracks a live instance we can re-query, which is a slower and more defensible thing. Identifiers outside that capture are either verified separately against a live instance and cited, or not shipped.

A verdict that cannot be held at full confidence says so rather than quietly softening. If your instance is on a build no capture covers, or the last reading of it could not be confirmed, the verdict is capped and the reason travels with it — including how long ago the reading was taken.

The five rules

R1 · Confidence expires. An instance reading is good for 24 hours. Past that the verdict downgrades itself and prints the reading’s age, because a refresh that could not run and one that never happened are the same position to be in.

R2 · The AI never decides. Verdicts are computed by rule before the model writes a word, and verdict-shaped prose is stripped out of what it writes afterwards.

R3 · It refuses rather than guesses. An advisory we do not track returns “not a tracked CVE id as of <date>” — never “no known issue”. An absence of evidence is reported as an absence, not as a clean result.

R4 · Claims withdraw themselves. A rule change supersedes every verdict decided under the older rules. The dashboard asks for a re-scan and names the version; it never just goes quiet.

R5 · Mappings are dated. Every regulatory citation names its reviewer and the date it was read — or says plainly that nobody has reviewed it.

How a regulatory mapping is qualified

Saying a finding maps to an article of NIS2, DORA, ISO 27001 or NCA ECC is a claim about a regulation, and it is not one a scanner can make on its own. So every mapping carries its own review state, and the state is shown next to the citation rather than buried in a methodology note.

Unattested. The mapping exists and nobody has reviewed it. It renders with the tag (unattested) and it caps the verdict it supports at conditional.
Attested. A named reviewer has read that specific mapping and recorded the decision in an append-only log. What this guarantees is a name and a date, not a signature — a signature is something a person puts on a delivered document, and this page will not blur the two.
Expired. A review is good for a year. Past that the citation reads (attestation expired on …) with the date it was last read, and it caps the verdict exactly as an unreviewed mapping does. A framework whose reviews have all expired is treated as unreviewed at the document level, which is the conservative reading.
Not registered. Where no record of the underlying instrument exists to check against, the citation says so instead of implying one was checked. This also caps.

Two further details, because they are the ones that decide whether any of this is worth anything. The unit is a single rule-to-control mapping rather than a control, so attesting one rule's view of a control does not attest another's. And the control's own title is part of what a reviewer signs off: rename the control and the mapping returns to unattested, deliberately, because a renamed control is a claim nobody has actually read.

We do not pre-attest mappings to make a dashboard look finished. A mapping is reviewed when a customer needs it reviewed, and until then it says, on its face, that it has not been.

When we cannot read something

If we can't read it conclusively, the verdict says so — silence is never rendered as good news. A check whose underlying probe did not run is reported as not assessed, and no surface infers a pass from the absence of a finding. This is the single rule most of the others are a consequence of.

What we read from your instance, who else is involved, and how credentials are held are a different subject with their own page: access and data handling.