The privacy boundary: aggregates and rollups, never raw member data

What this article is about

Verinode HQ is the network intelligence layer that sits on top of every membership in your network, but it does not sit on top of any single membership's raw business data. This article explains that boundary concretely, using the Operations section as the working example: what data Operations reads, where that data comes from, how it is encrypted in transit through the system, and exactly what an HQ user can and cannot see about any one franchisee. The same boundary applies across every HQ section (Margin & Cash, Growth, Standards, Programs), Operations is simply the clearest place to walk through it because its numbers are visibly rollups rather than transaction-level detail.

Read this once and you will recognize the pattern everywhere in HQ: a franchisee's day-to-day business, its jobs, its invoices, its bank balance, lives in that franchisee's own Verinode IQ account. What reaches HQ is a periodic, pre-computed snapshot of a small set of operational indicators, computed on the operator side and written up as aggregate evidence. HQ never runs a query against a franchisee's underlying records, because HQ has no access path to them at all.

Where to find Operations

Open Operations from the HQ sidebar at hq.verinode.ai/operations. It renders in the same card-and-row shell as the rest of HQ: a hero panel at the top, then a stack of horizontally scrolling rows, Capacity Pressure, Process Maturity, Shared SOPs, and Bulk Buy. Clicking almost any tile opens a slide-over with more of the same kind of data; clicking a franchisee tile navigates to that franchisee's summary page under Franchisees.

The hero: three network-wide numbers plus a cycle-time comparison

At the top of Operations is a hero panel. The eyebrow line reads "Cycle time · Group median (days)" and the large headline number is your network's median job cycle time in days, computed across every active member. Beside it is a pill showing either a percentile (for example "P42 (lower is better)", meaning your network's median cycle time sits at that percentile against every other network Verinode tracks) or, when the comparison cannot be shown, a raw sample-size readout. Below the headline, a line of text repeats the industry median cycle time alongside two more headline numbers, your network's Process Maturity percentage and Capacity Utilization percentage.

Three secondary tiles sit beside the main figure:

• Process maturity, a percentage, labeled "Above SOP coverage threshold." This is the share of your network's operational maturity signal that clears an SOP-coverage bar Verinode tracks internally. It does not list which member cleared it or by how much, it is a single network-wide percentage.
• Capacity utilization, a percentage, labeled "Network active jobs vs cap." This is how full your network is running relative to its available capacity, aggregated across every member.
• Fleet items, a count, labeled "Equipment registered." The total pieces of equipment members have logged network-wide.

When no cycle-time data has flowed in yet, the subtext reads "Cycle time appears as members share job data." That is not a broken page, it is the literal empty state: cycle time only appears once enough members have jobs recorded on their own side long enough to compute a median.

Row 1: Capacity Pressure

What it is. A list of members whose capacity utilization is running hot, meaning their active job volume is stretching their available crew and equipment capacity.

What you see. One tile per stretched member, sorted highest utilization first, capped at six visible in the row (open the row's slide-over to see the full list). Each tile shows:

• A label, "Stretched" for members over 80% utilization, or "Maxed Out" for members over 95%.
• The franchisee's name as the headline.
• The utilization percentage as the subline, for example "87% Capacity."
• The member's average cycle time in days, if known, as the meta line, for example "18d Cycle Time."
• A ring gauge visual reflecting the percentage, colored amber for Stretched and red for Maxed Out.

Empty state. When no member is over 80% utilization, the row reads "All members operating with healthy capacity headroom." In the expanded slide-over, the same condition reads "No member is running over 80% capacity. Pressure points show up here when utilization tightens."

What to do. Capacity Pressure is a leading indicator: a member running Maxed Out for a stretch is a candidate for the kind of intervention HQ exists to enable, temporary resource sharing, a hiring push, or workload redistribution, decided by leadership, never by Verinode. Clicking a tile opens that franchisee's summary page under Franchisees.

Row 2: Process Maturity

What it is. A per-member rollup of how much of that franchisee's work is running under documented SOPs (standard operating procedures), the clearest single indicator of operational maturity Operations tracks.

What you see. One tile per active member (up to twelve visible in the row), showing:

• A label: Mature (80% SOP coverage or higher), Partial (40 to 79%), Low (under 40%), or Pending when no coverage figure exists yet for that member.
• The franchisee's name as the headline.
• SOP coverage as a percentage in the subline, for example "63% SOP coverage," or "Awaiting data" when unknown.
• Average cycle time in days as the meta line, when known.
• A gauge visual, green for Mature, amber for Partial, red for Low.

Empty state. With no members in the network yet, the row reads "Process maturity will appear as members are added."

What to do. A cluster of Low or Partial members is a signal for a Programs-side push (documented SOPs, training, standards enforcement), see Programs and Standards for how HQ turns a maturity gap into a coordinated network response.

Row 3: Shared SOPs

What it is. The network's library of standard operating procedures that individual franchisees have chosen to publish for the rest of the network to adopt. This is the one place in Operations where content originates from a specific member by name, and it is opt-in: a franchisee shares a process deliberately, it is not extracted from their private records.

What you see. One tile per shared SOP, most recent first, labeled "Shared SOP," with:

• The SOP's title as the headline.
• The service line and the sharing franchisee's name as the subline, for example "Water Mitigation · by Riverside Restoration," or just "By [name]" when no service line is tagged.
• Adoption and view counts as the meta line, for example "4 adopted · 22 views."

Opening a tile shows the full SOP body alongside the same adoption and view metadata, and a "Shared by [name]" attribution when no body text is available yet.

Empty state. "Network SOP library is empty. When a franchisee earns network adoption, share their SOP from the operator-side processes view (anonymized before write)." In the slide-over, the equivalent copy reads "Shared SOPs land here when members publish a process to the network library."

Row 4: Bulk Buy (fleet)

What it is. A rollup of equipment classes across the network's registered fleet, surfaced to identify categories where enough members run the same equipment class that a coordinated, network-wide purchase would beat individual buying power.

What you see. One tile per equipment class, bulk-buy candidates listed first, then the rest, capped at twelve visible in the row:

• A label, "Bulk-buy" for a flagged class, or "Class" otherwise.
• The equipment class name as the headline (humanized from the underlying category, for example "Cube Van" or "Service Truck," never a raw database slug).
• Total units registered across the network as the subline, for example "142 units across network."
• The count of members actively running that class as the meta line, for example "9 operators."

A class is flagged as a bulk-buy candidate once enough distinct members across the network are running it that a group purchase conversation is worth having. Verinode does not publish the exact operator count behind that flag, the flag itself is the actionable signal, not the threshold.

Empty state. "Fleet inventory will appear as members add equipment."

What to do. A flagged class is a prompt to open a vendor or manufacturer conversation on behalf of the network, HQ decides whether and how to pursue it; Verinode surfaces the pattern, it does not negotiate or purchase on your behalf.

How this data actually gets to HQ, and why it can never be raw

This is the part worth understanding once, because it explains every empty state, every "aggregates only" statement, and every place a number here is coarser than what a franchisee sees about their own business.

Every number on this page (process maturity, capacity utilization, fleet counts, per-franchisee cycle time and SOP coverage) comes from exactly one place: a single JSON payload called the aggregate, stored on the most recent row of the network data for your group, under an operations key. Verinode's Operations page code does not query jobs, invoices, crew schedules, or equipment logs. It reads one snapshot row, decodes its operations section, and renders it. That is the entire read path.

That snapshot is not written by HQ, and it is not written live. A scheduled aggregator job runs on the operator side, where each franchisee's real business data (their jobs, their financials, their fleet) actually lives, in their own Verinode IQ account, in the PII-side database that only that operator's own session and Verinode's operator-facing infrastructure can read. The aggregator computes the rollup numbers you see, process maturity percentage, capacity utilization percentage, cycle time, SOP coverage per member, fleet totals per equipment class, and writes only those computed numbers into the group's shared snapshot. The transaction-level records those numbers were computed from never leave the operator side. HQ receives the output of the computation, never the inputs.

The snapshot is encrypted, not just access-controlled. The the aggregate column on the nightly network rollup has a sibling column, evidence_ciphertext, holding the same payload encrypted under the group's shared vault key (a KMS-wrapped data encryption key scoped to your group). Every HQ read path, including Operations, decodes the ciphertext first: it unwraps the group's shared key and decrypts the payload, falling back to the plaintext the aggregate column only if no ciphertext is present yet (a rollout safety net, not a normal-path behavior). In practice this means the aggregate rollup itself is encrypted at rest, on top of the fact that it was already stripped down to computed percentages and counts before it was written.

What HQ can see about a single franchisee, and what it cannot. Click a franchisee tile anywhere in Operations and you land on that member's summary under Franchisees. What you can see there is: their name and location, their membership status (seeded, invited, or active), how long they have been in the network, and the same category of rollup numbers Operations already showed you, their process maturity, capacity utilization, cycle time, certification status, and equipment counts, all pulled from the same aggregate snapshot plus the network directory (the network data, which holds only the name, location, and status HQ needs to run the network, not business data). What you cannot see, at any zoom level, is a single job, a single invoice, a client name, a crew member's schedule, a bank balance, or any other record-level detail. There is no drill-down path from a percentage to the underlying rows, because the underlying rows are never transmitted to HQ's side of the system in the first place. The privacy boundary is not a permission check HQ passes through, it is a data path that physically does not exist.

Why the boundary is built this way

Verinode HQ exists to give franchise leadership a network intelligence layer, patterns, rankings, and compliance visibility across every membership, without ever becoming a system that can see into any one franchisee's private business. That distinction is the entire basis of trust the platform depends on: franchisees contribute operational signal knowing HQ receives rollups, never their transaction-level data, and HQ gets a network view no individual membership's own software could ever produce. Verinode is an independent data trust, not a member of your network's chain of command, and the aggregate-only, encrypted-in-transit path from operator to HQ is what makes that independence real rather than a claim in a terms-of-service document. Leadership decides what to do with what Operations shows; Verinode's job stops at surfacing the pattern.

Related reading

• HQ overview, the full HQ shell and how Operations fits alongside the other sections.
• Network health, the network-wide health signal that Operations' capacity and maturity rollups feed into.
• HQ benchmarks, how group-vs-rest comparisons like the cycle-time percentile are computed and gated network-wide.
• HQ programs, turning a Process Maturity gap into a coordinated network program.
• HQ standards, enforcing the SOP coverage and compliance bar behind Process Maturity.
• HQ compliance, the certification and compliance layer that reads the same aggregate path.
• Broadcasting to your network, the deliberate, opt-in publishing pattern Shared SOPs also follow.

Data sources