MN warehouse audit: 204 of 204 objects accounted for

Plain-language finding

The safe purchase table and the two broader revenue objects can produce very different answers to the same question. In July 2026, the checked VPN total was $162,333. Summing the broader objects without a filter produced $230,346: $68,013 extra, or 41.9% above the clean total.

Where the extra amount comes from

At the frozen snapshot, postgre.mv_user_revenue_actual held 424,882 rows. 126,221 rows—29.7%—had the same start and end date. Those rows still carry an amount. The audit calls them “zero-length” because the recorded interval lasts zero days.

They are strongly linked to normal subscriptions and usually share plan, amount and gateway, but their date rarely matches a billing boundary. The warehouse alone cannot prove what event created them. Calling every row a copied payment would overstate the evidence.

Why Looker is affected

looker.users_revenue reproduces the inflated monthly sums in the periods checked. It does not retain period_to, so the zero-length filter cannot be applied inside that object. It is also not a literal row-for-row mirror; the full audit refuted that stronger claim.

Why the clean source is trusted for this use

claude.vpn_purchases had 294,986 rows at the snapshot, a tested unique purchase_id, no exact duplicate rows and no future purchase dates. Across the All-Hands era checked, its monthly totals matched the broader source after the zero-length filter within $0–$837 per month, at most roughly 1%.

Safe use and remaining limit

• Use claude.vpn_purchases for the checked VPN gross-revenue questions.
• Do not sum either broader object without the tested correction and cross-check.
• Ask MN which source is canonical, what consumes each object and where the producing transformation lives.
• This is a material warehouse trap. It does not prove that MN's checked reports used the wrong number; the All-Hands checkpoints tested followed the clean series.

What was counted

The audit found future-looking values in 40 time fields across 31 objects. Seven high-count tables contain 552,322 table-row occurrences, but the same underlying event may appear in more than one table.

Why the concentration matters

The largest group is 279,183 purchase-session rows associated with 12 pseudonymous analytics IDs, five logged-in users and ten session IDs. Those identifiers are not a count of people or physical devices.

Current assessment

Repeated dates and tight identifier concentration make bad, test, automated or malformed sources plus downstream copying more plausible than hundreds of thousands of independent device clocks. The original producer and intent are still unknown. Current evidence contains no sign of an external attack.

Safe use

Exclude event timestamps beyond the reporting horizon from ordinary trend, cohort and retention work. Keep legitimate entitlement or validity end dates separate until each field's meaning is confirmed.

The five objects

claude.vpn_purchases, looker.users_revenue, postgre.mv_user_revenue_actual, App_usage.App_usage_events and App_usage.App_usage_sessions.

What Kairos needs from MN

For each object: what one row represents; the authoritative key and time field; the intended use; the report or dashboard already trusted; known exclusions; and the person who resolves discrepancies.

The scope limit

Five is the immediate report scope, not a warehouse-wide count. MN may already have these definitions in code, BI documentation or practitioner knowledge that BigQuery does not expose.