What HQ sees, the network privacy boundary

The hard line

Verinode HQ is the network intelligence layer sitting on top of every location's own IQ account. It is not a window into any one location's books. Every surface on Network Health, Benchmarks, and the rest of the HQ product is built on one line that never moves: HQ sees network aggregates, roster standing, and compliance status. HQ never sees a single location's private business data.

That line is not a display setting you can toggle off, and it is not a promise resting only on policy. It is built into where the data physically lives and which database role HQ's application server is allowed to query. This article explains exactly what that means in practice: what shows up named on your Network Health home, what only ever shows up as a network-wide number, how the cross-network industry comparison line protects the operators who contribute to it, and what the "reporting locations" language you see throughout the product is telling you.

Two different kinds of "your data" at HQ

HQ reads two categories of numbers, and they behave very differently. Confusing them is the single most common misunderstanding operators and HQ leaders both have about the product.

1. Your own network's data, named, because it's yours. When you look at the Location Directory, the Leaderboard, or the per-office view inside Benchmarks, you are looking at your own franchisee network's data rolled up by the aggregator that runs against your group. A location that belongs to your network can appear by name (or by an anonymized label, see below), ranked against the other locations in your own network. This is not a privacy boundary issue, because it's the same network looking at itself, the same way a company can see its own branch offices' numbers.

2. The cross-network industry reference, a single anonymized line, never a name. Wherever HQ shows an "industry" or "network vs. industry" comparison, that number is built from anonymized facts contributed by operators outside your network entirely, everywhere across the platform. Those operators are never identified, individually or collectively, by name, location, or any combination of attributes that could point back to one business. You get exactly one number: a median. Nothing else about who's behind it.

Both kinds of numbers can sit side by side on the same benchmark card. The per-office benchmarks inside HQ's Benchmarks tab are the clearest example: the big number is your network's own median, the spread beneath it (p25 to p75) is your own offices' distribution, and the industry line is a single reference point drawn from operators outside your group. The methodology note under every one of those cards spells this out directly: "Median across your [N] offices on [metric], with each office ranked in the deep-dive. The band shows your network's p25–p75 spread; the industry line is the median of [N] operators outside your network, a reference, not a competitor."

Where to find it

Open Network from the HQ sidebar (hq.verinode.ai/network). Depending on how your network is set up, this item may be labeled "Network," "Franchisees," or "Locations" for your audience, but it's the same page. This is the canonical Network Health home, and it's also where the composite health score, the Take Action row, and the Explore tiles (Location Directory, Leaderboard, Top Quartile, Risers & Fallers, Watchlist, and the rest) live. The per-office view inside Benchmarks (hq.verinode.ai/benchmarks) is where the industry reference line shows up alongside your own network's spread.

The technical enforcement: HQ cannot query PII, period

The privacy boundary is enforced at the database level, not just in the interface. Every location's operational data (invoices, job line items, adjuster correspondence, payroll, bank connections, anything an operator enters into their own IQ account) lives in a separate PII database. HQ's server-side database role has a hard schema-level revoke on that database: it is not permitted to run a query against it under any circumstance, successful login or not. There is no code path in the HQ application that can read a location's raw business records, because the database itself refuses the connection.

What HQ can read is the network layer schema tables: your group's roster (the network member directory), your group's own per-office rollups computed by a nightly cron (equipment, fleet, certifications, team, facilities, commercial mix, vendor spend), and signals your network has surfaced. Those rollups are pre-aggregated by the cron before HQ ever touches them, so even the "your own network" side of the boundary is one step removed from a location's raw books.

Names on your own roster resolve one specific way: your group's aggregator cron, which does have PII access, reads each member operator's business name and writes it into your group's roster (location_name in the network member directory). HQ's read side only ever sees that pre-resolved name, and only for operators who belong to your own group. It has no ability to look up a name for an operator outside your network, because it has no path to the PII database where that lookup would happen, and no reason to: the industry reference line is a number, not a roster.

Anonymization inside your own network

Whether the locations in your own roster and leaderboard appear by name at all depends on your network's entity model, a setting HQ configures once when your account is set up:

• Same entity (multi-location enterprise, PE-backed roll-up where every location is the same legal business): locations appear by their real name everywhere. There's nothing to anonymize, since it's one business looking at its own branches.
• Independent operators (a franchise network of separately owned locations, an association of independent members): every per-location name is anonymized to a stable label like "Franchisee #A1B2" derived from the location's internal ID. The same location always gets the same label, so you can track it over time, but the label never reveals which business it is. This is the default, safer posture for any new network, and a network has to be deliberately switched to same-entity mode to unlock real names.

This anonymization also governs a related guard: in independent-operators networks, per-location breakdowns (Commercial, Facilities, Fleet, Equipment, and similar rollups) only render as individual rows once your network has enough active locations that a single row isn't identifiable by elimination alone. Below that, HQ shows the aggregate view only, with a note pointing you to the network-wide numbers. Once your network has grown past that point, the per-location rows appear automatically, anonymized the same way.

The k-anon floor on the cross-network industry side

The industry reference line you see next to your own network's numbers, the one described above as "a single median, no names attached," has its own floor before Verinode will publish it at all. This is separate from and in addition to the name anonymization above; it's what protects the operators outside your network who contribute to that reference.

Here's the qualitative version of how it works, without exposing the exact mechanics of the gate:

• Verinode counts distinct contributing operators, not rows of data. An operator who shows up in the underlying facts many times over (many jobs, many snapshots) still only counts once. A single operator with a lot of data behind it is still a cohort of one, and publishing a "benchmark" built from one operator's numbers would hand a competitor that operator's exact private figures under a benchmark label. Verinode's aggregation code exists specifically to prevent that.
• Every industry line has to clear a minimum number of distinct contributing operators before it publishes. Financial and cost-structure figures, margin, labor cost ratios, and similar sensitive categories, require a noticeably larger contributing cohort than operational metrics like cycle time or job counts, because a P&L figure is more re-identifying and a thin cohort can be reverse-engineered by two contributors comparing notes.
• Below the floor, there is no line. You will not see an industry median built from too few contributors labeled with a small sample size. The number is withheld entirely rather than shown with a caveat, and the card reads as "warming up" or omits the industry reference until enough independent operators have contributed.
• This floor is a legal commitment in Verinode's published data-use policy, not just an engineering choice, and it cannot be lowered without a coordinated, publicly disclosed policy change.

The same principle applies to the Network Flow row on your Network Health home: each stage's industry benchmark tick (the small marker alongside your network's own median duration) only appears once the anonymous peer cohort clears its floor. Without it, you still see your own network's median and your own offices' spread, just no external comparison point.

"Reporting locations": what that language means

You'll see phrases like "based on reporting locations" and "N not yet reporting" throughout Network Health and Benchmarks. This is coverage language, and it exists so that a network-wide number is never silently misread as covering locations that haven't actually supplied the underlying data yet.

Concretely, on the Network Health hero:

• The subtext under your composite score reads "[X] Of [Y] Members Active In The Last 30 Days." when every active member's inputs are complete.
• When some active locations haven't reported the figures behind the composite (most often margin, since that requires financial data a location may not have connected yet), the subtext extends with " Based On Reporting Locations. [N] Not Yet Reporting."
• The margin secondary figure itself is labeled either "Net Margin" or "Gross Margin," whichever your network actually has on file (net is preferred once the operating-expense data to compute it exists), with a sub-line reading "Median of [N] reporting" whenever that count is smaller than your total active roster, or just "Median" when every active location is represented.

The point of this language is honesty about denominators. A network composite score, a margin median, a compliance rate: none of these are averaged silently across "everyone." They're computed over the locations that have actually reported the relevant inputs, and the interface tells you that denominator every time it might matter, rather than letting a partial number pass as a full-network figure.

What HQ never shows, even about your own network

Beyond the database-level PII wall described above, there are things HQ deliberately never surfaces even in aggregate, because doing so would functionally leak an individual location's private numbers through the back door of a "network view":

• No per-location invoice, job, or adjuster-level detail. The rollup tables HQ reads are pre-computed sums, medians, and ratios. There is no drill path from a Network Health tile into a location's actual line items.
• No fabricated rankings. The Top Quartile and Watchlist rows on your Network Health home are built only from real, computed evidence, either an actual Verinode operator score for that location, or a specific driver (margin position, cash runway, SOP coverage, cycle time, receivables aging) pulled from the same aggregator evidence. If neither exists yet for a location, it is left out of the ranking rather than assigned a slot to fill the row. A location never gets called out as a top or bottom performer on a guess.
• No invented movers. The Risers & Fallers row only populates once there are two real, comparable weekly snapshots of a location's Verinode score to compare. Until then, it reads as still warming up rather than showing speculative movement.
• No named attribution in Best Practices. When the Best Practices row on your home surfaces something the strongest cohort in your network is doing differently (stronger SOP coverage, faster cycle time), it names the pattern, never which specific location is behind it.
• No raw operator values leaving the network in ops or founder-facing channels. Cross-network signal detection exists to flag patterns, not to publish any one location's numbers outward.

Empty states you'll see

• No open signals: "No open signals. Cross-network warnings appear here when ≥30% of active franchisees hit the same pattern." This is a real threshold: a signal is a pattern shared by a meaningful share of your active network, not a single location's issue surfaced as a network warning.
• No best practices to propagate: "No material gap between your top and other locations right now. Practices appear as the top cohort pulls ahead on SOP coverage or cycle time."
• No network flow data yet: "Network stage medians appear as offices report lifecycle dates. Job, supplement, recruiting, and safety flows map here automatically."
• Composite score not yet computed: the hero reads "Network Health will appear as members come online." when the network has no active membership yet.
• Risers & Fallers warming up: the row explains it needs two comparable weekly snapshots before it will name any mover, rather than showing a false start.

Each of these is the same underlying discipline: an absence of qualifying data produces an honest empty state, not a number stretched to look complete.

Why this matters

The privacy boundary is the reason a franchisee network, an association, or a PE-backed multi-location group can put Verinode in front of every location without that location worrying HQ is quietly watching their books. Locations keep their own data in their own IQ account. What flows up is aggregate standing: how the network as a whole is doing, how one location compares to the others in the same network (named or anonymized per your entity model), and how the whole network compares to an industry reference built from operators who will never be identified. That structure is what makes the benchmarks worth trusting in the first place: they're built the same way for every network on the platform, under the same floor, whether or not you can see the individual pieces behind them.

Related articles

• Network Health: the network home
• HQ overview
• Benchmarks at HQ
• Compliance
• Standards
• Programs
• Report library
• Broadcasting to your network
• Discovery Day
• Item 19