The privacy boundary: aggregates, k-anonymity and small-network suppression

Why this article exists

Equipment is the third pill inside HQ's Assets cluster (alongside Facilities and Fleet, at hq.verinode.ai/equipment), and it never reads a franchisee's own equipment log directly. Every number on that page, the hero, the Maintenance & Calibration Risk row, the Refresh Cycle row, and Equipment by Franchisee, comes from a nightly network rollup, not a live query into any franchisee's Verinode IQ account. That is not a display convention. It is enforced three separate ways, at three separate points in the read path, and this article documents all three:

1. The core-only read. HQ's application code has no path to a franchisee's private PII database at all for this page, enforced at the database connection layer, not just in application logic.
2. Name anonymization. In a franchise or association network of independently owned businesses, a franchisee's real name never leaves the rollup; HQ sees a stable, meaningless label instead.
3. Small-network suppression. In a network too small for anonymization alone to protect an operator, HQ hides the per-franchisee rows entirely and shows aggregates only.

If you administer a franchise network, an association, or a PE-backed platform of independently reporting locations, this is the mechanism that makes it safe to put HQ's Equipment page in front of an operator advisory council or use it in a capital-planning conversation. Read What HQ sees: the network privacy boundary first for the platform-wide version of this contract; this article is the section-specific deep dive for Equipment, grounded in the actual query code behind the page.

Mechanism 1: the core-only read (no pii.* access)

Every franchisee's actual equipment records, individual units, serial numbers, purchase invoices, service logs, calibration certificates, live inside that franchisee's own PII database, the same database their own Verinode IQ account reads and writes. HQ's Equipment page does not, and structurally cannot, query that database.

Instead, a nightly aggregator cron (the same one that feeds Facilities, Fleet, and the rest of HQ's Assets cluster) reads each franchisee's own equipment records from inside their PII database, computes counts and sums, and writes one summary row per franchisee into a core-schema table, the network data. HQ's Equipment page reads only that table. There is no other query path.

This boundary is enforced at four layers, not just one:

• SQL. HQ's server-side database connection authenticates as a dedicated role with a hard schema-level revoke on the the private layer schema. A query against pii.* from that connection returns a permission-denied error at the database itself, before the query can even run, regardless of what the application code asks for.
• Client binding. Every file under HQ's franchise code, including the equipment queries and the detail-slider actions this article is grounded in, imports the same HQ-bound database client. There is no alternate client available to that code that could reach a franchisee's PII database instead.
• A CI lint. An automated check rejects any commit that imports the operator-side PII database client from HQ-side code, so this boundary cannot regress silently in a future change.
• An audit trail. Every mutation on the core-schema tables HQ does touch is logged, though Equipment itself is entirely read-only, no mutation path exists on this page at all.

One piece of information the rollup does carry that deserves its own explanation is a franchisee's name, since the page has to display something under each tile. That name is written into the rollup two ways depending on how your network handles sensitive fields: as plain text, or as an encrypted value (franchisee_name_ciphertext) that HQ can only read back by unwrapping a group-level encryption key issued for your account. Either way, the name itself comes from the same nightly rollup, not a live lookup, and what HQ does with that name once it has it is governed by the second mechanism below.

Mechanism 2: anonymizing franchisee names

Whether a franchisee's real name appears anywhere on the Equipment page, on a tile headline, in the detail overlay's header, depends on one setting on your group record: the entity model, configured once when Verinode sets up your HQ account.

• Independent operators (the default, and the safer posture for any new network): your network is a set of separately owned businesses sharing a brand, a set of standards, and a data pipeline into HQ, the standard franchise model. Every franchisee's real name is replaced, at the query layer, with a stable label built from that franchisee's internal account ID: "Franchisee #A1B2," for example. The same franchisee gets the same label every time, on every tile, in every row, and in the detail overlay it opens, so you can track that franchisee's posture over time without ever learning which specific business it is. The label is derived from the last four characters of the franchisee's account ID, a value with no relationship to the business name, address, or anything else that could be reverse-engineered.
• Same entity (a single multi-location enterprise or a PE-backed roll-up where every location is the same legal business): there is no separate franchisee to protect, since HQ and every location are the same business. Real names pass through unchanged everywhere on the page.

This is a single toggle, and it cascades to everything downstream of it. In an independent-operators network, the anonymization doesn't stop at the tile headline:

• The detail overlay's header, which normally shows a franchisee's city and state, instead reads "Location anonymized" in place of geography, because city and state together can narrow an anonymized label back down to one identifiable business in a network of any modest size.
• The hero panel's sub-line on the Equipment page itself adds one more clause when your network is anonymized: "Franchisee rows are anonymized (independent-operator network)."
• Every equipment metric, every peer comparison, and every maintenance or calibration figure still computes and displays normally. Anonymization hides who a franchisee is; it never hides what the numbers say.

Same-entity networks bypass all of this. There is no anonymization step to apply, so real names, real cities, and real states show through on every tile and overlay.

Mechanism 3: small-network suppression (MIN_NETWORK_K)

Anonymizing a name is not, by itself, enough protection in a very small network. If your network in independent-operators mode has only one or two franchisees currently active, a single tile's equipment count, capital value, or overdue-maintenance figure can identify that franchisee by elimination even under a made-up label, because there is nobody else it could plausibly be. Stripping the name doesn't close that gap; the numbers themselves are the identifying detail once the field narrows to one or two candidates.

To close it, HQ applies a network-size floor before it will render any per-franchisee row at all on Equipment. HQ counts your network's currently active franchisees (the same status the Location Directory and roster use, not seeded or invited members still onboarding) and compares that count against a minimum. Below that minimum, and only when your network is in independent-operators mode, HQ suppresses the per-franchisee rows entirely:

• The Maintenance & Calibration Risk row, which lists franchisees carrying overdue maintenance or calibration
• The Refresh Cycle row, which lists franchisees carrying the largest share of equipment older than five years
• The Equipment by Franchisee row, the full roster of every franchisee with any equipment on file

All three return empty at once, together, as a single decision. This is not three independent checks; it is one gate (Verinode calls it the network-size gate internally) evaluated once and applied uniformly to every per-franchisee surface on the page.

The hero panel is never affected. The network-wide totals, active equipment, capital value, maintenance-overdue count, equipment over five years, statuses in service, in storage and retired, all still compute and display in full, because a sum across the whole network doesn't identify any single franchisee. Only the per-franchisee breakdowns are held back.

In place of the three suppressed rows, a banner appears above where they would normally sit:

Aggregate-only view. Your network currently has fewer than three active operators, so per-franchisee equipment capacity tiles are suppressed to protect operator privacy (small-cohort identification risk). Hero aggregates still surface. Tiles return once the network reaches 3+ active operators, or change the network data posture in Settings, Group, Data posture.

This banner reads in copper, the network-neutral brand accent, not a signal color, because it isn't flagging a problem with your equipment. It's explaining an absence so you don't mistake a privacy guard for a broken page or a network with no equipment data at all.

Same-entity networks bypass this guard entirely, for the same reason they bypass name anonymization: there is no separate franchisee identity to protect when every location is the same legal business, so per-location rows render in full regardless of how many locations exist.

A second, separate "3": the Group scope peer floor inside the detail overlay

Clicking any franchisee tile, once tiles are showing, opens that franchisee's Equipment detail overlay: a header, a Group / Regional / National scope switcher, Capacity, Utilization & age mix, and Maintenance & calibration watch sections. The Group scope pill in that overlay compares the franchisee's own numbers against the median of its active peers within your own network.

That comparison has its own floor, separate from the network-size gate described above, though it happens to use the same number today. If your network has fewer than a small handful of other active franchisees to compare against, the Group scope's peer line doesn't render a median at all. Instead, the overlay's scope footer reads:

"Peer cohort too small, need 3+ active franchisees in the network."

Don't conflate this with the small-network banner higher up the page. The banner controls whether a franchisee's tile appears at all in the network rows; this footer message controls whether that franchisee's detail overlay can show a within-network peer comparison once you've already opened it. A network can, in principle, clear the tile-visibility floor while a specific franchisee's overlay still can't compute a Group-scope median if too few of its peers have equipment data of their own on file yet. Both are k-anonymity floors in spirit, protecting a peer cohort from being small enough to reverse-engineer, but they are two different checks, evaluated at two different points in the page.

Regional and National scope in that same overlay are unaffected by either floor described in this article. They read "pending" today for every real network because the cross-network equipment benchmark hasn't seeded industry-wide data yet, not because of a small-cohort suppression. See The 'vs national' deltas on hero tiles (and why real groups see none) for that separate, unrelated mechanic.

How the three mechanisms interact, end to end

Put together, here is what actually happens when the Equipment page loads for your network:

1. 1HQ's server queries the network data for your group, the pre-computed rollup a nightly cron wrote. No query against any franchisee's PII database is possible from this code path, enforced at the database connection itself.
2. 2HQ checks your group's entity model. In an independent-operators network, every franchisee name coming back from that rollup is replaced with its stable "Franchisee #XXXX" label before it reaches any tile, row, or overlay.
3. 3HQ counts your network's currently active franchisees and compares that count against the small-network floor. If your network is independent-operators and below the floor, the three per-franchisee rows return empty and the aggregate-only banner renders in their place; the hero panel still computes and displays in full regardless.
4. 4If your network clears the floor and you click into a franchisee's tile, the detail overlay opens with that franchisee's anonymized (or real, in same-entity mode) name, its city and state anonymized to "Location anonymized" when applicable, and a Group-scope peer comparison that itself needs enough of that franchisee's own peers to have reported before it will show a median.

Every step degrades toward less information, never more, when a floor isn't cleared: a network below the size floor gets aggregates only, a franchisee overlay with too few Group-scope peers gets a plain explanation instead of a median, and no code path in this stack silently substitutes anonymized data with real names or fills in a suppressed row's absence with an estimate.

What this means for how you use the page

Read the small-network banner and the "Peer cohort too small" footer as maturity signals about your own network, not as errors to work around:

• A brand-new HQ account with one or two franchisees onboarded will legitimately see the aggregate-only banner on Equipment (and on Facilities and Fleet, which apply the same floor). This resolves itself as more franchisees come active; there is nothing to configure.
• A mature network that clears the floor overall can still have individual franchisees whose Group-scope comparison reads "cohort too small," most often because that specific franchisee is unusually new, or because the peer set for a niche metric (total purchase value, for instance, which is optional data) is thinner than the peer set for a metric everyone reports.
• If you genuinely believe your network's entity model is misconfigured (for example, your locations are actually company-owned branches, not independently owned franchisees, and you're seeing anonymized labels that shouldn't apply), that is a conversation with Verinode, not a setting to change yourself. Reach it through Settings, Group, Data posture.

Related articles

• What HQ sees: the network privacy boundary
• Equipment (Assets): what HQ sees across the network
• Equipment by Franchisee row: inventory, class coverage and capital
• Maintenance & Calibration Risk row
• The 'vs national' deltas on hero tiles (and why real groups see none)
• What HQ sees vs. what stays private: the vendor aggregate boundary
• HQ overview
• Network Health: the network home