Reading a Sentinel-Q decision

Start with the findings and next step

Open AI investigations and decisions. Use Needs your review to focus on decisions waiting for a person, then open a row to read the full findings. Reviewed means the activity was assessed; Recommendation ready means a response was suggested; Action selected means a response was chosen, but you still need to check its action result; Needs your review means the system needs your judgment. None of these labels alone proves that a device or account was changed.

The list refreshes in the background while the page is visible. Read what happened, what evidence supports it and the recommended next step. Technical scoring details are collapsed so you can focus on the explanation first. Use Agree, Disagree or Request review to respond; expand Record investigation outcome when you need to record the outcome separately. An error message means the requested change has not been confirmed.

A decision is the record of Sentinel-Q looking at one alert and reaching a conclusion. It is a database row, an audit artefact and a screen, and it is designed to be read by somebody who is not a security specialist and who has about four minutes.

This article walks the fields in the order they matter. If you read only one section, read The two questions a decision answers — most confusion about these screens comes from conflating them.

The two questions a decision answers

Read three things separately: the classification describes the response decision, the disposition describes the assessment of the activity, and the linked action result confirms whether a change actually happened. A classification or a model score is not an execution receipt.

Read the reason and evidence before interpreting a combination of labels. Observe alone does not prove that the organisation is in an observe-only tier. If a record suggests automatic execution but has no confirmed action result, keep the alert under review and report the missing evidence.

The fields, in reading order

Decision id, alert id, rule id, sensor id

The four identifiers that let you and us talk about the same object. The rule id is the one to quote if a detection is consistently wrong for your environment; the sensor id names the machine.

Classification and disposition

The two verdict fields above. Both are always populated on the agentic path.

Confidence

A number between 0 and 1, derived from the verified findings rather than reported by the model. It is recomputed from the claims that survived verification, so it is not the model's self-assessment.

Severity

The detection's own severity, inherited from the rule. It is an input to the decision, not an output of it — a critical rule can produce a false_positive disposition and often does.

Reason summary

One line, meant to be readable in a list view. It is a summary of the classification, not of the evidence.

Reason factors

The weighted contributors to the verdict, each with a code, a weight, a detail sentence and its own evidence references. Rendered as a stacked bar, normalised so the set totals 100%.

Ticket id

Present when a live-response ticket was opened. Live-response tickets default to pending_approval, so the presence of a ticket does not by itself mean anything ran.

Engine and model

Which path produced this decision: the deterministic scorer (heuristic) or a grounded investigation (agentic), and if the latter, which model. Mixed populations are the normal steady state — the cheap path handles low-severity alerts and every fallback — so this field is what makes decision quality analysable at all.

Autonomy tier

The tier that was in force for this rule when the decision was made, not the tier you have set today.

Evidence references

Evidence shown to the model and eligible for verification, in first-seen order. A result that was too large to show is recorded separately and cannot support a cited finding.

Claims

The structured findings after verification — rejected ones included. An unsupported assertion is part of the audit record rather than something quietly dropped.

Grounding report

The record of what verification did to those claims. On the decision screen it is headed Evidence check — the same thing under a plainer name, and the section below covers what it shows. The mechanism is in Why a confident answer can still be refused.

Tool calls

What the platform queried, in order. Useful when a decision looks thin: often the answer is that one lookup returned nothing.

Escalation record

Present whenever the platform handed off: the reason, a detail sentence, a needs-human flag, and what would resolve it. On the decision screen it appears under the heading What Sentinel-Q declined to do, along with two other things the decision stopped short of doing.

Auto-closed flag

Marks a decision resolved without human attention. This is the honest numerator for any claim we make about reducing your alert volume, and it is why we can publish that number rather than assert it.

Overridden by, at, action, reason

Filled in when a person has ruled on the decision. See Agreeing, disagreeing and escalating.

Created at, latency, input and output token counts, cost

The operational footprint of the decision. Present so that "what is this costing us" is a query rather than a conversation with your account manager.

Reading the factor bar

Each reason factor carries a code, a signed weight, a detail sentence and its own list of evidence references. The bar is normalised so the factors total 100% by construction — there is no hidden term and no unexplained residual. Positive weights push toward a true positive; negative ones pull away from it, and are labelled exculpating rather than being hidden as a smaller positive.

The rule the interface enforces is worth knowing, because it changes how you should read a sparse bar: a factor an operator cannot trace to evidence should not be shown to them as a reason. Only verified claims become factors. A rejected claim is not displayed as a weak reason, because an unsupported assertion rendered as a bar on a chart is automation bias in its purest form. If the bar looks thin, that is information: the investigation established little, and the confidence figure reflects it.

On the deterministic path the factors come from the alert row itself — rule severity, whether the response engine had already auto-approved, and how many alerts have fired on the same sensor in the last hour — and carry no evidence references, because there is nothing to link to beyond the alert.

The Evidence check section

Expand a decision row on Sentinel-Q → Autonomous decisions and the sections come in a fixed order: the reasoning factors above, then Evidence check, then What Sentinel-Q declined to do, then the explanation. The middle two are the subject of this section and the next.

Evidence check is the on-screen face of the grounding report. If you have heard it called the grounding check, the grounding report or verification, this is the same thing under a plainer name — the mechanism behind it is in Why a confident answer can still be refused, and this is the short view of it.

It opens with one sentence of arithmetic — 4 of 6 claims were verified against your own data. — and then lists the claims that did not verify: the statement itself, and, where one was recorded, the stated reason it was rejected. When nothing failed, the list is replaced by a single line: Every claim cited evidence that exists in your data.

Read the list rather than only the count. Two rejected claims about a detail nobody was relying on is a very different decision from two rejected claims that were the whole argument, and the ratio at the top cannot tell those apart.

What Sentinel-Q declined to do

Below the Evidence check, above the explanation, is a section headed What Sentinel-Q declined to do. It appears whenever the decision stopped short of something: the alert was escalated to a person, or it was closed without one, or an action was prepared and not run. It is the part of the screen that answers why did nothing happen, which is otherwise the hardest question to ask of an automated system.

Three shapes appear there, and only one of them is an escalation.

It was escalated to a person

The specific reason from the closed vocabulary below, a longer explanation naming the numbers involved, and — dimmed, underneath — what would resolve it. That dimmed line is the one to read first; it is the only field on the screen that tells you what to do next.

It was closed without a person

Fixed wording: Closed without a person: the verdict was false positive at or above the confidence floor on a rule set to act unattended. Reopen it with an override below if you disagree. Three conditions had to hold at once — the verdict, the confidence floor and the rule's autonomy setting — and the sentence names all three.

An action was prepared and not run

Fixed wording: Prepared an action and did not run it. Your autonomy setting asks for a person to approve it. Nothing failed and nothing was refused; your own configuration asked for you.

The escalation reason is one value from a closed list, and the screen shows it in plain English rather than as the code. Both are below, so that a reason somebody read on screen and a reason you found in an export are recognisably the same thing.

The escalation vocabulary takes each of these reasons in turn and says what is worth doing about it in the next ten minutes. Use the table above to recognise what you are looking at; use that article to act on it.

What the confidence figure means

The underlying field is a number between 0 and 1. Our house rule is that a decision should be presented as a qualitative band with its reason — Low, because sign-in geography could not be corroborated and the source was offline — because practitioners read a bare "87% malicious" as theatre, and they are broadly right to: the second decimal place implies a precision the method does not have. Two screens do not yet honour that rule and still render the bare percentage, which is a gap between what we have written down and what we have shipped. Where you are given a band and a reason, prefer them when deciding what to do; use the number when you are comparing decisions or writing a threshold. See How confident is confident for what the figure is and is not calibrated against.

Two properties of the number are worth internalising. First, it is derived, never inherited: it is recomputed from the claims that survived verification, so an unverifiable finding cannot raise it. Where citations failed, the figure is reduced in proportion. Second, on an ambiguous disposition it deliberately lands near the middle — ambiguity is not a confidence claim, and plenty of evidence pointing both ways is exactly what should produce an escalation rather than a decisive-looking score.

The limitations block

Every decision carries a standing statement of what it cannot be relied on for. These two lines appear on all of them, without exception, and they are not boilerplate to skim — the first one is the single most common way an operator misreads a clean decision.

This assessment rests only on telemetry this platform holds for your
organisation. Absence of evidence is not evidence of absence.

A threat-intel lookup that returned no match means the indicator is
unknown to the configured feeds, not that it is safe.

A third line is appended when it applies, and it is the one to look for when a decision seems more confident than the evidence in front of you:

N of M findings were discarded because the evidence they cited could
not be verified. They are recorded on the decision and are not
reflected in the confidence figure.

Further lines are appended for a decision that came from the deterministic scorer rather than a full investigation, for one produced under a cost-degraded configuration, and for one where nothing has been done to your endpoints. The block grows to fit what is true about that specific decision.

Counterfactuals: how much the verdict depends on one thing

Under the factor bar you will find a set of leave-one-out recomputations. Each one removes a single factor, re-derives the confidence, re-runs the real classifier and reports whether the outcome changes. They read as sentences: if this finding had not been established, then the decision would have been X instead of Y, at confidence 0.62 instead of 0.81.

These are computed from the stored decision, not asked of the model. A model explaining its own reasoning is the least reliable available source, because a plausible post-hoc rationalisation is precisely what a language model is best at. A recomputation of the decision function is a fact about the system that decided.

The field to look at is whether a counterfactual is marked decisive. A decision that flips when any single factor is withdrawn deserves less of your trust than one that survives the removal of each factor in turn. You may also see a threshold counterfactual — how far the decision sat from acting on its own — but only when action was genuinely permitted, because telling you "more confidence would have executed this" when the grounding check had already withdrawn execution rights would be false.

The escalation record

When the platform hands off, it records four things: the reason, from a closed vocabulary; a detail sentence naming the actual numbers involved; a needs-human flag; and what would resolve it.

That last field is the single most useful thing in a handoff, and the one a confidence score cannot carry. "Confidence 0.48" tells you the platform is unsure. "Check whether this account signs in from this country in a normal week" tells you what to do about it. Read it first.

The reason vocabulary is closed rather than free text, because a reason that can be any string is a log line and not a metric. The values distinguish between low confidence, contradictory evidence, insufficient telemetry, a novel pattern with no precedent in your history, a failed grounding check, an action your tier prohibits, a blast radius above what the tier may take unattended, an unresolved critical detection, prompt-injection text found in the telemetry itself, an investigation that submitted no verdict, and a close that is waiting on your confirmation. The plain-English wording each one gets on screen is in the table under What Sentinel-Q declined to do above.

Three checks before you trust a decision

1. Look at the engine field. A heuristic decision considered rule severity, prior auto-approval and recent alert density. It did not read the process tree, the identity or threat intel, and it says so in its own limitations block.
2. Look at the rejected claim count. A decision with several discarded findings was produced by a model that cited things which could not be substantiated on this alert. The verdict may still be right; treat the narrative with more caution.
3. Look at whether any counterfactual is decisive. A verdict resting entirely on one factor is a verdict resting entirely on one piece of evidence, and it is worth clicking through to that evidence.

When you have formed a view, record it. Agreeing, disagreeing and escalating explains what each option does, including the one that changes how future alerts on the same rule are triaged for your organisation.