Signal evidence: the sample and signal type

What this is

Every open row on Signals is a rollup: a pattern the nightly network aggregator saw repeating across a meaningful share of your active members. The top of the signal detail panel tells you the shape of that pattern (title, severity, domain, the reach numbers). The bottom of the panel tells you where it came from: a real example of the underlying pattern at one contributing member's level, and the raw internal code the aggregator filed it under. This article is about that bottom section, the two blocks labeled Sample signal and Signal type, and the evidence data behind them.

Nothing in this section hands you a franchisee's business record. The sample is a structured excerpt of the specific numbers a detector used to decide the pattern had tripped, not an invoice ledger, a job file, or a client name. See Network health for how that boundary holds everywhere on HQ, not just here.

Where to find it

Open Feed from the HQ sidebar at hq.verinode.ai/signals. Click any signal tile, in any row, and a detail panel slides in from the right. Scroll to the bottom of that panel, past the header chips, the body text, the four-number reach grid, and the Affected franchisees list. The last two blocks are:

• Sample signal, an optional block that only appears when the aggregator captured one.
• Signal type, a one-line footer that is always there once the panel has loaded.

For the reach grid and the Affected franchisees list above these two blocks, see Signals: your network's early-warning feed and the Critical & High Severity row. This article covers only the evidence footer.

The evidence blob: what the aggregator writes

Every night, the HQ aggregate-refresh cron scans open warning- and critical-severity signals across your active members' own IQ accounts (the same signal types that show up on an individual member's feed), groups them by signal type and severity, and for any group that clears the network-wide share required for that severity, writes one row to the network data. Alongside the title, domain, severity, and the affected/total counts, that row carries a single JSON column, the aggregate, with four fields:

• sample, a structured excerpt of one contributing member's own signal evidence, the specific fields that member's detector recorded when it decided the pattern had tripped for them.
• sample_title, the plain-language title that one member's own signal carried (or the raw signal type, if that signal had no title of its own). This is the heading shown above the sample excerpt.
• threshold, the minimum share of active members required to hit the pattern before this severity was allowed to fire at all, stored as a fraction (0.3 for a warning-tier pattern, 0.5 for a critical-tier one) and rendered in the reach grid as Fire threshold, a percentage.
• ratio, the share of active members that actually hit the pattern, stored as a fraction and rendered in the reach grid as Network reach, a percentage.

A fifth field, affected_operator_ids, sits in the same evidence blob and feeds the Affected franchisees list above this section: the sorted list of member IDs the aggregator counted as affected, resolved to a name (real or anonymized, depending on your network's entity model) further up in the panel.

Sample signal: the "for instance" behind the pattern

What it is. An abstract "12 of 40 locations hit this pattern" statement is hard to picture. The Sample signal block makes it concrete by showing one real, structured example: the evidence one contributing member's own signal carried when it tripped. Think of it as the "for instance" that backs up the rollup title above it.

How it's picked. The aggregator does not curate this for severity, dollar size, or how representative it is. It groups every open signal of a given type and severity in the order they come back from the database, and keeps the evidence from the first one it encounters for that group. In practice, that is typically whichever contributing member's signal has been open longest at the time of that night's run, not necessarily the worst example, just the one the aggregator happened to see first. Because the aggregator rebuilds this from scratch each night, the sample you see today can be a different underlying example than the one you saw yesterday, even if the affected count hasn't moved, if the previously-sampled signal resolved or a different one sorted earlier in that night's query.

What you see. When the aggregator captured one, the block shows:

• A bold sub-heading: the sample's title (sample_title), the same plain-language sentence that member's own signal carries on their feed.
• Beneath it, if the underlying evidence has at least one field, a monospace, scrollable box with the evidence printed as formatted JSON, the raw structured fields (ratios, counts, dollar deltas, whatever that specific detector recorded), not narrative detail like a customer name, an address, or a job record. No member name or ID appears inside the box itself; the excerpt stands alone as an anonymous illustration of the pattern.

The box scrolls horizontally if a line runs long, but it does not scroll vertically. If the evidence object is deep enough to run past the box's height, the bottom of it is simply cut off rather than revealed by a scrollbar. If you need the full evidence for a specific case, that is a support conversation, not something to dig for in this box.

What you don't see. If the aggregator has no sample title and no sample evidence for that pattern, the entire block is omitted, there is no placeholder text, no "no sample available" line. You'll see this on the two non-reporting coverage signals described below, and on any older signal where the underlying evidence never carried a sample.

Signal type: the raw identity line

What it is. Every signal in the network data carries a signal_type column: a raw, lowercase, underscore-separated internal code (for example, the kind of string a detector or a support engineer would recognize, not the humanized sentence you read as the tile title). The title above it in the panel is a humanized, network-framed sentence built from this same code. The Signal type footer is the one place in the panel that shows the raw code itself, unhumanized, exactly as it's stored.

What you see. A small uppercase label reading Signal type, and beneath it, in a monospace font, the raw code string.

Why it's there raw. This is a deliberate exception to the platform's usual rule against showing raw database identifiers on screen. It exists for precision: if you're describing a pattern to Verinode support, filing a note for your council, or cross-checking a signal against something you saw on an individual member's own feed, the raw code is the unambiguous reference. It is not meant to be read as a label in its own right, treat the title above it as the sentence, and this line as the citation underneath.

When it appears. Unlike the Sample signal block, the Signal type footer does not wait on the richer drill-down fetch. The signal tile you clicked already carries its own signal type from the page's initial rollup load, so this line renders the moment the panel opens, before the fuller evidence (sample, reach numbers, affected roster) has finished loading in.

Two signals that don't carry this evidence shape

Not every row on Signals is a cross-network pattern rollup with a sample and a ratio. Two signal types are coverage nudges instead, and their evidence blob is a different shape entirely:

• network_pnl_not_reporting, fired when a material share of your active members haven't reported a P&L, so network margin and cash figures are computed over an incomplete set.
• network_certs_not_reporting, fired when a material share of your active members have no certifications on file, so the network compliance picture is incomplete.

Both carry an evidence blob of reporting_n, not_reporting_n, and metric, none of the four fields described above. On the detail panel for one of these, that means:

• Network reach and Fire threshold in the reach grid both show a dash instead of a percentage, because ratio and threshold are absent from the evidence.
• Sample signal never appears, because there is no sample or sample_title to show.
• Affected franchisees shows the note that the signal predates the per-franchisee roster capture, even though these two signal types are current. They were simply never built to carry an affected_operator_ids roster; the panel can't tell the difference between "too old to have one" and "not designed to have one," so it defaults to the same explanatory copy either way.

If you land on the detail panel for a non-reporting signal expecting the usual evidence footer, this is why it looks sparse: the pattern is real, it's just a different kind of signal than the aggregated-pattern rollups this article otherwise describes.

How to use it

Read the reach grid first for the shape of the pattern (how many, how severe, against what bar), then use the Sample signal block only when you need the "does this feel real" gut check, an actual instance of the numbers behind the rollup. The Signal type footer is not something to read every time, it's there for the day you need to describe the exact pattern precisely, whether that's a support ticket, a note to your council, or cross-referencing against something a member mentioned from their own feed.

1. 1Open a signal tile's detail panel and read the reach grid (Affected, Network reach, Fire threshold, Detected) for the pattern's shape.
2. 2Scroll to Sample signal. If it's present, read the bold title first, then the JSON box underneath for the specific numbers that one contributing member's signal carried.
3. 3Remember the sample is one arbitrary contributing example, not necessarily the worst or most typical case, don't generalize its exact numbers to the whole affected group.
4. 4If Network reach and Fire threshold both show a dash and there's no Sample signal block, you're looking at a non-reporting coverage signal, not a cross-network pattern rollup, read its body text instead for the plain-language explanation.
5. 5Note the Signal type code at the bottom if you need to reference this exact pattern in a support conversation or a council note.

Related reading

• Signals: your network's early-warning feed: the full page, all five rows, and how a signal reaches HQ in the first place.
• The Critical & High Severity row: the tiles that most often lead into this evidence footer.
• The Recent and Resolved rows: the other two rows that open the same detail panel.
• Network health: the aggregate-only privacy boundary this evidence footer depends on.
• HQ compliance: where the certification non-reporting signal connects to your compliance program.
• Broadcasting to your network: turning a signal, sample and all, into a message to affected members.
• HQ report library: exporting a signal's underlying pattern for a board or council update.

Data sources