Phase 007 is mostly working — here’s what’s drifting.

Forensic findings, 2026-05-16. This is the first phase that’s actually firing on schedule. Findings are about edges, not wholesale failure.

Finding 1 — 007 IS firing on the cron successfully (good news, finally).

Direct BQ query of enrichment_007a_gbp_info for atty_wa_seattle as of 2026-05-16:

007a, 007b, 007c all show the same 4 runs with identical CID coverage. This is the first phase I’ve documented where the cron actually produces fresh data weekly. Phases 005 and 006 are stuck on their April backfills; Phase 007 has three subsequent cron-driven fires after it.

Finding 2 — The 2026-05-04 Monday fire is missing.

Look at the timestamps: 2026-04-21 → 2026-04-28 → 2026-05-11. That’s 7 days → 13 days. The expected 2026-05-04 fire didn’t happen.

Possible causes (unverified):

• VM was down or rebooted during the May 4 cron window
• The orchestrator hit an error and didn’t retry
• DFS was experiencing API issues that morning
• Memorial-Day-adjacent or other operator action

amicus_logs.pipeline_runs filtered to profile_id='atty_wa_seattle' and the date range 2026-05-03 to 2026-05-05 would show whether a run was attempted at all. Not yet checked.

Finding 3 — CID count drift: 2,968 backfill → 2,772 ongoing.

The 2026-04-20 backfill processed 2,968 CIDs. Every cron fire since has processed 2,772 — 196 CIDs disappeared between the backfill and the first cron fire on 2026-04-21.

Most likely explanation: gold_cids was rebuilt between those dates (e.g. by a Phase 003+004 re-run that produced fewer ATTORNEY_CONFIRMED CIDs). The cron now operates on whatever the current gold_cids table holds.

Confirmation query (not yet run): SELECT COUNT(*) FROM gold_cids WHERE profile_id='atty_wa_seattle' AND final_verdict='ATTORNEY_CONFIRMED' — today that returns 2,742, which is close to 2,772 but not identical, suggesting one more small rebuild happened recently.

Finding 4 — Reviews are stored as one BQ row per CID per run, with reviews nested in JSON.

enrichment_007b_gbp_reviews.review_rows for the latest run = 2,772 = unique_cids. That means the BQ table has one row per CID, not one row per review. The actual review text is presumably nested inside a JSON field on that row.

Implication for downstream analytics:

• Counting reviews requires unnesting the JSON field with SELECT JSON_EXTRACT_ARRAY(...) or similar.
• Comparing across runs (“new reviews this week”) requires diffing two JSON blobs, which is awkward.
• A flatter schema (one row per (cid, review_id)) would make analytics easier but would explode row count (2,772 firms × avg 50 reviews = 138K rows per run).

This is a design choice, not a bug — just call it out so a future analyst knows where to look.

Finding 5 — Operating on a stale gold list.

Same root cause as every other downstream phase. gold_cids hasn’t been refreshed since Phase 004 last produced rows (see Phase 004 forensic Finding 2). Firms that opened or closed since mid-April are invisible to the weekly GBP scrape. New CIDs added to a firm aren’t tracked.

Finding 6 — If a firm has 10 CIDs (multi-location), Phase 007 fetches 10 times.

Phase 007 explicitly does not dedupe by domain. It processes every CID in the gold table. A large firm with 10 offices = 10 separate GBP API calls. That’s correct behavior (each office has its own listing, reviews, posts) but it does mean cost scales with CIDs not unique firms.

For atty_wa_seattle today: 2,742 CIDs / 2,223 unique domains = 1.23 CIDs per firm on average. Not a big amplifier — but for a firm with 5+ offices in the dataset, Phase 007 is the only phase that bills 5x. (Phases 005 and 006 dedupe to one call per primary domain.)

The bottom line