Why a dismissed signal stays quiet (and when it comes back)

When you click **Ignore** on a decision, that click is feedback: you are telling Verinode this particular observation is not useful to you right now. Before this logic existed, that feedback went n…

9 min read·Updated July 13, 2026
On this page

Why this exists

When you click Ignore on a decision, that click is feedback: you are telling Verinode this particular observation is not useful to you right now. Before this logic existed, that feedback went nowhere. Every detector that runs each night excludes dismissed rows from its own duplicate check, so nothing was stopping the same detector from writing the same signal right back the next night. Dismissing something and watching it reappear a day later is the fastest way to stop trusting a tool. This article covers the rule that fixed that: a per-operator dismissal history that puts a real, time-boxed cooldown on a signal you have said no to, plus the safety valves that make sure a genuinely urgent or one-time-setup card is never the thing that goes quiet.

This is entirely a background rule. There is no settings toggle and no page to configure it: it runs automatically, inside Verinode's data pipeline, every time a detector is about to write a signal to your account.

Verinode does not decide what matters to your business, you do. This rule exists so that decision sticks, at least for a while, rather than being silently overridden by the next detector pass.

Where you feel it

You will not see a "suppression" screen anywhere in the product. You feel this rule in three places:

  • On the Feed (/feed), when you swipe or click Ignore on a decision card, it flips to a brief Dismissed confirmation with an Undo link, then leaves the deck. That single click is what starts the cooldown described below.
  • On Decisions (/decisions), the Ignored status filter pill shows every decision you have dismissed. Selecting a row that is still dismissed shows a single Restore button in place of the usual Act / Not now / Ignore trio.
  • Indirectly, by absence: a signal type you have dismissed a few times simply stops showing up for a while, on any entity, even though the underlying condition in your data has not changed. That absence is the suppression rule working as intended, not a bug.

See the Feed and the decision workspace for how these surfaces work day to day; this article is specifically about what happens after you click Ignore.

Note

"Dismiss" here means an operator clicking Ignore (on a Feed card or a Decisions tile), or the equivalent bulk-dismiss action available to a Verinode analyst reviewing your account. It does not include a signal that Verinode's own housekeeping closes out on your behalf, for example when a detector supersedes its own stale signal, or a reputation-tracking cleanup routine closes a disconnected record. Those system closures never start a cooldown, because you never said "no" to them, Verinode just tidied up after itself.

The three cooldown tiers

Every dismissal is logged against two keys: the signal's type (for example, a vendor renewal-price alert or a slow-payer carrier warning) and the specific entity it was about (a named vendor, carrier, or client). Before a detector writes a new signal, it checks your dismissal history against three tiers, in order. The first one that matches wins.

  1. 1Exact cooldown, 30 days. You dismissed this exact signal type about this exact entity once. That combination stays quiet for 30 days, counted from the moment you dismissed it.
  2. 2Repeat cooldown, 90 days. You dismissed that same (signal type, entity) combination twice or more. Verinode treats the second no as a stronger signal than the first and extends the quiet period to 90 days from your most recent dismissal of it.
  3. 3Type cooldown, 30 days, whole type. You dismissed the same signal type three or more times across different entities within a rolling 90-day window, for example, ignoring a "renewal price spike" alert for three different vendors. At that point Verinode stops writing that signal type at all, for any entity, for 30 days from the last of those dismissals.

All three tiers only look back 180 days. A dismissal older than that has aged out of your history entirely and cannot extend or restart a cooldown.

Tip

The entity key usually means the specific vendor, carrier, or client record the signal named. A small number of AI-generated coaching cards from Verinode's reasoning engine don't carry a structured entity link, only a name in the card text (for instance, a vendor named only in the card's copy). For those, Verinode keys the cooldown off that name instead, so dismissing a card about one named vendor quiets alerts about that vendor specifically, not the whole mechanism behind every such card.

What never gets suppressed

Two categories skip all three tiers entirely, no matter how many times you have dismissed similar cards:

  • Critical severity. A signal marked Critical is, by default, treated as a safety or compliance escalation and always surfaces. The one nuance: a small subset of critical cards come from Verinode's reasoning engine rather than a rule-based detector, and on those, "critical" is a priority label the engine assigns to its most urgent recommendation, not automatically a safety class. For that subset, only cards in the Safety, Compliance, or Certifications areas keep the blanket exemption; a critical-labeled cashflow or margin card from the engine still gets a normal cooldown if you dismiss it. Every rule-based detector's critical output (the large majority of critical signals you will see) is exempt outright.
  • Setup signals. Onboarding milestone cards, prompts like uploading your logo and brand color, or setting up email forwarding so vendor invoices and carrier mail start flowing in automatically, are navigational, not analytical. Dismissing one does not start a cooldown, because there is nothing to re-detect: it is a one-time nudge to finish setting up the platform, and it should keep nudging until you do it or it naturally expires.

The escape hatch: when a re-raise breaks its own cooldown

A small number of decisions come from Verinode's reasoning engine and carry a specific dollar estimate. If you dismissed one of those and the underlying number has since grown substantially (at minimum, about half again as large as the biggest dollar figure you dismissed), the engine is allowed to raise it again even inside an active cooldown. The idea is that "no, this isn't worth my attention at $8,000" and "no, this isn't worth my attention at $30,000" are different decisions, and Verinode should not quietly sit on the second one because you declined the first.

When that happens, the card that comes back is stamped with a visible acknowledgment rather than pretending it is brand new. Open that decision in the workspace and you will see a line like:

You passed on this on [the date you dismissed it]. It's larger now.

(or Raising it again. when the escape hatch fired for a reason other than the dollar growing, such as the cooldown window simply lapsing.) This line only appears on engine-authored decisions with a matching prior dismissal; rule-based detector signals do not carry it, they simply wait out their cooldown quietly and reappear without commentary once it expires.

Recurrence: how many times has this actually shown up

Separately from suppression, every signal carries a recurrence count, how many detector passes in a row have found the same underlying condition still true. The first time a detector notices something, the count starts at 1. Every subsequent nightly pass that finds the same condition still present on the same entity bumps the count by one and refreshes the signal's last-seen time, rather than writing a duplicate row. You will see this surface on the back of a Feed card, in the reasoning view, as a line reading "Based on N data points." A higher number means Verinode has now watched this pattern hold up across more passes, not that anything new has been added; it is corroboration of the same finding, not a growing pile of separate incidents.

Recurrence and suppression are independent. A signal can recur for weeks while you have never touched it (climbing count, no dismissal, no cooldown), or you can dismiss a signal the very first time you see it (count still at 1, cooldown now active). The two numbers answer different questions: recurrence asks "how long has this been true," suppression asks "did you tell Verinode you don't want to hear about this."

Restoring a dismissed signal ("unignore")

If you change your mind, or you dismissed something by mistake, you have two ways back:

  • Right after dismissing, on the Feed. The card briefly shows Dismissed with an Undo link before it leaves the deck. Clicking Undo puts the card back exactly as it was and, just as importantly, erases the dismissal from your history entirely: it is as if you never clicked Ignore, so it does not linger as a data point toward a future repeat or type cooldown.
  • Any time after, on Decisions. Open /decisions, select the Ignored status pill, find the row, and click the single Restore button on its tile. This flips the signal's status back to open, clears any recorded outcome, and, like Undo, removes it from your dismissal history going forward. A restored signal is not on probation: the next time a detector evaluates it, it is judged purely on your current data, with no memory of the earlier dismissal held against it.

Both paths do the same underlying thing: a dismissal only counts toward a cooldown while its status is still "dismissed." The moment you restore it, whether seconds later with Undo or weeks later from the Ignored list, that history entry no longer matches any cooldown check, and the signal is free to fire again the next time your data warrants it.

Heads up

Restoring a signal does not "un-happen" the time that passed. If the condition it originally flagged already resolved on its own (the job resumed activity, the balance got paid, the certification renewed), restoring it just reopens a decision about something that is no longer true. Check the current state of the underlying entity before you act on a freshly restored card.

Empty states

There is no dedicated screen for suppression or recurrence, so there is no empty state to describe for this rule specifically. What you will notice instead:

  • A signal type you have dismissed several times simply does not appear for a while. This is not a broken detector, it is the type-level cooldown in effect.
  • On /decisions, filtering to Ignored with nothing dismissed yet returns an empty list; the list fills in only as you click Ignore on cards.
  • A Feed card without a recurrence line ("Based on N data points") simply has not been re-detected on a later pass yet, or came from a source that does not track recurrence (content and event cards, as opposed to decisions).

Best-practice example

You dismiss a "vendor spend above peer network" alert for one tarp-and-board vendor. Nothing changes for 30 days, that vendor and signal type stays quiet while every other vendor alert keeps flowing normally. A month later the same vendor's rate drifts even higher and the alert reappears, because the cooldown lapsed. You dismiss it again. Now it is quiet for 90 days, since this is the second no on that exact pairing. Separately, over the same stretch, you also dismiss three different "certification lapse" alerts for three different team members within a couple of weeks of each other. Because that crosses the type-level threshold, Verinode stops surfacing any new certification-lapse alert, for anyone, for 30 days from the last of those three. When your safety officer's hard-hat certification actually lapses two weeks into that window, you still see it, because certification-lapse alerts marked Critical are exempt from suppression entirely.

Data sources

  1. 1.pii.signals (status, ignored_at, recurrence_count, severity, domain, evidence.re_raise_of). Your business.
  2. 2.lib/signals/suppression.ts (cooldown policy, exemptions, material-escalation escape hatch). Verinode platform logic.
Was this helpful?