Kairos — Database Integrity and Fraud-Risk Assessment (2026-08-11)

[!confidential] Private Kairos working analysis. It contains a calibrated fraud-risk branch, not an allegation. Do not copy the personnel-risk interpretation to shared or MN-facing surfaces without Lee's explicit approval and independent evidence.

Scope and evidence state

This note preserves the complete analytical result of the Claude session “MN database direct access” and Codex's same-day continuation. Claude established the direct warehouse connection, mapped the available data, found and corrected a revenue-table duplication, and reached the beginning of the duplication timeline before its session limit. Codex then independently reproduced the timeline, verified the relevant row fingerprints, established the Stripe table's grain, and separated a defensible retry-policy defect candidate from the naive “75% failure” headline.

All database work described here used read-only aggregate queries. No raw customer rows, credentials, passwords, one-time codes, card fingerprints, or customer identifiers were copied into the vault or Kairos repository.

Evidence labels:

• Fact: directly reproduced from the current warehouse snapshot.
• Working: corroborated by at least one second in-warehouse source but not externally reconciled.
• Citable: externally verified against a processor, finance statement, bank settlement, or source owner. Nothing in this note is citable yet.
• Hypothesis: a live explanation or risk branch with an explicit kill test.

Direct-access contract

The warehouse project is mysterium-bq. The authenticated principal is sarunas@mysterium.network, with BigQuery Data Viewer and BigQuery Job User. Access runs through the machine's existing local gcloud authentication and the bq CLI. Claude and Codex can use the same connection; it is not Claude-exclusive. Query cost and audit attribution remain attached to that principal/project. No reusable secret or service-account key was present in the session or added to the vault.

The project exposes 24 datasets. The postgre dataset is a same-day Airbyte replica containing the core VPN subscription, revenue, payment, Stripe, churn, traffic and support surfaces. Proxy revenue is not present in the warehouse; proxy-related tables cover users, mappings and support rather than revenue.

Revenue duplication: reproduced facts

postgre.mv_user_revenue_actual contains 420,773 rows. Of these, 125,095 have period_from = period_to; the other 295,678 are normal-duration rows. The zero-length rows mechanically duplicate normal payment rows across gateways and materially inflate naive revenue sums.

For July 2026, using the documented revenue population (New, Recurring, New/History, Winback):

Across all revenue types, including refunded and NULL rows, July contains 4,420 zero-length rows and $71,232.83 of phantom amount. The earlier shorthand “$71k phantom revenue” was therefore population-ambiguous. Use $68.0k when discussing the documented gross-revenue population and $71.2k only when explicitly discussing all row types.

The clean July result is working, not citable:

• claude.vpn_purchases, a curated purchase-grain table, totals $162,333 for July and matches the clean result to the dollar.
• looker.users_revenue, the BI-layer feed, totals $230,346 with the same 14,668 all-type row count as the duplicate-carrying table. The BI feed therefore contains the inflation. We cannot see every dashboard query, so “executives see inflated revenue” remains a hypothesis.
• The Stripe charge mirror reports $68.6k of July succeeded charges, close to the clean revenue table's $64.7k Stripe slice and materially below the duplicate-carrying $88.0k slice.
• MN's all-hands deck reports $288k total July revenue. The warehouse has no proxy-revenue table, so the remaining perimeter cannot be assigned from BigQuery. Arithmetic fits such as $230k + $58k or $162k + $126k are not evidence.

Duplication timeline and provenance limit

Zero-length rows exist in April and May 2023, but those rows carry $0. The first non-zero observable month is June 2023, when phantom rows carry 12.9% of the documented gross population. The share is 6.5% in July, 10.3% in August, 23.2% in September and 25.4% in October. It persists at 21.0–28.0% through 2024, 24.3–28.8% through 2025, and 25.8–31.4% from January through July 2026. There is no clean observable era in this table.

The exact start date is unknown. The warehouse horizon begins after the generating mechanism was already present. Every one of the 125,095 zero-length rows has blank created_at; 182,094 of 295,678 normal rows also have blank created_at (61.6%). This fingerprint narrows the generating path but does not prove cause or intent.

Airbyte metadata cannot date the original writes. Every row in both classes was re-extracted once at 2026-08-11 12:34:51 UTC, with one generation and one extraction date. Root cause requires the source SQL, scheduled-query/model history, or the table owner. Dashboard exposure requires the consuming Looker/dashboard queries.

Stripe retry grain: first defensible engineering lead

postgre.mv_claude_stripe_charges has 207,979 rows, 207,979 distinct Stripe charge IDs and 207,979 distinct Airbyte raw IDs. One row is one unique charge attempt. A second table, postgre.vpn_stripe_adyen_charges, matches all 15,261 July Stripe charge IDs and statuses exactly. That corroborates extraction and grain, but it is probably the same upstream Stripe source rather than an independent external reconciliation.

July contains 11,391 failed attempts ($263,665.62 attempted) and 3,870 succeeded charges ($68,606.88). The headline is real at attempt grain but false as a loss estimate:

• 658 failed attempts have no invoice ID.
• The remaining 10,733 failed attempts collapse to 3,694 affected invoices: 2.91 failed attempts per affected invoice on average, with a maximum of 10.
• At true first-failure cohort grain, 3,285 invoices first failed in July. By the warehouse cutoff (2026-08-11 09:14:31 UTC), 280 later succeeded (8.5%) and 3,005 had not. Counting one amount per invoice, unrecovered exposure was $79,733.29, not the $263.7k sum of repeated attempts.

Same-day correction: the pooled $79.7k figure above is superseded and must not be cited. A later independently written cohort query split initial checkouts from recurring renewals and reconciled back to the same 3,285 first failures. The defensible recurring slice is 2,979 renewal invoices, 1,528 first-attempt failures (51.3%; 50.7% after excluding 17 intentional Radar blocks), 275 later recoveries (18.0%) and $19,177 still unpaid at cutoff. Initial-checkout failures account for $60,441 of the pooled figure and behave like abandoned acquisition, not recoverable renewal exposure.

The published “75% failure” is attempt-grain: 157,880 failed attempts divided by 208,104 total attempts over the charge log's full life (75.9%; 74.6% in July). It answers the wrong question because retries multiply the numerator. The 51.3% renewal-invoice rate is the correct July value for the War Room metric definition. It remains working-tier, Stripe-only evidence rather than an MN-facing opportunity estimate.

The surviving opportunity is a hypothesis, not a financial claim: roughly $19.2k of July renewal invoice face value remained unpaid at cutoff. Before treating any part of it as involuntary-churn recovery, strip subscriptions cancelled before the renewal attempt and confirm the cohort against Stripe's external dashboard. The correction is canonical in ~/Claude/Projects/Kairos/CONTEXT/2026-08-11-db-blindspot-map.md section G.

The narrow engineering lead is the processor reason previously_declined_do_not_retry. Across warehouse history, 1,280 invoices have it as their first failure reason. The system later retried 672 of them, generating 4,414 additional failed attempts; only 12 invoices ever succeeded (0.9%). In the July first-failure cohort, 78 invoices began with that reason, 67 were retried 478 more times, none recovered by cutoff, and $1,355.47 remained exposed. This supports a billing-owner test of the retry policy. It does not support presenting “Stripe failures are high” as an MN insight or claiming revenue lift.

The 658 July failed charges without invoice IDs remain outside the invoice analysis. All also lack both subscription identifiers and user_id; 558 lack customer, and 39 lack card fingerprint. Fingerprint plus amount could produce a provisional retry-session model, but card reuse can collide. It is not yet a defensible transaction key.

Insider-fraud assessment

Current calibrated judgment

The warehouse anomaly is a serious data-governance failure with a legitimate fraud-risk branch. It is not evidence that an insider committed fraud. The current subjective priors are:

• Accidental pipeline, SQL or BI-modelling defect: 85–95%.
• Defect known but tolerated, ignored or selectively exploited: 5–15%.
• Deliberate insider fraud responsible for creating the duplicate mechanism: 1–5%.

These bands are judgmental priors, not a statistical result, and the latter two can overlap. A broken feed may begin accidentally and later be knowingly exploited.

Why engineering failure is more likely

The duplication affects all gateways and scales broadly with legitimate volume. It does not visibly cluster around quarter-end, round-number adjustments or a particular reporting threshold. Its mechanical signature resembles a second branch in a query or model: identical economic events represented again as zero-length periods with uniformly blank created_at.

The same warehouse retains a clean curated purchase-grain table alongside the inflated BI feed. That is weak control, but not effective concealment. The anomaly creates inflated analytical revenue; current evidence does not show diverted cash, invented processor receipts, altered bank settlements, personal benefit or misappropriated assets.

Why a quiet audit is still warranted

The defect is material and persistent. It reaches roughly one quarter to one third of the affected gross measure and survives for the full observable history. The BI feed carries the inflated number exactly. If someone knew the feed was wrong, continued using it in management, board, investor, bonus, covenant or fundraising reporting, and concealed the clean comparator, the evidence would shift from error toward intentional financial misrepresentation.

The decisive boundary is intent. The PCAOB's fraud standard distinguishes fraud from error principally by whether the underlying action is intentional, and it warns that intent is often difficult to determine: https://pcaobus.org/oversight/standards/auditing-standards/details/AS2401

Do not ask “who did it?” yet. Ask two mechanical questions: what query created these rows, and which surfaces consumed them?

Quiet audit plan

1. Preserve the current table schema, aggregate fingerprints, query outputs and timestamps without exporting customer-level data.
2. Obtain the source SQL, scheduled-query or model definition, Git/change history, BigQuery job/audit history and named technical owner for mv_user_revenue_actual and looker.users_revenue.
3. Trace every dashboard, deck and KPI that consumes the duplicate-carrying feed. Record its exact query and whether it filters zero-length rows.
4. Reconcile the dashboard and deck figures with Stripe, other processor dashboards, finance statements and bank settlements. This is the external gate from working to citable.
5. Search tickets, messages, metric dictionaries and prior analyses for evidence that the discrepancy was previously known, reported, dismissed, corrected or suppressed.
6. Only if knowledge and continued misleading use are established, inspect incentive links such as bonuses, fundraising, covenants, earn-outs or continuation targets.
7. Keep language neutral until evidence crosses the boundary: “data-integrity anomaly,” “duplicate-carrying BI feed,” and “intent unknown.” Do not name a person or use “fraud” as a conclusion.

Recommended operating response (captured after Lee's 2026-08-11 question)

This is the governance response to the anomaly, not the highest-leverage use of the database for the September sprint. Keep the two lanes separate.

First build a compact evidence packet containing the clean and duplicate-carrying July figures, the exclusion rule, cross-source reconciliation, timeline, row fingerprint, evidence labels, query-output timestamps and hashes. Preserve that snapshot before anyone changes a model or dashboard.

Then bring only Šaras and the actual data-model owner into a private technical reconciliation. Ask for the source SQL, intended zero-length-row semantics, model/change history, consumers and dashboard filters. Open factually: “We found zero-length revenue rows that change July VPN gross from $162.3k to $230.3k. The curated purchase table supports $162.3k. Before interpreting this, we need the model lineage and consuming queries.” Do not mention the 1–5% fraud prior externally.

Reconcile the affected surfaces against processor dashboards, finance statements and bank settlements. Establish prior knowledge only after lineage: whether the discrepancy was reported, whether a correction was available, and whether any consuming report knowingly remained on the inflated feed.

Escalation is evidence-gated:

• ordinary SQL defect with correctly filtered consumers → close the fraud branch and install reconciliation tests;
• unknown defect that reached reporting → repair, back-correct and add controls;
• known inflation used after correction was available → preserve evidence and escalate privately through the appropriate finance/governance authority;
• evidence of concealment, personal benefit or intentional misstatement → stop informal questioning and use independent audit/legal counsel.

The narrow previously_declined_do_not_retry billing finding stays separate. It is an engineering candidate, not evidence about revenue-reporting intent.

Kill tests and escalation triggers

The fraud branch weakens further if source lineage shows an ordinary union/join defect, the consuming dashboards filter the rows, reported finance figures reconcile to processors, and there is no evidence anyone knew of the discrepancy.

The branch strengthens materially if audit history shows deliberate creation or preservation of the duplicate mechanism, consuming reports knowingly used the inflated feed after correction was available, clean comparators were hidden, reconciliations were overridden, or personal/organizational incentives were explicitly tied to the inflated measure.

No personnel allegation, external communication, dashboard correction, production query change, or MN disclosure is authorized by this note. Lee retains that authority.

Cancellation timing: a structural limit, not a gap to query around

Added 2026-08-12, from schema inspection rather than analysis. The warehouse cannot cleanly say when a customer cancelled, which constrains every voluntary-versus-involuntary churn question including the renewal-leak gate.

mv_vpn_cancel_reasons holds the reason (type · reason · comment · gateway · user_id · subscription_id) and no cancellation timestamp. Its only time column is _airbyte_extracted_at — when Airbyte replicated the row, not when the customer left. A join treating that as the cancellation time returns a clean, plausible, entirely wrong ordering and raises no error. mv_vpn_users_churn carries churn_date, but at DATE grain, so a cancellation and a charge attempt on the same date are genuinely unorderable.

There is no subscription_events table in postgre; a bq ls sweep for subscription|cancel|churn returned only the two tables above. If a timestamped cancellation source exists elsewhere in MN, finding it is worth more than any query written against these two — and it is a fair Thursday ask of the payments owner.

Method and pre-registered stop rules for the test this constrains: ~/Claude/Projects/Kairos/CONTEXT/2026-08-11-voluntary-cancellation-test-preregistration.md (commit 773d50b).

Provenance

• Claude session: “MN database direct access”, 2026-08-11.
• Direct read-only BigQuery continuation by Codex, 2026-08-11.
• Shared analytical precursor: ~/Claude/Projects/Kairos/CONTEXT/2026-08-11-db-blindspot-map.md.
• Related vault synthesis: Kairos — Opportunity Hypotheses (2026-08-11), Kairos — Mysterium All-Hands Analysis (2026-08-07), VPN business-health benchmarks — 2026-08-11, questions-to-excavate.