What an HQ app can and cannot read

Every HQ app, Network Review, Franchisee Health, Program Negotiation, Recruitment Story, runs a specialist over data. The natural question from a location owner, a franchisee, or an association mem…

4 min read·Updated August 25, 2026
On this page

The hard line, applied to apps

Every HQ app, Network Review, Franchisee Health, Program Negotiation, Recruitment Story, runs a specialist over data. The natural question from a location owner, a franchisee, or an association member is: which data? The answer is the same line that governs every other HQ surface, and it does not move for an AI run: an HQ app reads network-level aggregates and the industry layer. It never reads an individual location's private business data.

Concretely, the specialist behind an HQ app can read your network's pre-computed rollups, the margin medians, cycle-time aggregates, carrier mix, reputation composites, coverage figures, program performance, and roster standing that the overnight aggregation computes for your group, plus Verinode's published industry reference data. It cannot read a location's invoices, job records, estimates, adjuster correspondence, payroll, or anything else a member entered into their own IQ account. Not summarized, not anonymized on the fly, not at all: those records live in a separate database the HQ side has no path to.

Enforced by the database, not by prompt discipline

It would be easy, and worthless, to enforce this with an instruction: tell the model "do not look at private data" and hope it listens. That is not how the boundary works. The application server that serves every HQ page and every HQ app connects to the database under a dedicated role, and that role carries a hard, schema-level revoke on the entire private data store. A query against a location's private records from the HQ side does not return an empty result; it is refused by the database engine itself, exactly as described in what HQ sees, the network privacy boundary.

An HQ app inherits that boundary automatically, because the specialist's reads go through the same role. There is no special AI credential, no elevated path for "just this run," and no way for a cleverly worded question to talk the specialist into a table its connection cannot reach. If you ask an HQ app about one location's raw books, the honest answer it can give is the only answer it can give: that data is not visible from HQ, by design.

A second guard sits on top: only the vetted network specialists can be run through an HQ app at all. The run path checks the requested specialist against an allow-list of group-side analysts, so an app cannot be pointed at an operator-side specialist that works with private data.

Note

This is the same defense-in-depth posture the rest of HQ uses: the database refuses the query, the HQ code has no import path to the private data client, and an automated check in the build pipeline rejects any code change that tries to create one. The AI layer sits on top of those guarantees; it does not replace them.

Your results are keyed to your network

The findings an HQ app produces are stored scoped to your group. Every read of a saved result carries your network's identity, resolved from your sign-in session on the server, never from anything the browser sends. Ask for a result that belongs to another network and there is nothing to deny you: from your account's vantage point, that result simply does not exist. The same is true of the PDF export, which resolves your own network first and will only render a result that belongs to it.

That cuts both ways, and the symmetric direction matters just as much: another network, including one running the very same app on the very same day, can never see your findings, your run history, or the fact that you ran anything at all.

What the industry layer contributes, and what it protects

Where a finding sets your network against an outside reference, that reference comes from Verinode's industry layer: anonymized figures contributed by operators across the platform, published only as aggregates and only once enough distinct operators stand behind a number. The operators behind an industry figure are never identified, and a comparison appears as more operators contribute; its absence is never about anything missing from your data. An HQ app cannot narrate its way past that floor, because the floor is applied before the data reaches anything the specialist can read.

What this means for what you can tell your network

When a franchisee or member asks what the "AI at HQ" can see about them, the answer is short and checkable:

  • It sees the same aggregates HQ leadership already sees on the Network page: network medians, spreads, coverage, compliance standing, and roster status.
  • It sees nothing from inside their own IQ account: no jobs, no invoices, no correspondence, no financial records.
  • The restriction is enforced by the database role the HQ product runs under, so it holds regardless of what anyone types into a run.
  • The findings it produces belong to your network alone and are invisible to every other network on the platform.

That structure is why an HQ app's finding is worth trusting in a leadership meeting: it is built only from numbers your network is entitled to see, through the same boundary that protects every location's own book.

Data sources

Data sources

  1. 1.Your network's pre-computed aggregates and roster standing. Your network.
  2. 2.Anonymized, floor-protected industry reference data. Verinode intelligence layer.
  3. 3.Verinode Data Use Policy. Verinode.
Was this helpful?