Dispositions - What Your Not Real Click Actually Does

Every alert in Burrow carries three disposition buttons in its drill drawer: Real, Not real, Maybe. The click is one second of work but it feeds two downstream systems — the tuning advisor that watches your team's dismissal patterns, and (optionally) an auto-suppress feature that turns repeated dismissals into silenced alerts. This article walks each effect so you can use dispositions deliberately.

Where the buttons live

Open any alert on the Alerts page. The drill drawer opens on the right. At the bottom of the drawer are the three disposition buttons.

The choice is recorded against the (user, category) pair for the alert. It is visible to the next SOC shift looking at the same alert, and it is logged on the History page with timestamp, your analyst identity, and before / after state.

What "Real" does

• The alert is marked Real on the Alerts page and counts toward the dashboard's triage donut.
• Feeds the daily pattern detector. Real alerts weight more heavily than dismissed ones toward the daily escalation summary that may emit later.
• Logged on the History page.

Use it when you have validated the alert is genuine and want to keep the signal flowing.

What "Not real" does

Marking an alert Not real does not by itself stop future alerts of that kind. The disposition is a vote — Burrow watches the pattern of votes and proposes (or applies) tuning changes after a threshold.

Three things happen on every Not real click:

1. The alert is marked Not real on the Alerts page and counts toward the dashboard's dismissed slice of the triage donut.

2. The disposition is recorded against the (user, category) pair and logged on the History page.

3. The tuning advisor reads the dismissal. Once the same (user, category) pair has been marked Not real three or more times in the last 14 days, a new suggestion appears at the top of the Rules page:

   Add exception for bob.smith@example.com on unusual_hour_activity (dismissed 4 times)

   Clicking Apply on the suggestion adds the entity exception via the existing Apply mechanism. Future alerts of that (user, category) pair stop firing. See Tuning a noisy rule for the full suggestions workflow.

This is the default behaviour. Dismissals build evidence; an operator clicks Apply to enact the silencing. Nothing is silently suppressed.

Separately from the dismissal-pattern feedback loop, the AI's own verdict on each alert (the AI · YES / NO badge in the drawer) now drives the Alerts page filter directly. An alert the AI judges not real is auto-filed under the Dismissed tab and hidden from the default Active queue — so you do not have to dismiss them one by one. The operator override always wins: if you set Acknowledged / Investigating / Escalated on an AI-dismissed alert, it returns to those tabs and stays visible until you close it.

What "Maybe" does

• The alert is marked Maybe and stays open for the next shift.
• No tuning-advisor input, no daily-pattern weighting change.
• Logged on the History page.

Use it when you don't have enough context to call it today and want to defer.

Opt-in: auto-suppress without waiting for Apply

For mature SOC teams that want the noise reduction without the click, an opt-in Dismissal auto-suppress feature applies the same 3-in-14-days threshold automatically — no Suggestion review, no Apply click. Future alerts of the matching (user, category) pair are suppressed (or downgraded) directly.

• Default state: off. Burrow always requires an operator click to silence anything unless this is explicitly enabled.
• How to enable: Settings → Dismissal auto-suppress, or via support if the UI is not yet wired in your deployment.
• Audit trail: every auto-suppression is journaled in the suppression journal with reason auto_dismissed_pattern (or auto_downgraded_pattern if you chose the downgrade action). The exception itself appears on the Exceptions page marked with a "dismissal pattern" source so you can later distinguish auto-applied ones from manually-added entries.

For the full opt-in workflow — when to use it, when not to, how to tune the threshold — see Dismissal auto-suppress.

How to undo a dismissal-driven silencing

Whether the silencing was applied by your click on a Suggestion or auto-applied by the opt-in feature, the result is an entity exception on the Exceptions page. To undo:

1. Open the Exceptions page.
2. Find the entry for the (user, category) pair. Dismissal-derived entries are tagged with "dismissal pattern" as the source.
3. Click Delete.

Future alerts of that pair fire normally on the next detection pass. The History page records the deletion with your analyst identity.

To turn off the auto-suppress feature entirely (so future dismissal patterns produce Suggestions only, not automatic silencing): Settings → Dismissal auto-suppress → toggle off.

When to use Real vs Not real vs Maybe

• Real — you have confirmed the activity is genuine and material. Keep the signal.
• Not real — you have confirmed the alert is a false positive (legitimate user, expected behaviour, known noisy account). The first dismissal does nothing on its own; the pattern across multiple dismissals is what produces the eventual silencing.
• Maybe — you do not know yet. Defer to the next shift.

When to add an exception directly instead

If you already know on the first alert that a specific (user, category) pair is permanent noise — a service account, a known scheduled job, a vendor automation that always trips the same rule — skip the dismissal cycle and add an entity exception directly. The dismissal threshold is for discovering false-positive patterns; once you know a pattern is false, add the exception immediately.

See also

• Tuning a noisy rule — including dismissal-driven suggestions.
• Entity exceptions — the underlying mechanism the Suggestions panel and auto-suppress use.
• Dismissal auto-suppress — the opt-in tier 2 feature.
• Investigating an alert — the workflow that produces the disposition click.

Need help? support@smikar.com.