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
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 theirs_soi.form_w2_social_security_tipsfamily — whichtarget_parity_manifest.jsoncorrectly holds as areviewed_exclusion(structural-zerotip_incomeuntil 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) onus_target_family_idrather 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