A signal's lifecycle: new, seen, actioned, resolved, parked

What this article is for

Every signal Verinode raises, a job gone quiet, a carrier balance aging past normal, a certification about to lapse, lives as a single row that carries a status. That status is the whole story of what happened to that observation: whether you have looked at it, whether you acted, whether you set it aside, whether it closed out with a dollar figure attached. This article is the reference for that status model itself: the six values it can hold, which of them still count as open work, how a signal quietly times out, and how closing one out with an outcome is what actually feeds the learning loop.

For what a signal is and where you work them day to day, see signals overview, the Feed, and the decision workspace. This article is the plumbing underneath those surfaces.

The six statuses

A signal's status column holds exactly one of six values at any moment:

• new: freshly detected. Nobody has acted on it, parked it, or dismissed it yet. This is the starting state for every signal, the moment a detector first writes the row.
• seen: acknowledged but not acted on. A signal moves here when you give it a light touch, a "noted" tap, without committing to a plan or ruling it out. It is functionally still waiting on you, just no longer brand new.
• actioned: you took a real action on it, opened a plan, started working it, or told IQ to draft something. Verinode stamps actioned_at the moment this happens, and that timestamp is what "Acted on [date]" reads elsewhere in the product (see closing a decision and recording its outcome).
• parked: you told Verinode "not now" and gave it a reason. A parked signal leaves your active view and comes back on its own once a resurface condition fires, a fixed clock for the first few parks, then only when something in your business actually changes. The full mechanics, the reason picker, the resurface schedule, the badge that marks a returning card, live in not now, parking, and dismissing cards.
• dismissed: closed out with no further tracking. You told Verinode this doesn't need attention, or the system quietly closed it because the underlying condition it was raised for went away on its own. Two different paths land here; see below.
• resolved: closed out with a verified outcome attached, what happened and, where one applies, a realized dollar figure. This is the only status that feeds the network's learning loop and rolls into your impact totals.

Which statuses count as "open"

Verinode's own codebase treats four of the six statuses as still-open work: new, seen, actioned, and parked. Only dismissed and resolved are treated as closed. This single rule is what every detector checks before it decides whether to update an existing signal in place or raise a brand new one, and it is what the Decisions workspace's status filter reduces to underneath its five pills:

| Signal status | Open? | Shown on Decisions as | |---|---|---| | new | Yes | Pending | | seen | Yes | Pending | | actioned | Yes | Acted | | parked | Yes | Parked | | dismissed | No | Ignored | | resolved | No | Resolved |

Notice new and seen collapse into one pill, Pending. You will never see "seen" as its own filter option on Decisions, it is a finer-grained distinction that matters to the underlying data (and to the small status word shown on a signal row inside an entity's own Signals panel, see signal count badges on entity cards) but not one you need to filter by day to day. The Pending count on that filter, and the matching badge count in the sidebar next to Decisions, is this exact new-plus-seen total.

A broader definition, for badges and entity panels

The signal count badge on a vendor, job, client, or carrier card, and the Signals panel inside that record's own detail view, use a looser rule: they drop only dismissed signals (plus anything expired, below). That means a badge or an entity panel's count includes resolved signals alongside new, seen, actioned, and parked ones, so a record you've already closed something out on doesn't just quietly disappear from its own history. The inline signal cards embedded directly on a domain page (Vendors, Equipment, and so on) are narrower again: they drop both dismissed and resolved, showing only what's still genuinely unresolved. Three different reads of the same six statuses, each tuned to what that surface is for: the badge answers "does this record have history," the domain page answers "does this record need something from me right now."

Expiry: the second way a signal stops showing up

Status is not the only thing that determines whether a signal is still visible. Every signal also carries an optional expires_at timestamp, set by the detector for anything genuinely time-boxed, a weather alert, a seasonal pattern, a window that will not matter once it passes. Once that date is in the past, the signal drops out of every current read (your Feed, the entity badge, the domain panels) regardless of its status. A signal can still technically say new in the database and be invisible everywhere you'd normally see it, because nobody ever interacted with it and its window simply closed. Signals with no expires_at never age out this way; they stay visible until you, or the condition itself, resolves them.

One-way doors: dismissed and resolved don't reopen

Resolving or dismissing a signal closes that specific occurrence for good. If the same underlying condition shows up again later, the same job goes quiet a second time after you already resolved the first stall, the same vendor's spend drifts again after you dismissed the earlier pattern, Verinode raises a brand new signal rather than reopening the old row. The new row starts its own clock: its own first_detected_at, its own status at new, no memory of the one you already closed. This is deliberate: a detector's own dedup check only looks at open statuses (new, seen, actioned, parked) to decide whether to update an existing row in place instead of duplicating it, so once a row leaves that open set, the next occurrence is treated as its own event.

Two ways a signal becomes dismissed

"Dismissed" looks identical on the surface, an Ignored pill on Decisions, no further tracking, but it is reached two different ways, and only one of them changes how Verinode treats similar signals going forward:

• You dismiss it. Tapping Ignore on a Feed card, or the equivalent on the Decisions workspace, stamps ignored_at on the row alongside the status change. That stamp is what feeds Verinode's dismissal-based suppression: dismiss the same kind of signal on the same record once, and it stays quiet for a period; dismiss it twice, and the quiet period extends; dismiss the same signal type repeatedly across your book within a shorter window, and the whole type goes quiet for a stretch. Critical-severity signals and onboarding milestone cards are exempt from this suppression on purpose, since those should never go quiet just because you dismissed something similar before.
• The system dismisses it. Some detectors close their own superseded signals directly, for instance when the condition a signal was raised for clearly no longer applies, without any operator interaction. These system-closed rows carry no ignored_at stamp and never feed the suppression logic above, because no feedback was actually given.

Outcome and recovered-dollar capture: how the loop closes

Two columns carry the payoff of all this: outcome, a category describing what actually happened, and outcome_value_cents, the realized dollar figure where one applies. Both get written at the same moment a signal's status flips to resolved, alongside a resolved_at timestamp. Until that moment, whatever dollar figure a signal carries is only an estimate; resolving it is what turns an estimate into a verified number.

There are two paths to that moment:

1. You close it out. Working through a plan, or deciding not to act at all, ends in the Outcome section of the decision workspace: pick what happened, optionally correct the dollar figure to what actually landed, rate whether the recommendation was useful. This is the full mechanic, and it is documented in detail, the three phases (Executing, Measuring results, Verified), the one-tap Feed shortcut, the close-out dialog's fields, and exactly what gets written where, in closing a decision and recording its outcome.
2. Verinode proposes it, you confirm it. For some signals, IQ independently notices that the metric behind a decision already moved the way it should have and offers a one-tap Confirm win in the Decisions log instead of the full close-out flow. Confirming still writes the same outcome record and still flips the source signal to resolved, it is simply a shortcut for the cases where the proof already speaks for itself.

Either way, only a resolved signal with a real closed reason behind it counts toward the totals you see elsewhere: the annualized impact addressed on your Decisions log, and the per-operator and network learning aggregates that shape how IQ weighs similar recommendations for you next time. A signal that is dismissed instead, even one dismissed straight from the Feed (which does stamp an internal "dismissed from Feed" outcome marker so the row isn't left blank), never carries a realized dollar figure and never feeds that learning loop the way a genuine resolution does. Parked, actioned, new, and seen signals carry no outcome at all yet, because none of them represent a closed loop.

Best-practice example

A carrier's balance has been aging slower than that carrier's own average for three weeks straight. The first night it crosses the threshold, Verinode writes a new signal. You see it in the Feed the next morning and tap Noted while you finish the call you're on, it moves to seen. Two days later you actually call the adjuster and open a follow-up plan, it flips to actioned and stamps that date. The carrier settles the balance a week after that; you open the decision, confirm what happened in the Outcome section, and it resolves with a realized dollar figure attached, which rolls into your impact total. Three months later that same carrier's balance drifts again. Because the earlier signal is resolved (no longer in the open set), this shows up as a brand new signal with its own fresh new status, not a reopened version of the one you already closed.

1. 1Read a signal's status as where it sits in your workflow (new through resolved), and its severity as how urgent it is, the two are independent.
2. 2Use the Decisions Pending / Acted / Parked / Ignored / Resolved filter to triage; remember Pending quietly covers both new and seen underneath.
3. 3Park what you'll genuinely come back to; ignore what you won't. Only parking sets up a resurface condition.
4. 4Close a decision out through the Outcome section, or confirm a proposed win, once you know what happened. That is the only path that produces a verified dollar figure and feeds the learning loop.
5. 5If the same condition returns after you've resolved it once, expect a fresh signal, not a reopened one, and treat it on its own merits.

Related reading

• Signals overview
• Signal count badges on entity cards
• The Signals panel on a vendor, job, client, or carrier
• Not now, parking, and dismissing cards
• Closing a decision and recording its outcome
• The decision workspace
• The Feed
• Acting on decisions
• Clients and carriers

Data sources