HEN Data Validation Report — 2026-06-09

Source: HEN Leads Supabase mirror (HubSpot → hen-sync Cloudflare Worker → Postgres). Read-only analysis. Emails masked (abc***@domain), phones masked (last 4 digits only).

Routine periodic re-run, one day after the 2026-06-08 post-sync-fix baseline. The mirror is healthy and incremental — the scheduled cron completed cleanly across three consecutive cycles overnight (00:00, 03:00, 06:00 UTC), all seven entities, 0 errors. Day-over-day figures are stable with small organic growth; the structural fixes from 2026-06-08 (contacts backfill, deals-hang, ISO-date/high-water) all hold. v_stale_rows is steady at 49.

Snapshot taken ~07:17 UTC (12:47 IST); last successful sync 06:00 UTC; next cron 09:00 UTC.

1. Total counts

select 'contacts', count(*) from contacts where deleted_at is null;  -- repeat per table

Growth is small and incremental — exactly what a healthy 3-hourly sync should look like one day on (no backfill spikes, no regressions).

Field population health (contacts)

Population rates are unchanged from yesterday — the contacts table that was empty stubs pre-fix remains fully populated.

2. Sync health — green

All seven entities completed in the 06:00 UTC run with 0 errors:

v_stale_rows = 49 (unchanged). High-water marks advance per entity, so the small per-run record counts (24–70) confirm the sync is genuinely incremental, not re-scanning. Three clean cron cycles were observed overnight (00:00 / 03:00 / 06:00 UTC) with no human present — the scheduler runs entirely on Cloudflare's edge.

select * from last_successful_sync order by entity_type;
select count(*) from v_stale_rows;          -- 49

Minor observation: the segments sync still processes all 2,858 rows every run (its high-water mark advances to "now" each time, so it full-scans). Harmless at this volume, but a candidate for the same incremental treatment as the other entities if segment counts grow.

3. Dedupe summary (v_dup_summary)

select * from v_dup_summary order by excess_rows desc;

Numbers crept up by single digits vs. yesterday (companies-by-name excess 3,752 → 3,759) — normal as new records land. Contacts-by-email remains 0: HubSpot enforces unique contact emails, so email is a clean merge key. The company-name backlog (3,759 excess) is the dominant cleanup item; domain matching stays noisy (shared registrar/association mailboxes → false positives), so prefer name/phone for companies.

4. Data quality flags

All flags are flat or moved by single digits vs. 2026-06-08 — no new data-quality regressions.

5. Drilldowns (top 5–6)

5.1 Top closed-won deals by revenue

The two Ontario/Bauer rows at 121,280 are confirmed to share the same company_id, amount, and close date — a duplicate deal (Bauer Compressors is the partner on the Ontario FD order). Surfaced by v_dup_deals; see Action 9.

5.2 Top existing customers by revenue (resellers excluded — business rule 2)

Why the reseller filter matters: an unfiltered "top accounts by revenue" is dominated by distributors, not end customers — Dinges Fire Supply alone shows $1,170,602 across 666 won deals, then L.N. Curtis & Sons ($534,563), Atlantic Emergency Solutions ($407,320). Per business rule 2 (customer_vertical IN ('US_Reseller','International_Reseller')) these are excluded from existing-customer analysis. The table above is the true end-customer ranking and matches the prior report.

5.3 Closed-won with no line items (top by amount)

$375k of the top closed-won revenue (the two HEN Foundation deals) has no itemized line items — revenue is booked at the deal level only, so product-line attribution misses it.

5.4 Contact duplicates by name+company

5.5 Top company-name duplicate clusters (merge backlog)

Most are legitimate fire departments entered with case/spelling variants (real merge candidates). "Self-Employed" ×12 is junk-label noise and should be scrubbed rather than merged.

6. Masking applied

• Emails: abc***@domain (none shown in the body above; drilldowns use names/company only).
• Phones: last 4 digits only (none shown).
• DATABASE_URL / credentials never printed.

7. Prioritized action list

P0 — RESOLVED ✅ (from 2026-06-08, holding)

1. ✅ Contacts skeleton — fixed & backfilled; remains fully populated (96.5% email).
2. ✅ Deals sync hang — fixed; deals complete cleanly every run.
3. ✅ ISO-date / frozen high-water — fixed; incremental sync confirmed across multiple cron cycles.

P1 — still open (Worker-side mappings, unchanged)

1. Managing Distributor association not synced — deals.managing_distributor_company_id is null for all deals, so v_distributor_companies = 0. Add the labeled association to the deals sync. (Note: §5.2 shows distributors *do* carry large revenue — Dinges $1.17M — so this association is high-value for distributor analysis.)
2. Owner identity — owners rows still have null names/emails, so v_unknown_owners reads a misleading 0 and business rule 6 (Jacob McAfee → Joe Schuller; Curt Johnson RSD null) can't run.
3. Lead stage labels — raw *-stage-id values still leak unmapped; 863 leads have null lead_type (was ~877).

P2 — data cleanup (on the complete mirror)

1. Merge company name duplicates (3,759 excess — top: LA Fire ×18, Orange County ×16) and contact name+company duplicates (455 excess); scrub the "Self-Employed" ×12 junk label.
2. Resolve 850 deals without a company, 183 closed-won with no line items ($375k unattributed at the top), 106 orphan line items.
3. De-duplicate the Ontario/Bauer 121,280 deal (§5.1) — confirmed same company/amount/close.

P3 — optimization (new, minor)

1. Make the segments sync incremental — it currently full-scans all 2,858 rows each run (harmless now, see §2).

*Routine re-run 2026-06-09 (~07:17 UTC). All figures reflect the live mirror; last sync 06:00 UTC, sync healthy and incremental.*