Where equipment data comes from and how fresh it is
Everything on HQ's Equipment page, the hero count, the Maintenance & Calibration Risk row, Refresh Cycle, and Equipment by Franchisee, comes from one table: the network data. That table does not up…
On this page
The short version
Everything on HQ's Equipment page, the hero count, the Maintenance & Calibration Risk row, Refresh Cycle, and Equipment by Franchisee, comes from one table: the network data. That table does not update itself when a location logs a new dehumidifier or clears a calibration. It is written once a night by a scheduled job called hq-aggregate-refresh, which reads each member operator's equipment records out of the PII database and rolls them into a single summary row per operator. HQ's own Equipment page never runs a query against a location's PII data directly. This article covers exactly how that rollup works, on what schedule, and what "fresh" actually means when you're looking at a number on screen.
Note
For what the Equipment page shows and how to read each row, see Equipment (Assets): what HQ sees across the network first. This article is the pipeline underneath it, not a tour of the page itself.
The one bridge from PII to core
Verinode's data model keeps two databases apart on purpose. A location's actual business records, its invoices, jobs, and equipment log, live in a PII database scoped to that one operator. HQ's application server has no path to query that database: the connection is refused at the schema level, regardless of who is signed in. Instead, HQ reads from the network layer, a separate database that only ever holds pre-aggregated rollups.
hq-aggregate-refresh is the only process that bridges the two for this section. It is a scheduled job with two kinds of database access at once: it can read your operator data (the location's own equipment log) and it can write the network data (the rolled-up row HQ reads). Nothing else in the HQ product touches your operator data. That single, narrow bridge, one job, one direction, PII in and core out, is what keeps the privacy boundary real rather than just a display rule.
What the job actually reads
For every operator in your network's roster (every member listed in the network data for your group, whether or not they've been active recently), the job pulls that operator's rows from your operator data: each piece of equipment's status, ownership type, equipment class, purchase date, purchase price, and its next maintenance and calibration due dates. It does not read serial numbers, vendor names, condition notes, or anything else sitting on that record, only the specific fields the Equipment page's numbers are built from.
From there it builds one summary per operator:
- Counts by status. How many pieces are in service, in storage, or retired. Anything not retired counts toward "active equipment."
- Counts by ownership. How many are owned, leased, or financed.
- Equipment class coverage. The number of distinct equipment classes that operator has active equipment in (retired units are excluded from this count), the figure behind "N classes" on the Equipment by Franchisee row.
- Capital value. The sum of purchase prices on file, in cents internally, shown on the page as a rounded dollar figure. A unit with no purchase price recorded simply contributes nothing to this sum, it isn't treated as zero-value.
- Average age. Computed from each unit's purchase date to the day the job runs, averaged across every unit that has a purchase date on file, then rounded to one decimal of a year for display.
- Equipment over 5 years old. A straight count of active (non-retired) units whose purchase date is more than five years before the run.
- Maintenance and calibration posture. For active equipment only, the job checks whether the next maintenance due date and next calibration due date have already passed (overdue) or fall within the next 90 days (due soon). Retired equipment is excluded from every maintenance and calibration count, since it's no longer in a rotation that needs servicing.
That per-operator summary, plus the operator's location name (read from your group's own roster, the network data, not from PII) and an encrypted copy of that name, is what gets written as one row into the network data, keyed by group and operator. If an operator has equipment records but isn't listed in your group's roster directory yet, no summary row is written for them until the directory catches up, which is why a brand-new member can show equipment activity on their own IQ account before it appears on HQ's Equipment page.
Note
A location's real name is only ever resolved by this same aggregator job, which does have the PII-side access needed to read an operator's business name. HQ's read side never performs that lookup itself, it only ever sees the name the job already wrote into your roster. Whether that name then displays as-is or as an anonymized label like "Franchisee #A1B2" on the Equipment page depends on your network's entity model, covered in Equipment (Assets): what HQ sees across the network.
The rollup HQ reads is a sum, not a snapshot of anything live
The hero numbers on the Equipment page (total active equipment, capital value, maintenance overdue, equipment over 5 years) are computed by summing and averaging the per-operator rows already sitting in the network data, the moment HQ's page loads. That part is instant. What's "as of last night" is the content of those per-operator rows themselves: the counts, the age, the maintenance flags. So the page always renders quickly, but the numbers it renders reflect equipment data as it stood at the previous overnight run, not the current instant a location's team member logs a new unit.
The schedule
hq-aggregate-refresh runs on a fixed overnight window: it fires every 10 minutes between 06:00 and 07:50 UTC. It does not run once and finish, it runs as a checkpointed sweep across every group on the platform. Each 10-minute firing picks up where the last one left off, working through groups in order and saving its place after each one. Once every group's rollups (equipment included) have been written for the night, the sweep marks itself complete and later firings inside that same window simply do nothing.
This checkpointing exists because a single run can't reliably get through every group on the platform in one pass as the number of networks on Verinode grows. Splitting the work across a two-hour window with a resumable cursor means a slow group, or a brief platform hiccup partway through the sweep, doesn't leave later groups in the queue permanently stale, the next 10-minute firing simply resumes from where the cursor stopped. If the sweep doesn't finish inside its window on a given night, an internal health check flags the incomplete sweep so it gets attention rather than quietly rolling forward with stale data.
Heads up
There is no manual "refresh now" control on the Equipment page. If you make a change to an operator's equipment on their own IQ account, or a new operator joins your network, the change won't reach HQ's Equipment page until the next overnight run completes.
What this means when you're reading the page
- A number you see at 9am reflects last night's run, not this morning's activity. If a location's team logs a new dehumidifier purchase at 8am, it won't show up on HQ's Equipment page, or in that location's overlay, until the following night's rollup.
- The Maintenance & Calibration Risk and Refresh Cycle rows are similarly overnight-fresh. A location clearing an overdue calibration this afternoon will still show as overdue on HQ's page until the next run picks up the cleared date.
- Because the rollup reads every member operator in your roster on every run, a newly onboarded location's equipment starts appearing on HQ's Equipment page the first night after both its equipment records and its roster directory entry exist, whichever lands later.
- This lag is the same trade every HQ rollup makes (Facilities, Fleet, compliance, and the rest), in exchange for HQ never running a live query into any location's own business database. Freshness is measured in hours, not minutes, and that's a deliberate boundary, not a performance shortfall to be fixed later.
Related articles
- Equipment (Assets): what HQ sees across the network
- What HQ sees: the network privacy boundary
- HQ equipment hero: network equipment at a glance
- Maintenance & Calibration Risk row
- Refresh Cycle row
- Equipment by Franchisee row
- HQ overview
Data sources
- 1.Verinode. Verinode.
- 2.Verinode. Verinode.
- 3.HQ Franchise Portal Specification. Verinode.
- 4.Verinode Data Use Policy. Verinode.