PolicyEngine / PolicyEngine/microcosm-dynamics

Integration design: dynamics → Populace panel → full tax-benefit incidence

Open
#100 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1
Forks
1
Avg merge
1h 46m
Merged PRs (30d)
28

Description

Integration design: dynamics → Populace panel → full tax-benefit incidence

The end state (per the program's design and the maintainer's direction): a Social Security reform scored here should report household-level tax-benefit incidence — benefits, taxation of benefits, SNAP/SSI/Medicaid interactions, state taxes, marginal rates — not benefit-side deltas alone. Three workstreams, ordered by dependency:

W1 — Histories onto the Populace panel (the funded build)

Impute gate-certified earnings histories (gate-1-passing generator) and demographic histories (gate-2 transition models, pending that gate's first pass) onto the certified Populace CPS file: CPS↔PSID covariate transport, then calibration against SSA administrative targets (Statistical Supplement award/beneficiary tables, already staged with provenance in this program). Deliverable: Populace gains a longitudinal dimension with per-record benefit-relevant state (AIME/PIA, marital/claiming history). Each stage inherits the pre-registration discipline (transport validation gates before scored use).

W2 — Benefits into policyengine-us (the one-variable seam)

Finding from the survivor-plumbing build (#80): pe-us takes social_security as an uprated survey input — no benefit formula exists upstream. Integration is therefore replacing a survey input with the modeled variable; all downstream incidence (taxation of benefits, program interactions, MTRs) flows through existing policyengine machinery unchanged. Interim product available before W1 completes: dynamics-computed benefit deltas for a reform, fed as inputs to a standard policyengine simulation on the current-year certified Populace file → full current-year tax-benefit incidence of an SS reform. (The taxation-of-benefits work already exercises half this pattern.)

W3 — Axiom as the determinism layer (upstream the auxiliary rules)

The §415 chain here is cross-validated against the Axiom engine 240/240 exact-to-cent. Next: encode 402(b)/(c)/(e)/(f) (spousal, survivor incl. RIB-LIM, the remarriage-at-60 predicate — implemented here and validated against SSA worked examples in #80, but absent from upstream pe-us) as rulespec encodings; cross-validate against this repo's implementation; upstream real formulas to pe-us. Outcome: pe-us gains auxiliary-benefit computation, the encodings gain a validated Title II slice, and this program's statutory layer becomes independently verified per the estimation/determinism split.

Sequencing: W3 and W2-interim are startable now; W1 is the funded build and gates the panel-based projection products. Every scored output continues through the pre-registered evaluation protocol of this repository.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the survivor-plumbing findings in #80 and the taxation-of-benefits work, then trace the W2-interim seam into policyengine-us using the current-year certified Populace file. Done means modeled benefit deltas produce full current-year tax-benefit incidence and remain within this repository's pre-registered evaluation protocol.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.