Benchmark methodology and the privacy boundary

What this article is for

The other Benchmarks articles show you what's on screen: how to read a row on the Benchmarks tab, how the office leaderboard ranks your locations, what HQ does and doesn't see. This one is about the math and the plumbing underneath all of that: the two distinct calculations Verinode runs to build a "your network vs. the rest of the industry" comparison, why HQ's own server can query that comparison without ever being able to query a single franchisee's private records, and why a benchmark number stays honestly labeled even after Verinode improves how it's computed. If you haven't read the walkthroughs yet, start there: Network benchmarks: how the section works for the full tab tour, Per-office benchmarks: ranking your own locations for how a single row and its drill-in work, and What HQ sees: the network privacy boundary for the complete trust model. This article sits underneath all three.

Two different calculations, both called "benchmarks"

Verinode actually runs two distinct comparisons under the umbrella of "how does my network stack up," and they answer different questions. Knowing which one you're looking at tells you what the number can and can't do for you.

1. Office-vs-office, with the industry as a single reference line. This is the frame the Benchmarks tab's Benchmarks pill and the standalone Leaderboard are built around. For a given metric, Verinode works out one representative value per office in your network (the office's latest snapshot for something like margin, a median across its own jobs for something like cycle time, or a ratio summed across its jobs for something like collection rate), then computes your own network's p25, median, and p75 from those office values and ranks every office against that spread, best to worst. The broader industry, the median value among operators entirely outside your network, appears once, as a single quiet reference tick, never as a second cohort scoring you. This is the "how do my own offices compare to each other" question, and it's what most of the Benchmarks tab and the whole Leaderboard answer. The full mechanics, including exactly how a row reads and what the drill-in shows, are covered in Per-office benchmarks and The office leaderboard.

2. Group-vs-rest. This is an older, still-live engine that answers a different question: "how does my network, taken as one unit, compare to everyone outside it." It computes your group's own median for a metric exactly the same way an individual operator's own value is computed on their IQ account, then benchmarks that single group median directly against the median of every operator platform-wide who isn't a member of your group. Not a national average, not a hand-picked comparison set: literally everyone else, at whatever percentile your group's number lands on. You'll see this exact calculation power the opening hero card on Margin & Cash (hq.verinode.ai/margin-cash, your network's gross margin against the rest of the industry) and on Operations (hq.verinode.ai/operations, your network's cycle time against the rest), and it's also what feeds the two "vs. rest of network" reference points paired with your network's own 90-day trend lines on the Leaderboard page. It is the same underlying formula IQ uses for a single operator's own peer percentile, with your group standing in for the operator.

Both calculations answer honestly to the same question in different shapes, and both are protected by the identical anonymity floor before they'll publish a comparison at all (more on that below). Neither one ever computes anything from a franchisee's raw jobs, invoices, or correspondence: both start from pre-aggregated values that already exist one level removed from a location's own books.

The industry reference line, briefly

Both engines end at the same kind of number on the outside: a single median built from operators who are not part of your network, published as one figure and nothing else. No list of who's behind it, no breakdown, no way to narrow it down to fewer contributors than the whole eligible cohort. Before Verinode will publish that median at all, the cohort behind it has to clear a minimum number of distinct contributing operators, counted by operator, never by row, so one high-volume outside operator can't dominate or be reverse-engineered out of a "median of one." Financial and cost-structure metrics (margin, labor cost ratios, cost ratios generally) sit behind a noticeably higher bar than operational metrics like cycle time, because a P&L figure is more identifying and a thin cohort is easier to reason backward from. Below that bar, there is no line: not a number built from too few contributors and flagged as uncertain, just the line's absence, with your own network's numbers still rendering normally beside the gap. This floor is a legal commitment in Verinode's data-use policy, not a dial anyone can turn down to make a chart look fuller. The full explanation, including how it interacts with your own network's own-name vs. anonymized-label setting, lives in What HQ sees: the network privacy boundary.

The methodology version, and why it's stamped on exported reports

Verinode's benchmark engineering tags the group-vs-rest calculation with an explicit methodology version string, bumped only when the underlying math actually changes. You won't see that version string anywhere in the interactive Benchmarks tab, but you will see it on the one-page PDF slides your network can export from the Report Library (margin-cash, operations, facilities, fleet, and reputation slides, one button per section): the header of every exported board slide carries a small eyebrow line reading "Board slide · [Section] · methodology [version]," alongside a "Verinode-verified network snapshot" subtitle.

The point of stamping it is durability, not decoration. A board deck your leadership team pulls this quarter and a board deck pulled a year from now might be built on two different versions of the underlying calculation, if Verinode refines how a ratio is computed or which facts feed a metric in between. The version tag means neither slide silently misrepresents itself as the other's methodology: you can always tell, from the deck itself, exactly which calculation produced the numbers on the page, and hold two reports from different periods to the same or different standards deliberately, not by accident. It's also the same discipline behind the "Verinode-verified" language you'll see on these slides and elsewhere: the number in your board deck is the identical number an operator would see reading their own equivalent metric on their own IQ account, computed once by one engine, not a separate approximation built for the export.

Why HQ can query this at all, and never PII

Every number described above, on both engines, is read by HQ's application server through a single database path (internally called hqAdmin, part of the same family of cross-tenant service-role clients Verinode calls globalAdmin elsewhere in the codebase). That path is scoped to exactly two kinds of tables:

• the network layer schema, your own group's roster and the per-office rollups a nightly cron computes from your network's own connected data (financials, jobs, safety, equipment, certifications, team, facilities, fleet, commercial mix, vendor spend). These are already pre-aggregated one step removed from a location's raw books before HQ's server ever reads them.
• the benchmark layer schema, the platform-wide anonymized facts tables every operator's data (with consent) contributes to, keyed by a one-way cryptographic hash of the operator's identity, never a name, never a raw operator ID.

What that path cannot do, at the database level, is query the the private layer schema at all. That's where every operator's actual business records live: invoices, job line items, adjuster correspondence, payroll, connected-bank data, anything an operator enters into their own IQ account. HQ's database role has a hard, schema-level access revoke on the private layer, enforced by Postgres itself, not by a line of application code that could have a bug in it. Even if a future HQ feature tried to write a query against a franchisee's raw jobs table, the database would refuse the connection before the query ran. That's layered with a second, independent check: a CI lint that fails any commit importing the PII-side client from HQ-side code, so the two paths can't accidentally merge in the codebase either. Every table HQ can reach is audited on every read.

One detail worth knowing because it explains something you'll notice on screen: HQ can label a ranked office by its real name (or its anonymized label, depending on your network's entity model) without ever touching PII to do it. Your own network's directory, which HQ does read, already carries each office's name, resolved by your group's own aggregator cron (which does have PII access, but only to resolve a name into your roster, not to expose the underlying business records to HQ). The cross-network the benchmark layer tables, by contrast, only ever carry the anonymized hash, with no name attached at all, for any operator anywhere on the platform, including operators in your own network. When HQ needs to show your office named alongside its own metric value, it's joining your own roster's name to that hash locally, inside your own network's context. It never resolves a name for any operator outside your network, because it has no path to do that and no reason to: the industry reference line is a single number, never a roster of who's behind it.

The aggregates-and-compliance-only boundary, recapped

Put together, this is the shape of what HQ can and cannot see, everywhere in Benchmarks and everywhere else in the product:

• Can see: your own network's aggregated and per-office metrics (a margin percentage, a rank, a percentile, a compliance rate), your own network's roster and its compliance status, and single anonymized reference medians drawn from operators outside your network.
• Cannot see, ever: a single franchisee's invoice, job file, estimate, financial statement, vendor contract, adjuster correspondence, or any other raw business record, belonging to a location inside your own network or to any operator outside it.

Franchisees keep their own data in their own IQ account. What rolls up to HQ is the performance read your network agreement covers: standing, ranking, and compliance, never the underlying records that produced them. That boundary is what lets an independent operator trust their number is being read fairly (Verinode doesn't sell that data to carriers or expose it beyond the aggregate), and it's what lets your leadership team put Verinode in front of every location without any one of them worrying HQ is quietly reading their books.

Where each engine actually shows up

| Surface | Engine | What it looks like | |---|---|---| | Benchmarks tab, Benchmarks pill (hq.verinode.ai/benchmarks) | Office-vs-office | Category rows, your network's own p25/median/p75 spread, one industry tick | | Leaderboard (hq.verinode.ai/leaderboard) | Office-vs-office (ranking) + group-vs-rest (trend strip) | Ranked office list and composite score from office-vs-office; the 90-day margin and score trend cards pair your network's own history with a current group-vs-rest reference point | | Margin & Cash hero (hq.verinode.ai/margin-cash) | Group-vs-rest | Your network's own gross margin against the rest of the industry | | Operations hero (hq.verinode.ai/operations) | Group-vs-rest | Your network's own cycle time against the rest of the industry | | Report Library board slides (margin-cash, operations, facilities, fleet, reputation) | Group-vs-rest (for the two financial/ops slides) | A one-page exported PDF, methodology version stamped in the header |

1. 1Open a benchmark number wherever you find it and ask first: is there a ranked list of my own offices attached, or just one hero figure for the whole network. That tells you which engine you're reading.
2. 2If it's office-vs-office, drill into the row (see Per-office benchmarks) to see which specific offices are driving the network's position, that's the coaching conversation.
3. 3If it's group-vs-rest, treat it as a single network-level fact, not a diagnostic: it tells you where your whole network sits against the industry, not which office is responsible.
4. 4Either way, if the industry or rest-of-network reference is missing entirely, that's the anonymity floor, not a bug: the outside cohort for that specific metric hasn't cleared the minimum contributor bar yet, and Verinode would rather show nothing than a number that could be traced back to a handful of businesses.

Empty states you'll see

• A category or row on the Benchmarks tab has nothing to show. It hides itself rather than rendering a wall of dashes. See Network benchmarks for the full list of category-level empty states.
• An industry or rest-of-network reference tick is missing from a number that otherwise renders your own network's value. The outside cohort for that specific metric hasn't cleared the anonymity floor yet, or (for office-vs-office metrics sourced purely from your own roll-up tables, like equipment or reputation) there's no cross-network counterpart table for that family at all yet. Either way, your own network's own number keeps rendering normally beside the gap.
• A per-office drill-in reads "No offices have reported this metric yet." No office in your network has a usable value for that specific metric. In practice a metric card doesn't appear on the tab at all until enough offices report it, so this only shows as a defensive fallback inside a drill-in you reached another way.
• A board slide export is missing a section's numbers. The underlying hero query (Margin & Cash or Operations) couldn't resolve a group-vs-rest comparison for that section yet, most often because the aggregator hasn't run against your network's data long enough, or your network hasn't connected the financial or job data the calculation needs.

Related articles

• Network benchmarks: how the section works
• Per-office benchmarks: ranking your own locations
• What gets benchmarked: the metric families
• The office leaderboard and composite ranking
• What HQ sees: the network privacy boundary
• HQ overview
• Network health
• HQ report library
• HQ compliance
• HQ programs
• HQ standards
• Broadcasting to your network
• Discovery Day
• Item 19