How the network read is built (and what it never shows)

What this article is for

Forecasting shows your network's demand posture: how many locations are trending busier, steady, or cooling over the next 90 days, where that concentrates by region, and what the wider industry's published indicators are doing. The network demand outlook and what it means articles walk through what each element on the page shows. This article is the layer underneath those: exactly how that read gets computed, exactly what data is allowed to move from a location's own account into HQ's view, and exactly why the page shows nothing at all once your network is small enough that a busier/steady/cooling split would really be describing one or two locations.

None of what follows is a policy promise you have to take on faith. It is a description of code that runs on a schedule, a database column that either has a value in it or doesn't, and a floor that either has been cleared or hasn't. If you want the wider privacy contract that governs every HQ surface, not just Forecasting, read What HQ sees: the network privacy boundary. This article is the Forecasting-specific version of that story, in more mechanical detail.

The one-sentence version

Every number on Forecasting is either a published, public industry figure, or a count of how many locations landed in a posture bucket that public figure alone produced. A location's own revenue, margin, jobs, invoices, adjuster correspondence, or any other business record never enters this calculation, and never crosses from the location's own account into HQ's database at any point in the pipeline.

How one location's own read gets built

Before the network read exists, each location has its own demand outlook, the same read that operator sees on their own Forecasting section inside their IQ account. That per-location outlook is what HQ counts up. Here is how it is produced:

1. 1Look up the location's state. The only fact about the location this step reads is which US state (or Canadian province) it operates in, nothing else about its business.
2. 2Resolve the state to a region. The state maps to one or more region keys (for example, a Florida location maps to both "South" and the Gulf/Atlantic hazard overlay, since it faces both sets of regional conditions). This is the same shared region taxonomy IQ uses for its own industry data tab.
3. 3Pull the published indicators for that region. A set of public reference series, claims frequency, catastrophe and severe storm losses, the hurricane season outlook, residential construction activity, contractor backlogs, water damage claim share, home sales activity, consumer sentiment, mortgage rates, and a few cost and wage indicators tracked separately, scoped to the location's region plus the shared national series.
4. 4Score the indicators into a single momentum read. Each indicator carries a weight and a direction (a rising value can mean more work, or less, depending on the indicator). The weighted result lands on one of three postures, busier, steady, or slower, along with the two or three indicators that moved the needle most.

This computation is deterministic and pure: the same state, on the same day, with the same published indicator values, always produces the same outlook. It never reads a location's own jobs, revenue, invoices, or any other private record. The full mechanics of the weighting and the indicator table live in What's driving demand: the industry driver table on the IQ side; this article only needs you to know that the input is entirely public data and the output is one of three words.

The pii-to-core bridge: the one cron that touches both sides

Your location's state lives in your own account's private database (the the private layer schema). HQ's Forecasting page reads from a completely different database (the the network layer schema) that HQ's server is permitted to query. Something has to move the state-derived posture from one side to the other, once a day, without ever letting anything else cross with it. That something is a single scheduled job, and it is the only piece of code in the entire platform allowed to read from both sides.

The job is the product, called once per network from the hq-aggregate-refresh cron. It runs like this:

1. 1For your group's full roster of member operator IDs, look up each operator's state field from the your operator data table. That is the entire read against the private database: one column, for every member, and nothing else.
2. 2Compute (or reuse, if already computed for that state today) the demand outlook for each distinct state represented.
3. 3Count how many locations land in each posture (busier, steady, slower), and how many locations sit behind each region.
4. 4Write one row into the network data: your group's ID, today's date, the total member count, the busier/steady/slower counts, the dominant posture, the by-region breakdown, and the top shared drivers. Nothing else goes into that row.

That write is an upsert keyed on the group and the date, so re-running the job for the same day replaces the same snapshot rather than piling up duplicate rows. HQ's Forecasting page never calls this job directly. It only ever reads the most recent row already sitting in the network data, through getGroupDemandSummary in the product, which is itself restricted to the the network layer schema.

What HQ's read side is and isn't allowed to touch

Once the snapshot is written, HQ's application server reads it back through hqAdmin, the client every HQ-side page and query is required to use. That client is bound to a database role with a hard, schema-level permission revoke on the the private layer schema: a query against a location's private data from HQ's server does not get silently filtered or blurred, it is refused outright by the database itself, with or without the right credentials in front of it. HQ's Forecasting queries only ever touch the network data (your network's demand snapshot) and the public the benchmark data catalog (the same published series feeding Industry signals). There is no query path from Forecasting, or anywhere else in HQ, into a location's jobs, invoices, margin, or any other record it enters into its own IQ account.

The 5-location floor, and why it exists

Counting how many of your locations are busier, steady, or slower is safe when the count is large. It stops being safe when it's small. A network of three locations reading "2 busier, 1 steady" is not really a network statistic, it is a description of two specific, identifiable businesses dressed up as a distribution. So Forecasting will not publish a network split at all until your roster clears a floor: at least 5 locations with a state on file (and therefore a computed outlook) in your network.

This floor gates:

• The hero band's dominant posture word, location count, and distribution bar
• The "What it means" gauge's actionable count and guidance
• The network read paragraph beneath the hero band
• The By region row

It does not gate the Industry signals row at the bottom of the page. That row is the shared national indicator catalog, not a count of your locations, so it renders the same way whether your network has 2 locations or 200.

The cold state, verbatim

Below the floor, the entire top-of-page hero collapses into one full-width placeholder card. This is exactly what it says, word for word:

Network demand · next 90 days Building the network read Once at least 5 locations are contributing, the network's demand posture, the busier / steady / slower split, and the by-region breakdown appear here.

There is no separate placeholder for the "What it means" gauge, the network read paragraph, or the By region row in this state; the one cold card stands in for all of them. Industry signals still renders underneath it, unaffected, since it never depended on your roster size in the first place.

This is not a stalled page, a bug, or a sign that ingestion is behind. It is the same anonymity discipline applied everywhere in HQ: an absence of qualifying data produces an honest, plainly worded empty state, never a distribution stretched thin enough to reverse-identify the one or two locations behind it.

What Forecasting never shows, at any network size

Clearing the 5-location floor unlocks the distribution. It does not unlock anything beyond it. At no size, small or large, does Forecasting ever show:

• A single location's own revenue, margin, job count, invoice, or receivable figure
• A single location's name attached to its own posture (the by-region and hero-band counts are always aggregate counts, never a labeled list of which locations sit in which bucket)
• Anything derived from adjuster correspondence, carrier relationships, or client records
• A distribution built from fewer than the location floor, no matter how it's worded or caveated

What does cross from a location into this page, ever, is exactly one fact: which state it operates in, used only to select which region's public indicators apply. The posture that results from that one fact is public-data math, not private-data disclosure.

Best-practice example

Say your network has 14 active locations, all with a state on file. The cron's morning sweep writes today's snapshot: 7 busier, 5 steady, 2 slower, dominant posture busier. The hero band reads Busier, 14 locations, the distribution bar shows the matching percentages, and the "What it means" gauge shows 7 locations, Plan capacity. Nothing about that computation ever touched a P&L, an invoice, or a job record belonging to any of the 14 locations, it is 14 state lookups and one public indicator table, rolled up once a day.

Now say a second network on the platform has 3 locations. Its snapshot would, mechanically, produce the same kind of busier/steady/slower counts. Forecasting withholds it anyway, because 3 is below the 5-location floor, and shows the "Building the network read" card instead. The moment that network's roster (with states on file) reaches 5, the exact same pipeline that already ran quietly in the background starts publishing the split, with no migration, no manual unlock, and no change to how the underlying numbers are computed.

Related articles

• Forecasting: your network's demand posture, next 90 days
• Network demand outlook: Busier, Steady, or Cooling
• "What it means": the locations to plan for and the network move
• What HQ sees: the network privacy boundary
• Industry Data tab: macro series for the whole network
• Coverage labels and the anonymity floor
• HQ Location Directory
• Forecasting: past, present, and future demand, the same per-location read from inside IQ
• What's driving demand: the industry driver table