POS intelligence · one location of a 13-location restaurant group across the Mountain West
Six months of one location's sales, reproduced to the penny
The question
You asked whether a figure read from the warehouse will still be the same figure when someone checks it later.
What we measured
One location's daily net-sales view in the warehouse covers 181 days, 15 October 2025 to 14 April 2026, and sums to $1,443,440.77. The figure was first stated in April 2026 and reproduced exactly, to the penny, on a second read in September 2026 with a single query over the same view: same day count, same first and last date, same total.
What we built
The POS sync writes each location's orders into the warehouse, and a daily net-sales view is derived from them with one row per business day. A tie-out is one query against that view, which is why it can be repeated by anyone with read access and why the second read is the proof.
$1,443,440.77net sales, one location, 181 days (15 Oct 2025–14 Apr 2026), reproduced exactly on re-read
181business days in the view for that window
Read from the warehouse daily-sales view on 13 September 2026, reproducing the April 2026 figure.
POS intelligence · a 13-location restaurant group across the Mountain West
The sync that stopped reading after page one
The question
You asked why a sales trend built from the warehouse looked worse than the restaurants felt.
What we measured
The live POS sync was reading only the first page of each multi-page response, so historical check data in the warehouse was incomplete. On the sampled days a large share of the checks had never arrived in the warehouse. An early sales comparison built on the incomplete data was marked unreliable.
What we built
The fix changed the sync to follow the paging header the POS uses on those endpoints and added a backfill job to reload the affected history. Both shipped in one change on 9 June 2026 and are in the repository's change history, where anyone can read what was wrong and what changed.
9 Jun 2026the pagination fix and backfill job, shipped in one change
The fault and the fix are read from the change history on 13 September 2026.
Consolidated reporting · a medium-market automotive dealer group (three stores, two brands)
Sixteen analytics properties on one store's domain
The question
You asked why three stores' web reports never agreed with each other, or with the ad accounts.
What we measured
A tag inventory of the three stores' sites. One store's single domain carried 16 analytics properties, 14 tag containers and 8 ad-account identifiers. The other two carried 8, 7 and 1, and 7, 8 and 1. Each set had accumulated as vendors added their own tags over the years and nobody removed the last one.
What we built
The inventory itself: a per-store list of every property, container and account identifier firing on each domain, written up as evidence the group could take to its vendors. Clean-up is a proposal in that document; this entry claims the count only.
16 · 14 · 8analytics properties, tag containers and ad-account identifiers on one store's single domain
8 · 7 · 1 / 7 · 8 · 1the same three counts for the other two stores
Read from the analytics audit written for the group, re-read 13 September 2026.
Consolidated reporting · a medium-market automotive dealer group (three stores, two brands)
Two stores up, one down: no group-wide collapse in search clicks
The question
You asked whether your organic search traffic had collapsed, as a vendor claimed, before you changed how you spend.
What we measured
Ninety days of search clicks per store, 24 February to 23 May 2026, against the prior ninety days, 27 November 2025 to 22 February 2026, read from each store's search-console history in the warehouse. Store one: 10,166 against 9,001, up 12.9%. Store two: 8,175 against 6,629, up 23.3%. Store three: 9,664 against 10,147, down 4.8%. The figures did not support a group-wide collapse.
What we built
Each store's search-console history is loaded into the warehouse, so a period comparison is one query that anyone can re-run. Historical search data does not change, and the September re-run matched the May analysis exactly.
+12.9%search clicks, store one, 90 days to 23 May 2026 vs prior 90 days (10,166 vs 9,001)
+23.3%search clicks, store two, same windows (8,175 vs 6,629)
−4.8%search clicks, store three, same windows (9,664 vs 10,147)
Read from the warehouse search-console tables on 13 September 2026, reproducing the May 2026 analysis.
POS intelligence · a 13-location restaurant group across the Mountain West
Same stores, same holiday, three years: $237K, $248K, $247K
The question
You asked whether holiday sales were sliding, or whether the stores being compared had changed from year to year.
What we measured
Father's Day net check totals for the same twelve stores on each year's date: 16 June 2024, $237,137.95; 15 June 2025, $248,483.97; 21 June 2026, $246,941.71. One of the group's thirteen locations is excluded from all three years so the set stays constant, and voided checks are excluded throughout.
What we built
The comparison is one query over the shared POS orders table in the warehouse, filtered to the three business dates and the fixed set of stores. It is a comparison of like with like; we claim no result from it. It tells you what moved before anyone argues about why.
$237K → $248K → $247KFather's Day net check totals, same twelve stores, 2024 → 2025 → 2026 (voided checks excluded)
Read from the warehouse POS orders table on 13 September 2026, matching the June 2026 post-holiday note.
Consolidated reporting · a marketing agency's data and dashboarding platform for entertainment-venue and sports-property paid media
One renderer for every client; sections chosen by configuration
The question
You asked whether every new client means another dashboard to build and another set of numbers to check by hand.
What we measured
A static check of the dashboard application: no client name drives any branch in the code. Sections are registered once, and each client's configuration record chooses which appear and in what order. A source-controlled build note records the pattern carrying ten clients with no per-client code at the time it was written.
What we built
One generic renderer, a section registry, and a per-client configuration document. Adding a client is a configuration record and its tables; no dashboard code is deployed for it. The ten-client figure is a dated note; the current client count was not verified for this entry and is not claimed.
1renderer serving every client; no client-conditional branch in the application code
10clients on the shared code at the time of the source-controlled build note (dated note, not a live count)
Read from the application source and its documented build notes on 13 September 2026.
