The instruments in this post were not broken, they were not empty, and they were not late. They returned a clean number to a clear question — and it was the answer to a different question.
Population, formula and window are not metadata attached to a number. They are constituents of it, and changing any one produces a different number without making the old one wrong — which is precisely why the old one stays dangerous. This is the most expensive family in the series because nothing looks broken: a missing row prompts an investigation, while a number that is confidently, plausibly, auditably a different number gets pasted into a report and used to decide something.
Across a ninety-day window in 2026 we logged four of these on live client accounts and two timezone artifacts in our own tooling, and every repair was to the definition of what was being counted rather than to the system being measured. A companion post, Five Answer Rates, One Month, All Correct, sets out the three-part discipline in full: Population, Formula, Window. This post adds the constituent the series keeps surfacing: the instrument that produced it. Two instruments reading one channel can both be working and still disagree, and only one is authoritative.
The instances
| # | Instrument | What it said | What was true |
|---|---|---|---|
| 2 | Present-key count on a charged-lead flag | 68 charged leads, July 2026 | 49 — the flag is omitted when false, overstating 39% |
| 7 | A search-terms report | a quality verdict for the campaign | it covers a minority of the campaign's spend |
| 8 | A campaign metrics view | 0 leads on 2026-08-14 | the lead resource returns a row |
| 19 | An answer-rate formula | the assistant handled the call | a human answered and stayed on 251 seconds |
| — | UTC stamps, Central queries | 31 distinct days of 30 | a timezone artifact |
| — | Four code sites rendering timestamps | local time, labelled Z | a five-hour lie in three audit records |
The extended example: one month, five correct numbers
Between June and August 2026 we built an inbound-phone baseline for a commercial property-and-casualty brokerage that a pass/fail gate could read. June 2026 alone produced five defensible populations. The audited Analytics queue-level population records 1,160 calls, 680 (59%) answered live. The call-log population filtered to the main line in business hours records 1,385 calls in scope, 660 (47.7%) answered live under the pinned formula v1 and 49.1% recomputed under formula v2. Account-wide inbound across every channel and hour records 2,241 records over 20,851 legs. By channel, the main line carries 1,489 records at 45.7% live-answered against 752 on agent direct lines at 24.3%.
Five numbers, one month, one phone system, no two comparable. The set is trustworthy only because two rows reconcile exactly: the main-line count of 1,489 decomposes into 1,385 in-scope business-hours calls, 68 after-hours and 36 weekend, nothing left over. A population that cannot be reconciled to a wider one is a number somebody typed.
Population — the field that disappears when it is false
On 2026-08-11 we read Local Services lead data for an HVAC contractor through the Google Ads API. Counting leads by the presence of the charged-lead key returned 68 for July 2026. The true count was 49.
The mechanism is a serialization default, not a defect. Under proto3 a field holding its default value is omitted from the wire format, so a boolean that is false does not arrive as false — it does not arrive. Counting keys therefore counts leads that carry the field and leads where it was dropped for being false. The overstatement is 39%, and it is stable, repeatable and invisible: no error, no gap, no anomaly in the series.
The population you asked for was charged leads. The population you got was all leads. Both are real; only one is billable.
Formula — the test that wins unconditionally
The Connect gate had to decide, per call, whether a human answered or the automated assistant did, and formula v1 tested the assistant lane first — a test that won unconditionally, so a record from 2026-08-07 on which an agent answered and stayed on for 251 seconds scored as assistant-answered. Nothing in the output looked wrong: the rate was plausible, stable month over month, consistent with everything around it, and systematically undercounting the one event the measurement exists to count.
That companion post carries v2's human-answer marker, the readings both formulas produce on the same June 2026 population, and what became of a pass/fail bar pinned under the formula that was later retired. The transferable half is one line: a threshold derived under one formula cannot adjudicate a reading produced under another, and both sets of readings stay on the record, labelled by formula, because deleting the old ones would destroy the ability to audit anything decided while they were live.
Window — the hours nobody declared
The cheapest version of this failure is arithmetic. During our internal harness audit, 2026-07-29 to 07-31, a query requesting thirty days returned 31 distinct days, because the records carried UTC timestamps while the query ran in Central. Nothing was duplicated or missing; the window's edges sat five or six hours from where the reader assumed, so the first and last calendar days were each partly represented and both counted.
The same audit found four code sites rendering local time and labelling it Z, the suffix that asserts UTC. A five-hour lie inside three machine-readable audit records is worse than an unlabelled timestamp, because an unlabelled timestamp makes a downstream reader ask.
The instrument — two readings, one channel
On 2026-08-14 the campaign metrics view for that Local Services channel reported zero leads. The lead resource, queried for the same day and the same channel, returned a row.
Neither instrument was down. They are different products with different fill rules, and for lead-level truth on this channel the lead resource is authoritative — a decision made once and written down, because it determines the entire daily series. Built from the metrics view, that series carries a false zero. Built from the lead resource, the live read of 2026-08-17 shows the last normal day at 2026-07-28 and three leads in the nineteen days after. One version is a finding; the other is an artifact.
The scope-ceiling version is subtler. A search-terms report describes the terms the vendor chose to surface, not the campaign. On this account it covered only a minority of the campaign's spend, so any proportion computed inside it describes the disclosed slice and cannot be restated as a campaign-wide figure. We have such a proportion on file. It is not published as a campaign number, because it is not one.
What would prove this wrong
- An independent recount of July 2026 charged leads from the same export returning 68. Then present-key counting was right and the proto3 explanation fails.
- A routing record showing the assistant did handle the 251-second call on 2026-08-07. Then v1 was labelling correctly and its retirement was backwards.
- The metrics view and the lead resource agreeing across a full month of days. Then there is one instrument, not two, and the authority rule buys nothing.
- The 31-days-of-30 result reproducing when store and query run in the same timezone. Then it is not a timezone artifact.
- Two of the five June 2026 populations reconciling to one denominator. If they do, the guard keeping them apart is overhead.
Four labels, one sentence
Take the number in your monthly reporting you would least like to be wrong about, and write its population, formula, window and instrument in a single sentence. If nobody in the reporting chain can produce that sentence, the number is not a fact yet — it is a reading, and readings need a validated instrument behind them.
Which is where this series ends. The final post assembles the discipline into a working checklist.
Get the kit, not just the theory.
We'll send the build checklist behind this post — and the next pillar when it ships. One email, no drip sequence. Unsubscribe in one click.
