Phase 005 is not running the spec. Here’s exactly how.

Forensic findings, 2026-05-16. Several findings are different from the intake-tier gap — 005 is on the cron, but the cron itself is wrong.

Finding 1 — The “monthly” cron expression isn’t monthly.

The single orchestrator crontab entry on the VM is 30 10 * * 1,4 — that fires every Monday and Thursday at 10:30 UTC, NOT once per month. It runs the orchestrator with the monthly/weekly/biweekly tiers together.

Consequence: if 005 is tagged monthly in cadence.py, it fires on every Mon + Thu. That’s ~8-9 fires per month, not 1. At ~$74 per fire (2,247 V_CONFIRMED firms × the cost spec above), the monthly tier alone is bleeding ~$590-665/month instead of ~$74.

(See Monthly cron schedule for the broader cron-vs-spec finding.)

Finding 2 — Input is stale: gold_domains hasn’t been refreshed since Phase 004 last produced rows.

Phase 005 reads gold_domains filtered to final_verdict in {V_CONFIRMED, V_LIKELY}. Phase 004 hasn’t written fresh gold rows since whenever PIPELINE_RUN_ID was last set in a Phase 004 run (see Phase 004 forensic Finding 2). Every Mon + Thu fire of 005 is therefore operating on a frozen firm list, paying ~$3 to re-crawl the same domains.

Finding 3 — 005a is mid-rewrite. Old monolith + half-done replacement coexist.

Per 005_onpage/README.md: as of 2026-05-06 the team is replacing the 1,967-line step_005a_onpage_crawl.py with a four-step decomposition (step1_summary.py → step4_perpage.py). Status:

Two execution paths exist on the VM. Until the rewrite finishes, the monolith is what fires — with all the shared-state bugs the rewrite was meant to fix.

Finding 4 — The silver parsers (005b-g) have never written rows.

Per the April 7 baseline run summary in README.md:

“Empty tables (parsers wired but never wrote): enrichment_005b through enrichment_005g. The bronze JSON payloads ARE preserved; the silver-layer parsing has never successfully run end-to-end.”

The bronze data exists. The parsers exist. They’ve never connected. Today, step_005b_onpage_summary.py contains:

print("step_005b_onpage_summary: endpoint retrieval currently handled by step_005a_onpage_crawl.py")
print("This script will be the standalone entry point after BQ-first refactor.")
sys.exit(0)

Yes, that’s the entire body of 005b. It’s a stub. The other parsers (005c-g) similarly do not actually parse bronze into enrichment_005{b-g} tables in production.

Finding 5 — The fire-and-forget shared-state bugs the rewrite was meant to fix are still in the monolith.

Direct quote from README.md about the monolith:

“Every fix this past month touched shared state, exposed a new bug, repeat. By 2026-05-06 we’d burned 17 days fighting six interlocking bugs (token-bucket miscounts, semaphore stacking, OOM accumulator, --resume CLI mismatch, shared output dirs, /pages-with-non-2xx URLs).”

Many were patched in place. None were structurally eliminated — the architecture that causes them (one file doing seven jobs) is still what runs every Mon + Thu.

Finding 6 — Per-task and global timeouts are generous.

Defaults baked into step_005a_onpage_crawl.py:

An 8-hour global timeout fires every Mon + Thu. If 005 ever starts a real intake-driven run while the cron is also firing the monthly tier, two 8-hour windows could overlap, doubling the DFS load and tripling cost. Today this doesn’t happen because intake never fires — but if Phase 001 Fix 3 lands and the cron-overlap issue isn’t addressed, this becomes live.

The bottom line