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

Forensic findings, 2026-05-16. Same intake-tier gap as 001/002, plus a couple of 003-specific issues.

Finding 1 — All four 003 steps are tagged intake. None auto-fire.

pipeline/steps/cadence.py tags 003a, 003b, 003c, and 003d as intake. The intake tier has runs_on: [] — never auto-fires. Same root-cause gap as the rest of intake.

Finding 2 — 003c is where the 2026-04-06 cascade burned real money.

The manual fire on 2026-04-06 made it as far as 003c before someone killed it. pipeline_runs shows failed_step=003c on multiple runs that day, and api_cost_log shows Anthropic spend that hour clustered on 003c retries.

Root cause: 3-pass classifier with no per-domain failure budget. If a Pass 1 call fails (network blip, rate limit), it returns "ERROR" as the verdict, which is not in {V_CONFIRMED}, so the record escalates to Pass 2. Pass 2 also fails, escalates to Pass 3 (Sonnet, 5x cost). Sonnet returns "ERROR", which becomes the final_verdict. A single transient failure costs Pass 1 + Pass 2 + Pass 3 instead of just Pass 1.

When that fails for many domains at once (e.g. an Anthropic-side hiccup), you escalate the entire batch to Sonnet and burn 5x the budget for zero useful classifications.

Finding 3 — 003d writes only to disk. The gold_domains BQ table is written by Phase 004b, not Phase 003.

The pipeline overview page’s older cards described 003d as “promote to gold_domains.” That language is misleading. The actual step_003d_join_gold.py writes only to 11_gold.json on disk. It has no BQ writer import.

The amicus_pipeline.gold_domains table does get populated — but by step_004b_join_gold.py at the very end of Phase 004, not by Phase 003. (See Phase 004 for the actual write path: gold_domains + gold_cids + gold_paid are split out and written in one place at the close of intake.)

Practical implication for Phase 003: 003 has no BQ deliverable on its own. 003c writes enrichment_003c_classification, 003d only writes 11_gold.json. If 004 never runs, the verdicts are stuck on the VM disk with no BQ-side reflection.

Finding 4 — enrichment_003c_classification BQ write is gated on PIPELINE_RUN_ID.

Same gotcha as Phase 002. step_003c_haiku_classify.py at line 922 only writes to BigQuery if PIPELINE_RUN_ID is set in the environment:

if run_id and all_records:
    ...
elif not run_id:
    print("BQ write skipped: no PIPELINE_RUN_ID (standalone mode)")

Manual SSH fires almost never set this variable. So every manual 003c run since the orchestrator broke has silently skipped its BQ write — the data lives only on the VM disk as 10_haiku_classified.json.

Finding 5 — Input dependencies are files, not BQ tables.

003a reads 08_domain_verified.json. 003b reads tags_only/ and events.jsonl. 003c reads 09_categorized.json + tags_only/ + (optionally) 09b_playwright_results.json. 003d reads four different JSON files.

That means Phase 003 cannot be re-run independently of Phase 002’s on-disk output. If the VM disk gets wiped, or the output dir gets cleared, the entire intake cascade must rerun from 001 — even if BQ tables are fully populated. There is no “rerun classification from BQ” path.

Finding 6 — LLLT pre-classification only catches LLLT in the title.

The check_lllt() function (line 363 of step_003c_haiku_classify.py) deliberately checks only gmap_title and page_title — not body copy. That decision is documented (law firms may employ LLLTs without being LLLT-only practices), but it means LLLT-only practices that don’t put LLLT in their business name slip through to Haiku, which then has to figure it out from context. Haiku usually gets it right, but it’s a known leak.

The bottom line