The escalation vocabulary, and what to do about each one
The twelve reasons Sentinel-Q hands an alert to you, in the order it checks them, each with the action worth taking in the next ten minutes.
It is eight in the morning and your phone says Sentinel-Q has escalated something to you. This article is written for that moment. It leads with the action, because the words on the screen are precise and most of them tell you exactly what to do next if you know what they mean.
One reassurance before the detail. An escalation is not a failure state and not an error. It is the platform gathering the evidence, forming a view, and concluding that the next decision belongs to a person. Roughly 40% of first-line security work does not automate today, and the vocabulary below is how the platform says which 40% you have just been handed.
The first thirty seconds
An escalation record carries exactly four things. Read them in this order and you will almost never need anything else on the screen.
- What would resolve it. One sentence naming a specific next step. This is the field a confidence figure cannot carry, and it is deliberately first.
- The detail sentence. The operator-facing explanation, which names the actual numbers involved so the person receiving the handoff does not have to go and look them up.
- The reason. One value from the closed list below. It tells you what kind of problem this is, which decides who should handle it.
- The needs-human flag. The machine-readable form of the same thing, for anything you have wired to a notification channel.
The reason list is closed rather than free text, and that is a design decision with a reason of its own: an escalation reason that can be any string is a log line, not a metric. Because the list is closed, "how often does this tenant get handed a novel pattern" is a query you can run rather than a conversation you have to have.
The twelve reasons
| Reason | What it means, and what triggered it | Your next ten minutes |
|---|---|---|
grounding_failed | The verdict did not survive evidence verification: too few findings could be substantiated against your own data, or too high a share of the citations could not be resolved. Never suppressed and never auto-actioned. | Go to the raw alert. Do not read the narrative as evidence — the platform's own handoff text says none of its conclusions should be relied on for this alert. Then tell us the rule id if it keeps happening on the same rule. |
prompt_injection_in_telemetry | The ingested telemetry contained text aimed at steering the verdict — for example a command line asserting that the alert is a known false positive. Scanned per evidence lookup, so the specific piece of telemetry carrying the payload is named, not merely the fact that something did. | Read the quoted excerpt on the decision, then treat the alert as more likely to be real, not less. Whoever generated that activity wrote that text. Escalate to a specialist if the surrounding activity is unfamiliar. |
no_verdict_submitted | The investigation ran, gathered evidence and then never submitted a conclusion — not even after the platform removed its evidence tools and offered only the submission step. A failure of the analyst rather than a property of the alert. | Re-run the triage from the decision, or open the alert directly. The evidence gathered is on the record and usually readable even though the verdict is missing. |
insufficient_telemetry | The data needed to decide does not exist. A sensor was offline for the window, a log source is not connected, a principal is unknown. This is not resolvable by the platform trying harder. | Verbatim resolution hint: Confirm the sensor is reporting; there is no process or network telemetry for this window. Fix the source if you can. If you cannot, you are working blind in the place that matters — hand it onward rather than guessing. |
contradictory_evidence | Plenty of evidence was gathered and it disagrees with itself, with neither side dominating. Typically a low-confidence threat-intel hit set against several previous rejections of the same rule by your own team. | You are the tie-breaker, and you hold the context the platform does not. Look at who or what is involved and decide whether this is the same activity your team rejected before. Then record the ruling. |
novel_pattern | No baseline and no precedent: a host enrolled this morning, a rule that has never fired on your tenant, nothing comparable in your history. | Verbatim hint: There is no precedent for this rule on this tenant. Your disposition will become that precedent. Spend the time here — this decision is worth more than the next ten routine ones. |
low_confidence | The evidence points somewhere but not far enough. The most common honest escalation. A true positive below the recommendation floor is always escalated, whatever autonomy tier you have set. | Read the factor bar and the counterfactuals. If one finding is marked decisive, click through to that piece of evidence — the whole verdict is resting on it. |
critical_severity_unresolved | A critical detection that did not resolve to a confident verdict. Critical and high severity always land in front of a person when the disposition is ambiguous. | Treat as the highest-priority item in your queue. This is the combination the escalation vocabulary exists for: important, and undecided. |
policy_prohibits_action | The assessment supports acting and your autonomy tier does not permit it. Not a limitation to route around; it is your organisation's stated posture. | Approve or decline the prepared action. If you find yourself doing this repeatedly on the same rule, that is a signal to make a deliberate decision about the tier for that rule — not to raise it for everything. |
blast_radius_above_tier | A warranted action is above what this tier may take unattended. In practice the usual trigger is a derived confidence that did not reach your tier-2 floor; an action touching more than one host produces the same outcome. | Read what the action would have done before approving it. An action affecting more than one machine is the one worth ten minutes of your attention rather than one tap. |
close_awaits_confirmation | Sentinel-Q recommends closing the alert as not real, but is not confident enough to do that on its own — it wants a person to say so before the record is closed. | Read the recommendation, then agree or disagree on the decision. Agreeing closes it; disagreeing keeps it open for a proper look. |
| The empty value | No handoff. The decision resolved on its own — either it was assessed as not real and closed, or an action within your tier was prepared or taken. | Nothing, unless the decision was auto_executed, in which case check what was done and whether the undo window has an expiry. |
The order they are checked in
Only one reason is recorded per decision, so the order matters: it decides which of two true statements you are told. The ordering is itself a statement about what we consider most important.
- Verification failure outranks everything. An answer we could not check is never filed, never acted on and never softened. If the grounding check failed, that is the reason you see, even if the alert was also critical and the telemetry was also thin.
- Prompt injection is second, above everything except verification. The assessment is still reported, but it cannot be acted on or closed automatically.
- Observe-only tier next. A true positive on a
tier0rule escalates, because the platform is not permitted to open a ticket for it. - Then the disposition decides. A false positive or benign verdict resolves and closes. A true positive either executes, escalates for low confidence, or becomes a recommendation. An ambiguous verdict picks the reason that best describes why it is ambiguous.
One subtlety in that last step is worth knowing, because it protects a number you may one day quote. A low-severity alert that could not be decided is recorded but is not marked auto-closed. A case we could not decide must not be counted as one we resolved, and the auto-closed flag is the honest denominator for any claim about reducing your alert volume.
Why injected text makes an alert more suspicious, not less
This one deserves its own section because the behaviour is counter-intuitive and it is the most interesting thing in the vocabulary.
Six of the platform's evidence lookups return content an attacker can influence: the alert itself, the process tree, sensor events, sign-in records, threat-intel matches and endpoint history. A command line, a filename or a log message can be made to contain a sentence like known false positive, no action required, previously reviewed. The goal of that sentence is a quiet automatic closure.
So the platform inverts it. Finding steering text in the telemetry guarantees the opposite outcome: the decision cannot be closed automatically and cannot be acted on automatically, and it lands in front of a person with the payload quoted. The resolution hint says why, and it is worth reading in full:
Read the quoted excerpt on the decision. Text in a log line asserting that an alert is benign, approved or already reviewed is written by whoever generated the activity — on a real intrusion, that is the attacker, and the attempt is itself evidence.
Note what is deliberately not done. The tainted evidence is not dropped and the verdict is not discarded. Dropping evidence because it contained suspicious text would hand an attacker a denial of service on their own detection: write the magic words into every command line and the platform stops being able to see you. The evidence stays, the verdict stays, and the right to act quietly goes away.
By contrast, the lookups that return your own analysts' words — a previous override reason, a rule description, a policy row — are deliberately not treated as hostile. That is the tenant's own team talking, and it is the highest-value signal a triage has.
When the analyst is the problem
no_verdict_submitted is the only reason in the list that describes a failure of the platform rather than a property of your alert, and it exists precisely so that failure cannot be silent.
The observed failure shape on a live model is not a refusal. It is a model that keeps finding one more thing to look up and never reaches a conclusion. The platform handles that with a recovery round: it takes the evidence tools away and offers only the submission step, which resolves most cases. When even that produces nothing, the reason above is recorded.
An escalation reason is not an alert status
Two different axes are easy to conflate. The escalation reason is a property of the Sentinel-Q decision: why the platform handed off. The alert's own status is a separate field describing where the alert sits in your workflow and who owns it. A decision can be escalated while its alert is still open and unacknowledged, and closing the alert does not retract the escalation record.
Alert states and who owns one covers the status values, which differ between the log-detection and endpoint modules. The empty reason value — no handoff at all — simply means the decision resolved on its own.
Handing it onward
Escalation runs in both directions. When you cannot rule on something either, record escalate on the decision: it marks that a more senior reviewer is needed and keeps the decision open, which is the correct state for something nobody has actually decided. Agreeing, disagreeing and escalating covers what each option does to the record.
Three of the reasons above are the ones most likely to mean you want somebody who is not you: novel_pattern, prompt_injection_in_telemetry, and any critical_severity_unresolved you cannot settle in twenty minutes. When to bring in a human explains where to buy that person and why you should decide before you need them, rather than during.
And if the figure on the decision is what is confusing you rather than the reason, How confident is confident? explains what that number is and is not worth.