Why a confident answer can still be refused

In a security product, a confident wrong answer is worse than no answer. No answer sends you to look; a confident wrong answer sends you away. So the platform does not ask the model to be truthful and hope. It makes untruth structurally unable to survive as far as your screen.

This article explains the mechanism, because you will meet it: sooner or later you will see a decision where the platform clearly reached a view and then declined to act on it, and the reason will be here rather than in the confidence figure.

A verdict whose citations did not verify never reaches the auto-execute tier, regardless of confidence or severity. That is not a heuristic applied at the end; it is checked before confidence is considered at all.

The three layers of verification

Each layer catches something the previous one cannot.

1. Shape

A finding must arrive as a structured claim carrying at least one evidence reference. Prose cannot be verified, so prose is not accepted as a finding. A paragraph asserting that an account was compromised, with nothing attached, is not a claim — it is discarded before it is scored.

2. Provenance — the ledger

The platform records every evidence reference the tools actually returned during the run, in order, with which tool returned it and on which iteration. The model never writes to that ledger. A reference the model produces that was never handed to it is off-ledger. This layer catches the most common failure mode by a wide margin: a plausible-looking identifier assembled from the surrounding text.

3. Existence

Every surviving reference is re-resolved against your organisation's own rows. This catches a bug in our own ledger, a record deleted between gathering and submitting, and any reference whose identifier belongs to a different tenant. If the existence check itself errors, the reference is treated as unresolved and the error is recorded — a verification failure is not a licence to trust the citation.

A claim keeps only the references that pass all three layers. A claim left with no surviving references is rejected — and stored, with the reason. "The model asserted this and we could not corroborate it" is exactly what an oversight regime wants written down rather than quietly deleted, and it is what makes our own hallucination rate a query against a table rather than a matter of opinion.

The three ways a citation fails

The grounding report keeps these apart, because they mean entirely different things operationally.

The fabrication rate is the share of cited references that failed verification, across all three kinds. It is recorded on every decision, so "how often does this model cite things that do not exist, for this tenant, this month" is answerable.

The grounding report, field by field

The report is persisted on the decision and included in an evidence export. You do not need to read it routinely; you need to know what it says when a decision surprises you.

On the decision screen this report is headed Evidence check — the same thing under a plainer name, shown as a ratio of verified claims and a list of the ones that failed. If you came here searching for one term and not the other, they refer to the same verification. See Reading a Sentinel-Q decision for what that section shows and when it is absent.

Total claims, verified claims, rejected claims

How many findings the investigation produced, how many survived verification, and how many did not. The rejected ones are retained on the decision.

Total references cited, valid references

The denominator and numerator behind the fabrication rate.

Malformed, off-ledger and unresolved references

The three failure lists above, each naming the specific references concerned rather than only counting them.

Fabrication rate

Failed references over total references cited, for this decision.

Ledger size and tools used

How much evidence the run actually gathered, and which tools contributed it. A tiny ledger with a decisive verdict is worth a second look; there was not much to be decisive about.

Model confidence and derived confidence

Both are kept, and the difference between them is informative. Model confidence is what the model claimed. Derived confidence is what the surviving evidence supports, recomputed by the platform. Only the derived figure is shown as the decision's confidence and only the derived figure is compared against any floor.

Trustworthy flag

Whether the verdict may stand at all. False means the decision is escalated to a human and its conclusions should not be relied on for this alert.

Action permitted flag

Whether autonomous execution is allowed on this decision. Can be false while the verdict itself is retained — see below.

Downgraded flag and downgrade reason

Whether verification changed the outcome, and the sentence explaining it. The reason names the actual numbers.

Verification errors

Any reference whose existence check could not be completed, with the error. Present so an unresolvable lookup is visible rather than silently counted as a fabrication.

What failure does to a decision

There are three distinct outcomes, in order of severity, and the distinction between the second and the third is the one worth understanding.

The verdict cannot stand

If fewer claims survived than the minimum required — the shipped minimum is one — the verdict is void. The disposition is forced to ambiguous, the confidence is set to zero, and the decision is escalated with the reason grounding_failed.

N of M claims survived evidence verification (minimum 1): verdict
cannot stand, escalating to a human

The accompanying handoff text is deliberately blunt: "Review the alert directly. Sentinel Q produced findings it could not substantiate, so none of its conclusions should be relied on for this alert." We would rather send you to the raw alert than hand you a narrative we cannot support.

Too much of the evidence failed

The second threshold is proportional. The shipped limit is a fabrication rate of 0.34 — one bad citation in three. Above it, the verdict is treated as untrustworthy and escalated, the disposition becoming ambiguous.

X% of cited evidence (N of M references) could not be verified, above
the 34% limit: escalating to a human

The verdict survives; the right to act does not

This is the case that produces the question in this article's title. A single unverifiable citation among many does not void a well-supported verdict — but it does remove autonomous-execution eligibility from that decision entirely.

N of M cited references could not be verified: verdict retained,
autonomous execution withheld

This behaviour is a setting on the shipped grounding policy, and it is on by default. We do not recommend changing it.

Why the confidence figure moves too

Confidence is derived, never inherited. It is recomputed from the claims that survived, using the same weights the decision function uses, so a finding that could not be substantiated cannot raise the number you read. Where the fabrication rate is above zero, the derived figure is reduced in proportion to it.

Claims pointing the other way subtract, at half weight. Contradicting evidence should temper a verdict rather than veto it, because most real alerts contain some of both. Neutral context counts a little rather than nothing: an analyst who pulled the process tree and found nothing alarming has learned something.

The narrative, and the marker you may see in it

The one place the model still writes freely is the explanatory narrative, which makes it the last place an invented identifier could reach you. Before the text is shown, every reference-shaped token in it is checked against the decision's verified set.

Anything not in that set is replaced with an explicit marker rather than deleted:

[unverified reference removed]

Deleting the token silently would leave a sentence that reads as though it were sourced. An operator who sees the marker learns something true. Every reference removed this way is recorded on the decision as a scrubbed reference, so a later reviewer can establish exactly what the model told the operator at the time — explanations persist for that reason and are not regenerated on demand.

What to do when you see a grounding failure

1. Treat the alert as unresolved, not as benign. A failed grounding check says the platform could not substantiate its own reasoning. It says nothing about whether the underlying activity is a problem.
2. Go to the raw alert and the tool-call list. The tool calls show what was queried. A short list often explains the failure: one lookup returned nothing and the model filled the gap.
3. Check which failure kind dominates. A run full of unresolved references is usually a retention or timing problem on our side and worth reporting. A run full of off-ledger references is a model problem, and also worth reporting.
4. Do not raise the tier to compensate. Autonomy tiers do not override grounding. A tier2 rule with a failed grounding check produces a recommendation, by design and without exception.

If a specific rule fails grounding repeatedly, tell us the rule id through How to get help. Repeated failure on one rule usually means the evidence that rule needs is not reachable in your environment, which is a fixable problem — the same class of problem described in When a check cannot run.