Enhanced CPS build fails Stage-1: tips too low ($30.9B<$40B), JCT tax-expenditure >50% rel err, liquid assets too high ($72.5T>$70T) — NOT clone weight

[MaxGhenis]

Summary

The Enhanced CPS publication build fails Stage-1 validation at validation/stage_1/test_enhanced_cps.py::test_ecps_puf_clone_diagnostics_reasonable — the PUF-clone household weight share on the built artifact is below the 5% floor. This blocks producing any clean post-clone-fix eCPS.

Observed (not inferred)

• Modal pipeline get_pipeline_status for app us-data-1-115-5-patch-usdata-gha26670272533-a1 (GHA run 26670280120, SHA f7458313 = main with clone fixes Fix PUF clone prior weights #1140/Add household count target to ECPS calibration #1149/Fix Enhanced CPS PUF clone calibration guards #1150/Keep PUF clone priors as support weights #1151 all present): status=failed, Pipeline failed in 1_build_datasets: Validation failed: validation/stage_1/test_enhanced_cps.py::test_ecps_puf_clone_diagnostics_reasonable.
• The public + all staged eCPS artifacts show clone household weight share ≈ 0% (1.99e-5%).

The calibration MATH is NOT the cause (ruled out by local reproduction)

A faithful local repro of reweight() + initialize_weight_priors from enhanced_cps.py (real utils deps: get_target_loss_weights, get_target_error_normalisation, etc.), on synthetic problems matching build_loss_matrix's clone-count target construction:

• clones enter at the 0.05 prior and the optimizer drives them to 22–50% (well above the 5% floor) across baseline / many-target / clone-heavy cases.
• Teeth check: monkeypatching out the clone-count up-weight collapses clones to 0.65% — confirming the existing HOUSEHOLD_COUNT_LOSS_WEIGHT = 100_000 clone-count target is exactly what holds clones up, and it IS applied.
• Note: reweight()'s l0_lambda defaults to 0.0 and EnhancedCPS.generate does not set it, so the L0 HardConcrete penalty is off — "L0 gates prune clones" is not the mechanism.

So the optimizer, the prior, the floor guard, and the clone-count target weighting are all correct on f7458313.

Most likely real cause (data plumbing — needs maintainer confirmation)

The realized clone share is ~0% on the actual build despite correct math ⇒ the clone-count target is probably a no-op at build time because household_is_puf_clone is missing/empty on the built ExtendedCPS_2024_Half artifact → _load_household_is_puf_clone(dataset, period) returns None (precondition at utils/loss.py:1255) → _add_household_count_target skips the CPS/clone split → nothing rewards clone weight → clones collapse → the Stage-1 test fails.

Suggested check (cheapest first)

1. On the failed build's inputs, inspect whether ExtendedCPS_2024_Half actually carries a non-null household_is_puf_clone keyed by period 2024. If absent/empty, the clone-count target is silently skipped — that's the bug.
2. If present, pull the full Stage-1 traceback (the realized clone-share value) from the Modal container logs to confirm whether it's ~0% (skipped target) vs a smaller miss.

Evidence files (upstream/main)

• policyengine_us_data/datasets/cps/enhanced_cps.py (reweight ~673-790, initialize_weight_priors ~59, generate clone path ~805-879, floor ~55/166-172)
• policyengine_us_data/utils/loss.py (_load_household_is_puf_clone ~1208-1229, _add_household_count_target ~1255-1275, HOUSEHOLD_COUNT_LOSS_WEIGHT ~89-90, weights ~1306-1314)
• validation/stage_1/test_enhanced_cps.py::test_ecps_puf_clone_diagnostics_reasonable (~72)

Context: surfaced while trying to obtain a clean post-clone-fix eCPS baseline to benchmark microplex-us against. A speculative calibration fix was deliberately NOT shipped because the local repro refuted that hypothesis — flagging the data-plumbing lead instead so no one re-chases the optimizer.

[MaxGhenis]

⚠️ Correction — this issue's diagnosis was WRONG; retitling/rescoping

I filed this from get_pipeline_status summary text + inference. I have now read the full Stage-1 pytest output from the Modal logs (app us-data-1-115-5-patch-usdata-gha26670272533-a1, SHA f7458313), and the clone-diagnostics theory is refuted:

===== 5 failed, 65 passed, 7 skipped in 4297.20s =====
FAILED validation/stage_1/test_enhanced_cps.py::test_ecps_has_tips
  AssertionError: assert 30872167281.37 > 40000000000.0   (tips $30.9B < $40B floor)
FAILED validation/stage_1/test_enhanced_cps.py::test_ecps_replicates_jct_tax_expenditures
  AssertionError: JCT tax expenditure diagnostics exceeded 50% relative absolute error
FAILED validation/stage_1/test_sipp_assets.py::test_ecps_has_liquid_assets
  AssertionError: Total liquid assets $72.5T above maximum $70.0T (SCF source total $35.0T)
FAILED validation/stage_1/test_sparse_enhanced_cps.py::test_sparse_ecps_has_tips        (mirror of #1)
FAILED validation/stage_1/test_sparse_enhanced_cps.py::test_sparse_ecps_replicates_jct_tax_expenditures  (mirror of #2)

test_ecps_puf_clone_diagnostics_reasonable PASSED. The clone weight share is fine — consistent with a local reproduction of reweight()+initialize_weight_priors where clones reach 22–50% (well above the 5% floor), and with the fact that l0_lambda defaults to 0.0 (no L0 pruning). So the clone-weight-collapse hypothesis in the original issue body is incorrect and should be disregarded.

Actual Stage-1 blockers (3 distinct)

1. Tips too low — test_ecps_has_tips: total tip income $30.9B vs required > $40B.
2. JCT tax-expenditure replication — test_ecps_replicates_jct_tax_expenditures: ≥1 expenditure exceeds 50% relative absolute error.
3. Liquid assets too high — test_ecps_has_liquid_assets: $72.5T vs max $70T (SCF source $35T).

(The two sparse_* failures are the sparse-build mirrors of #1 and #2 — same root causes.)

These look like target/threshold or imputation-magnitude issues (tip income, SIPP/SCF asset scaling, JCT expenditure targets), unrelated to PUF clones. Retitling accordingly. Apologies for the noise on the original (clone) framing — that was an inference error, now corrected against the real logs.

Full error artifact ref: runs/usdata-gha26670272533-a1/errors/20260530T062809393244Z-1_build_datasets.json.