Skip to content

Proposal: preserve missing-input state instead of collapsing it to zero #513

Description

@edithatogo

I have been testing SNAP-style screener flows in policyengine-us, and I found that omitted monetary inputs behave the same as explicit zeros at the engine boundary.

Concrete examples (Texas SNAP household)

  • No employment_income / self_employment_income provided:
    • snap_gross_income = 0.0
    • snap_net_income = 0.0
    • snap = 291.0
  • No child_support_expense provided:
    • snap_child_support_deduction = 0.0
  • No housing_cost provided:
    • snap_excess_shelter_expense_deduction = 0.0

That is convenient for fully specified simulations, but it makes it impossible to tell the difference between:

  1. The user intentionally entered zero, and
  2. The user did not provide the field at all.

For screener-style and partially completed scenarios, that distinction matters. A missing income field should usually be represented as unknown or incomplete, not silently coerced to zero.

Questions for maintainers

Would any of these approaches be idiomatic?

  • A preserved missingness state on input holders
  • An explicit valueState-like annotation for inputs
  • A documented partial-input mode that propagates "cannot determine" rather than defaulting to zero

I am not proposing an engine-wide rewrite. I am asking whether there is an accepted way to distinguish missing from zero today. If not, I would be glad to follow up with a narrow proposal.

Runtime used for the cases: policyengine-core==3.28.0, policyengine-us==1.755.5.

Evidence packet (external): https://github.com/edithatogo/rulesandprocesses/blob/main/external/policyengine/MISSINGNESS_CASES.md

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions