Year-keyed support exclusions don't fence other vintages: ty2020 W-2 tips facts compiled the excluded tips family

Found during the Build K staging run (2026-07-13). Fail-closed catch #2 of 3.

What happened

A regenerated feed carrying irs_soi.ty2020.form_w2_social_security_tips.* rows (from the w2_statistics_2020 package) compiled the irs_soi.form_w2_social_security_tips family — which target_parity_manifest.json correctly holds as a reviewed_exclusion (structural-zero tip_income until the tip-imputation source stage is ported; us-data #220 fence). The parity assertion caught it (the manifest marks family(ies) a reviewed exclusion the registry now compiles).

The root cause: the operative support exclusion is keyed by full record id including vintage (irs_soi.ty2023.form_w2_social_security_tips.box_7_social_security_tips.return_count), so same-family facts at any other year walk straight past it.

Why it matters

The exclusion's intent is family-level ("the model cannot satisfy this target"), but its enforcement is vintage-level. Any feed regeneration or ledger package addition that shifts a fact's year silently re-arms an excluded target; the parity gate catches it today, but with a "promote to compiled" message that is the wrong remedy for this class.

Fix used

Dropped the family's rows from the staging feed.

Proposal

Match US_FISCAL_TARGET_SUPPORT_EXCLUSIONS (and the parity manifest's reviewed exclusions) on us_target_family_id rather than the full record id, or add a family-level exclusion tier — so a fence on "the model can't do tips yet" fences tips at every vintage.

🤖 Generated with Claude Code

Trace US_FISCAL_TARGET_SUPPORT_EXCLUSIONS and the reviewed exclusions in target_parity_manifest.json, starting from the parity assertion and the staging-feed filtering path. Confirm how us_target_family_id is available for the affected records. Done means exclusions fence the family across vintages and the parity assertion no longer reports the excluded family as newly compiled.