The HQ privacy boundary in the Vault

What this article covers

The Vault (HQ sidebar, hq.verinode.ai/vault) is where your network's generated reports live: Discovery Day Packs, quarterly reviews, compliance audits, and member cohort reports. Below the document rows sits the Access trail, the log of who on your HQ team pulled which document, and when.

Both surfaces are safe to hand to a board member, a prospective franchisee, or outside counsel without a second thought, and this article explains exactly why, in three parts:

1. Every document in the Vault, and every reference line in the Access trail, is built from network-level aggregates. There is no code path from either surface to a single member's private business records.
2. Sensitive text that does need to travel, an internal message sent to the network, a member's name attached to a rollup row, is protected at rest by an encryption key scoped to your network alone, with a deliberate split between what your admins can decrypt and what Verinode's own automated systems can.
3. The Access trail's own attribution has one narrow carve-out: on demo and tester networks, teammate names are hidden from anyone but the network's Account Owner, so a shared walkthrough account never shows one tester another tester's real activity.

Members own their own data. HQ's role is network oversight, aggregates and compliance, never a window into any one member's day-to-day records. Nothing below changes that; it explains the mechanics that hold it in place.

Part one: the Vault is aggregates, not records

What actually populates a Vault document

Every report type the Vault holds, Discovery Day Pack, quarterly review, compliance audit, member cohort, is generated from a fixed set of network-level figures: counts, medians, percentiles, and compliance rates computed across your network or a defined cohort within it. None of it is assembled by reading a single member's underlying business records directly.

Concretely, when a report is generated:

• A quarterly review draws on your network's health composite, active-versus-total membership counts, median gross margin, vendor and carrier program counts, a cash-runway breakdown, and your network's certification-current rate. Every one of those is a network-wide or cohort-wide figure, never one member's raw profit-and-loss or bank balance.
• A Discovery Day Pack presents cohort-level statistics, opt-in counts and percentile distributions across a defined group, never a single named member's figures.
• A compliance audit and a member cohort report compare groups against each other or against a standard, in aggregate. Neither exposes one member's numbers to another.

This isn't a filter applied after the fact to a report that could otherwise show more. The process that builds a Vault document simply never reaches into a member's own account data to begin with. It only ever reads the same kind of already-computed, network-level rollups that power the rest of HQ, figures refreshed on a schedule (a nightly network rollup), not pulled live from a member's own records at the moment a report is generated.

The Access trail's reference line is the same kind of data

Below the document rows, each Access-trail row carries a short reference line describing which document was pulled: a section name, a shortened cohort reference, a fiscal year and quarter, a franchisee count, or a methodology-version tag, whichever applies. Every one of those describes the shape of the aggregate the document covers, not any individual member. If none of them apply to a given pull, the line shows a plain dash rather than reaching for something to display.

Part two: how the group encryption key protects sensitive text

Aggregation answers the question "does HQ ever read a member's raw records" (no). A separate mechanism answers a narrower question: for the sensitive text that legitimately does need to live at the network level, an internal message you send to your members, a member's own name attached to a rollup row, how is that text protected once it's stored?

Every network has its own encryption key, generated once for that network and never shared with another network or with Verinode's general infrastructure. That key exists in two protected forms, built for two different jobs:

• Admin-protected. This form is wrapped using an authorized HQ admin's own personal, password-derived key. Practically, that means Verinode's infrastructure, not customer support, not the database, not an engineer with production access, can decrypt this content without an authorized admin's own key actually present, which only happens through that admin's live, signed-in session. If no admin session is active, this content simply cannot be read, by anyone.
• Shared. This form is wrapped so Verinode's own authorized background processes, the nightly rollup that keeps network figures current being the clearest example, can decrypt it automatically, without a human signed in at the time. That's a deliberately weaker guarantee than the admin-protected form, since Verinode's server-side systems retain the ability to unwrap it. It exists because some writes have to happen on a schedule, with no admin present to unlock anything.

Where this shows up

An internal message you broadcast to your network is the clearest concrete example: it's stored as ciphertext under the admin-protected key, alongside a plaintext copy kept purely as a safety-net fallback for the rollout period. When your session has the network's key unlocked, the message decrypts from the protected copy. If a decrypt ever fails, for any reason, the page falls back to the plaintext copy rather than showing an error, and the failure is logged so it's visible to Verinode's engineering team rather than silently normalized.

The same key family protects a member's name wherever a name is attached to a network aggregate row elsewhere in HQ: the row stores an encrypted copy alongside a plaintext fallback, and the page decrypts the protected copy using your network's key when it loads. The counts, dates, and percentages sitting alongside that name are never encrypted; they carry no identity on their own, so the encryption effort goes specifically toward the one field that names a real person or business.

Part three: teammate-identity redaction on the Access trail

The Access trail attributes every document pull to whoever pulled it, by name, so the log is useful evidence in a compliance review. On a demo or tester network, that attribution is narrowed for anyone who is not the network's Account Owner: rows that would otherwise show a real teammate's name instead show the neutral label "A teammate." Rows attributed to a signed counsel-review link still show "Outside counsel" either way, since that's not a teammate identity to protect in the first place, and a row that can't resolve any name at all falls back to a plain "Group user" label.

Why this exists

Demo and tester networks often have several people sharing one HQ workspace to explore the product together. Without this redaction, one tester could see another tester's real name attached to a document pull, on a network that was never meant to model real teammate relationships in the first place. The Access trail hides that identity rather than let a demo walkthrough imply people know things about each other that they don't, in real life, actually know.

Who still sees real names, and when

• On a live production network, names always resolve normally for every teammate with Vault access, regardless of role. This redaction never touches a real member network.
• On a demo or tester network, the network's Account Owner still sees every real name, because they're auditing their own network, and the redaction exists to protect other testers from each other, not from the owner.
• Everyone else on a demo or tester network who isn't the Account Owner sees "A teammate" in place of a name.

The fail-open rule

If HQ can't determine whether a network is a demo network, or can't determine whether the caller is the Account Owner, for any reason, it defaults to showing real names, not redacting them. A live, real member network should never have its Access trail silently degraded to anonymous labels because of an unrelated lookup failure. The redaction only activates when HQ can positively confirm both conditions at once: this is a demo network, and this caller isn't its owner. Short of that confirmation, the trail behaves exactly as it does for every production network, names attached, nothing hidden.

Putting it together

1. 1Open Vault from the HQ sidebar, or go to hq.verinode.ai/vault directly.
2. 2Any document you pull, or hand to a board member, a prospective member, or outside counsel, contains network-level figures only. There is no private member record to redact from it, because it was never in there to begin with.
3. 3Scroll to Access trail to see who on your team pulled which document, and when. On your own live network, every pull is attributed by real name.
4. 4Sensitive text you send to the network, an internal message, is protected at rest under your network's own encryption key, decrypted only through an authorized admin's active session or, for automated writes, Verinode's server-side systems, never a general database read.
5. 5If you're exploring a demo or tester network and see "A teammate" instead of a name, that's expected: you're not that network's Account Owner, and the network itself is a demo, not a production system.

Related help

• The Vault: your HQ document library
• The access trail: who pulled what, when
• What HQ sees: the network privacy boundary
• How certification rollups are built and what HQ can and can't see
• HQ Compliance