How a network signal fires: the trip-wire

What this article is for

Signals: your network's early-warning feed and its companion articles walk through what's on screen: the hero panel, the Critical & High Severity row, By Domain, Recent, and Resolved. This one is about the mechanism underneath all of it: the exact rule Verinode's aggregator applies every night to decide whether a pattern showing up across your network is real enough to write to HQ at all. If you've ever wondered why one franchisee's bad week never shows up here, or why a pattern that looked obvious to you on a call with a member didn't produce a signal, this is the article that explains the trip-wire itself.

Nothing below changes what you see on the Signals page. It explains why what you see is there, and, just as importantly, why some patterns never make it onto the page.

Where this lives

Open Feed from the HQ sidebar at hq.verinode.ai/feed. Every row this article refers to (the hero, the severity rows, the detail panel) lives on that one page. This article has no UI of its own to walk through; it's the reference underneath the page, not a new screen.

Step 1: every membership already runs its own signals

Nothing starts at the network level. Every membership running Verinode IQ has its own signal feed, individual patterns Verinode detects in that one franchisee's own data: a margin drifting the wrong way, a carrier paying slower than usual, a certification about to lapse. Those signals live in that membership's own account, tagged with a severity of their own, Warning or Critical (a third tier, Info, covers a couple of quieter categories described further down). HQ never reads them one at a time, and it never learns which specific member tripped which specific one.

The network aggregator's whole job is to ask a narrower question across all of them at once: has enough of the network hit the same pattern, at the same severity, for this to be a network-wide finding rather than one member's week?

Step 2: who counts as "active"

Before the aggregator can measure a share of the network, it needs a denominator: how many members are actually active right now. A membership counts as active for this purpose if it has had at least one signal register any activity, of any type or severity, in the last 30 days. This is a proxy for real usage (a fuller last-active-at measure is planned), but it means the "active members" figure isn't your total membership count. A network with 60 members might have 40 active by this measure this week; the trip-wire is always evaluated against that 40, not the 60.

This matters directly: if your network currently has zero active members by this measure (a brand-new network still onboarding, for instance), the trip-wire has nothing to compare against and no network signal can fire at all that night, regardless of what's happening inside any one member's account. The hero panel's All clear state and the "No open network-level signals" line cover this case along with the more common one (a genuinely quiet network).

Step 3: the aggregator counts, it doesn't guess

Each night, for every group, the aggregator pulls every open signal (status New or Seen, severity Warning or Critical) across every active member, and groups them by signal type and severity together. A "Certification Expiring" pattern at Warning severity and a "Certification Expiring" pattern at Critical severity are counted completely separately, because they usually represent different members in different states (an expiring cert soon versus one already lapsed), each already carrying its own severity from the member's own account. The aggregator doesn't invent or upgrade a severity; it inherits whatever severity the underlying member-level signals already carry and counts each severity's reach on its own.

For each signal type and severity pair, the count that matters is the number of distinct members affected, not the number of individual signals. A member with three open cost-drift signals of the same type still counts once toward that pattern's reach. That distinct-member count, divided by the active-member count from Step 2, is the ratio: the actual share of your active network currently hitting that exact pattern at that exact severity.

Step 4: the trip-wire itself

The ratio only becomes a network signal once it clears a minimum share of the active network, and that minimum is set higher for the more alarming label:

| Severity | Minimum share of active members required | |---|---| | Warning | 30% | | Critical | 50% |

If the ratio sits below the bar for its severity, even by one member, nothing is written. There's no partial signal, no "almost fired" placeholder, and no separate lower-severity fallback: a pattern that hits 28% of active members at Warning severity simply doesn't appear on the Signals page that night, exactly as if it hadn't happened at all from HQ's point of view. The comparison is inclusive at the boundary: a ratio that lands exactly on 30% or exactly on 50% does clear the bar.

This is the deliberate design behind the whole page. A single franchisee's bad month, or even a handful of members having a rough week on the same metric, is normal noise inside a network your size, and Verinode is built to keep that noise out of HQ's view entirely. What crosses the line is a pattern wide enough that it's more likely to be something structural, a carrier's behavior changing, a shared cost pressure, a process step stalling network-wide, than it is to be coincidence. The bar is meaningfully higher for Critical than for Warning for the same reason: the more alarming the label a leadership team sees, the more of the network actually has to be affected to earn it.

What gets written once the bar is cleared

When a pattern clears its threshold, the aggregator writes one row per group, signal type, and calendar day to the network data (the same table every row on the Signals page reads from). That row carries:

• Severity: Warning or Critical, whichever bar it cleared.
• Domain: the operational area the pattern belongs to (Margin, Cash, Carrier, Compliance, and so on), the same domain taxonomy your members' own IQ accounts use.
• A network-rollup title, reframed away from any one member's language into a network statement, in the shape "N of M locations · [Pattern]" (or "All M locations · [Pattern]" on the rare night every active member is affected). The affected count here is the distinct-member count from Step 3; the total is the active-member count from Step 2, the same two numbers behind the ratio.
• Evidence, stored alongside the row: the exact ratio, the threshold it cleared, one representative example of the underlying member-level pattern (never enough to identify who), and the list of affected member IDs that powers the detail panel's affected-franchisees list.

None of this exposes a franchisee's private numbers. What HQ reads is the pattern, the count, and the share, never the invoices, jobs, or correspondence behind any one member's contribution to that count. See Signals: your network's early-warning feed for how the detail panel presents this evidence, and What HQ sees: the network privacy boundary for the boundary this all sits inside.

The nightly cron, concretely

The trip-wire is evaluated by hq-aggregate-refresh, the same scheduled job that writes every other pre-aggregated network table HQ reads from. It's scheduled every 10 minutes across a fixed early-morning window (06:00 to roughly 08:00 UTC), not as one single run: on a network with a lot of members, one invocation alone isn't guaranteed to finish every group's rollup before it hits its own time budget, so the job checkpoints its progress and resumes where the last invocation in that morning's window left off. Practically, this means a signal from tonight's sweep can land at any point across that window rather than at one exact clock time, and a very large network's signals may materialize a little later in the window than a small one's.

Each night's evaluation starts clean: the aggregator re-scans every active member's currently open signals and recomputes the ratio from scratch, it doesn't carry forward yesterday's count. Two things follow from that:

• A pattern still above its bar tonight gets a fresh row for today, distinct from last night's row for the same pattern (the write is keyed by group, signal type, and calendar day, so the same pattern recurring on consecutive nights produces a new "Detected today" tile each morning rather than silently reusing yesterday's). This is why a persistent, unaddressed pattern keeps reappearing in the Recent row day after day instead of just sitting still.
• A pattern that drops back below its bar tonight simply isn't written again. The row from the last night it cleared the bar doesn't get touched, it stays exactly as it was, with its original detected time and open status, until it's worked and marked resolved or it eventually ages out of the page's rolling 90-day window. Falling below the bar is not the same thing as being marked resolved; it just means tonight's sweep found nothing new to add.

Reading network reach against the trip-wire

Every affected-count evidence you see on the Signals page, the coverage dot grid on a tile, the "Network reach" and "Fire threshold" figures in the detail panel, is this same math shown back to you. Network reach is the ratio from Step 3, expressed as a percentage of active members. Fire threshold is the 30% or 50% bar from Step 4 that severity had to clear. Reading the two together tells you not just that a pattern is real, but how far past the line it's already spread, useful for judging urgency between two signals that both cleared the same severity.

1. 1A member's own IQ account detects a pattern and tags it Warning or Critical.
2. 2The nightly aggregator counts how many distinct active members across your network carry that same signal type at that same severity.
3. 3It divides that count by your network's active-member count to get the ratio.
4. 4If the ratio is at least 30% (Warning) or at least 50% (Critical), it writes one network signal row for that day; below the bar, nothing is written.
5. 5The row appears on the Signals page with its severity, domain, network-rollup title, and the evidence behind the count.
6. 6The next night's sweep re-evaluates from scratch: a persistent pattern gets a fresh row, a cleared one simply stops recurring.

Related reading

• Signals: your network's early-warning feed: the full page walkthrough this article sits underneath.
• Reading the network-signals hero: the summary panel built from these same open rows.
• The Critical & High Severity row: where the highest-severity fired signals live on the page.
• By Domain: grouping open signals: the same fired signals grouped by operational area.
• Cross-network signals in Take Action: the reporting-coverage signal family that uses a different rule than the trip-wire described here.
• Benchmark methodology and the privacy boundary: the equivalent deep-dive for how Benchmarks protects contributor anonymity, the closest sibling to this article's approach.
• HQ overview: how Feed fits into the rest of the HQ sidebar.
• Network health: the aggregate-only privacy boundary every signal on this page is built inside.
• HQ benchmarks: the cohort-comparison counterpart to this pattern-detection mechanism.
• HQ programs: where a fired signal often turns into a network-wide program change.
• HQ standards: the stage-time and conformance side of network-wide pattern detection.
• HQ compliance: the certification and audit rollups behind the compliance-domain signals this trip-wire covers.

Data sources