Opening a signal: the detail panel

What this panel is

Every tile on the Signals page, in every row, is a summary: a title, a severity label, a rough age, and (when the aggregator captured it) a count. Clicking any of those tiles opens a detail panel that slides in from the right and gives you the full picture behind that one network pattern: the plain-language explanation, exactly how far it has spread, the trip-wire it crossed, and (when your network's privacy settings allow it) the specific members it touched. This article covers that panel end to end. For the five rows the tiles live in, see Signals: your network's early-warning feed.

Where to find it

The panel is not a separate page. Open Feed from the HQ sidebar; the underlying signal feed lives at hq.verinode.ai/signals. Click any signal tile, in the Critical & High Severity row, the Recent row, or the Resolved row, and the panel opens on top of the page. Click the same tile again elsewhere in a different row, and clicking there opens the identical panel, tiles are keyed by the signal's ID, so the Critical & High row and the Recent row can both point at the same signal without opening two different views of it.

Close the panel with the X in its header, by clicking the dimmed page behind it, or by pressing Escape. Closing it clears its state, so the next signal you open always starts clean rather than showing stale numbers from the last one.

How the panel loads

Clicking a tile does two things at once. First, it opens the panel immediately using the data the tile already had, its title, severity, domain, status, body text, affected count, total count, and detected/resolved timestamps all come from the same rollup rows that built the tiles on the page, so the panel never opens on a blank screen. Second, it fires a request behind the scenes to fetch the fuller drill payload for that one signal (evidence, the affected-franchisee roster, a sample). The reason for the two-step load: the Signals page's initial server load intentionally stays rollup-only, so opening the page for the day doesn't have to ship every open signal's full evidence blob and affected-member roster up front. The richer detail only gets fetched for the one signal you actually click into.

In practice this means two pieces of the panel appear a beat later than everything else:

• Network reach and Fire threshold, the two percentage figures in the reach grid, both live only in the fuller record. They render a placeholder dash while the fetch is in flight and fill in once it resolves.
• Affected franchisees shows "Loading…" under its heading until the fetch completes, then swaps in the roster (or the appropriate empty state, see below).
• Sample signal doesn't appear at all until the fetch resolves and only then if the aggregator actually captured one.

Everything else, the header chips, the body text, the Affected count, the Detected and Resolved timestamps, and the Signal type footer, is already correct the instant the panel opens, because the tile you clicked already carried it.

If the fetch fails (a network hiccup, a dropped connection), the Affected franchisees section shows:

"Couldn't load the affected roster. Refresh and try again."

When that happens, Network reach and Fire threshold stay at their placeholder dash and Sample signal stays absent too, since all three come from the same failed request. Refreshing the page and reopening the panel retries it.

If you close the panel and open a different signal before the first fetch finishes, the stale response is discarded when it eventually lands, so you never see one signal's detail bleed into another's panel.

Header chips

Three chips sit at the top of the panel, under the panel's title (the signal's own title, in plain language, for example "Carrier X paying slower than usual across the network"):

• Severity: Critical, High, Medium, or Low. Critical and High both render in the same red tone, Medium in amber, Low in a lighter neutral tone, so a glance at the color tells you whether this needs same-day attention (red) or is more of a watch item.
• Domain: the operator-side area the pattern falls under, Margin, Cash, Carrier, Client, Team, Process, and so on. Domain labels are humanized before they reach the panel; the one exception is the operator "growth" domain (Sales & Marketing), which is relabeled on every HQ surface so it doesn't get confused with the franchise-network Recruit & Grow area.
• Status: New, Seen, or Resolved. New and Seen are both open signals (Seen just means someone on your team has already looked at the underlying pattern in the operator-side product); Resolved means the pattern has cleared.

The pattern body

Below the chips, a paragraph of plain-language explanation of what the pattern is, written by the aggregator when it wrote the signal. Not every signal type currently writes body text, if the aggregator didn't populate one, this section is simply omitted and the panel moves straight to the reach grid.

The four reach metrics

A row of four figures, laid out in a grid under a hairline divider, is the core of the panel: it answers "how big is this, and how do I know it's real." Each has a headline number and a one-line caption underneath.

1. Affected. The raw count of members the pattern hit. Underneath, "of M franchisees" where M is the total number of members the aggregator considered eligible for this signal type. If the total isn't recorded, the caption is simply blank.
2. Network reach. The Affected count expressed as a percentage of eligible active members, for example a signal that hit 6 of 20 eligible members reads 30%. Caption: "of active members." This is the same math the aggregator itself used to decide whether the pattern was widespread enough to fire a signal in the first place, so it's the fastest way to gauge how far past the trip-wire the pattern has actually spread.
3. Fire threshold. The minimum share of the network the aggregator requires before it will write this signal type at this severity, shown as a percentage. Caption: "minimum to trip-wire." Verinode deliberately doesn't publish the specific member-count math behind this number, the same reason cohort sizes stay unpublished on Benchmarks: a visible threshold is a threshold that can be gamed, and the whole point of a network signal is that it represents a genuine cross-network pattern rather than a low bar a handful of members' worst week could clear.
4. Detected. The full detection timestamp (date and time, for example "Jul 13, 2026, 2:45 PM"). If the signal has since resolved, a second line underneath reads "Resolved" with its own full timestamp. If the signal is still open, there's no second line.

Read Network reach against Fire threshold together: a signal sitting right at the threshold is a pattern that just barely qualified and is worth watching for whether it grows or fades; one running well past the threshold is already a broad, structural pattern across your network.

Any figure that hasn't loaded yet (Network reach or Fire threshold, while the drill fetch is still in flight or if it failed) shows a placeholder dash rather than a number or a zero, so you're never misreading "not loaded yet" as "zero."

Affected franchisees

Below another hairline divider, a list of the specific members the pattern touched. This is the one place on the Signals page where individual members are named, everywhere else on the page, patterns are counts and percentages only.

Each row shows the member's display name on the left and an "Open profile →" link on the right that takes you to the Member Directory with that member pre-selected, so you can go straight from "a pattern touched this member" to "let me check in on them" without hunting for them in a list.

How the name renders depends on your network's entity model, set under Settings:

• In independent_operators mode, the default for new networks, each row is anonymized to a stable label like "Franchisee #4F1A", derived from that member's own ID rather than their business name. The same member always gets the same label across every signal, so you can track one member's recurring pattern history without ever seeing their real name here.
• In same_entity mode (company-owned or PE-owned locations under one legal entity), the real location name passes through instead, since there's no cross-entity privacy boundary to hold inside a single company's own locations.

Three states cover what happens when there's nothing (yet) to list:

• Loading: while the drill fetch is in flight, the section shows "Loading…" instead of a list.
• Roster not captured for this signal: signals written before the aggregator started capturing per-member rosters (2026-05-24) show a footnote instead of an empty list: "This signal predates the per-franchisee roster capture (2026-05-24). The next nightly aggregator run will populate the list; until then only the affected count is recorded." This is deliberately worded to avoid implying there were no affected members, only that the roster for this particular row hasn't been backfilled yet.
• Genuinely empty: if the roster was captured but happens to list no members, the section reads "No affected franchisees recorded."

Sample signal

When the aggregator captured a representative example, a section below the roster shows it: a short title describing the underlying operator-level pattern, and (when the raw evidence was attached) the evidence itself shown as a formatted excerpt. This is the "for instance" that turns an abstract network-wide percentage into a concrete example of what one member's version of the pattern looked like. If the aggregator didn't attach a sample for this signal, the whole section is omitted, there's no empty-state message here since not every signal type generates one.

Signal type

At the very bottom of the panel, under its own small header, the raw internal signal type code is shown in monospace, for example a compact underscored token rather than a sentence. This isn't meant for reading in the panel itself, it's there so you can quote the exact type precisely if you need to describe a pattern to Verinode support or reference it in a network communication without ambiguity over which of several similarly-worded signals you mean.

How to use it

Open the panel expecting the top of it to answer "what happened" and the reach grid to answer "how big and how sure." Check Network reach against Fire threshold before deciding how urgent the pattern is, a signal sitting just past the trip-wire is different from one running at double the threshold. Then use Affected franchisees, when your entity model surfaces names, to decide whether this is a call-a-few-members situation or a network-wide communication. Sample signal is there if you want a concrete "here's what this looked like for one member" to anchor a conversation or a broadcast.

1. 1Click any signal tile in any row on the Signals page to open the panel.
2. 2Read the header chips (severity, domain, status) and the body text to understand what pattern fired.
3. 3Compare Network reach against Fire threshold in the reach grid to gauge how far past the trip-wire the pattern has spread.
4. 4Give the panel a moment if Network reach, Fire threshold, or Affected franchisees are still loading, they finish shortly after Affected count and Detected are already showing.
5. 5Open Affected franchisees and click "Open profile →" on any member you want to check in with directly.
6. 6Reference Sample signal, if present, for a concrete example to anchor a network communication.
7. 7Note the Signal type at the bottom if you need to reference this exact pattern with Verinode support or in a broadcast.

Related reading

• Signals: your network's early-warning feed: the five rows the tiles live in, and how a signal gets written in the first place.
• Network health: the aggregate-only privacy boundary this panel's affected-franchisee list depends on.
• HQ benchmarks: the cohort-comparison counterpart to Signals' pattern-detection feed.
• HQ programs: where a signal-driven insight often turns into a network-wide initiative.
• HQ standards: compliance-side patterns that surface alongside operational signals.
• HQ compliance: the compliance-specific view of network-wide patterns.
• Broadcasting to your network: turning a signal into a message to affected members.

Data sources