Skip to content

PUF stage manifest declares a support_clip op that no execution path honors (dead donor_realized contract) #482

Description

@MaxGhenis

Found during the #462 fix-3b diagnostic. The PUF stage manifest declares

{"kind": "support_clip", "range": "donor_realized"}

(source_stages.json:111-114) but the declaration is dead twice over:

  1. Bypassed: the production builder reads the PUF HDF5 and calls the QRF chain directly (build_us_puf_support_base.py:981-989, :1811-1829); nothing routes this stage's ops through the generic runtime.
  2. Mis-shaped: the generic support_clip handler accepts output + numeric lower/upper and does not implement "range": "donor_realized" (us_runtime/source_runtime.py:1050-1083) — so even a routed invocation would fail.

Also: even as intended, a donor-realized min/max clip would not have prevented the #462 tail defect ($594,483.64 is an observed donor value, well under the $5.96M donor max).

Same disease class as the never-invoked capital_gain_distributions stage fixed in #480: a declared operation that no execution path honors. Options: implement donor_realized in the handler AND route the stage through it, or delete the declaration and let the #462 per-target weighted-quantile bound (which subsumes the useful part of the intent, with real tail semantics) be the recorded contract. Either way the manifest must stop declaring machinery that never runs — a spec-validation guard of the #477 no-hardcoded-counts kind would prevent the class recurring.

Relates #462, #480.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions