PolicyEngine / PolicyEngine/microcosm
reform_validation_payload: embed executable reform dicts + publisher slugs for scorecard claim identity
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 4
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 94
Description
The reform-validation registry is being consolidated into policyengine-scorecard (PolicyEngine/policyengine-scorecard#15, adapter in #16); calibration-diagnostics' External checks tab retires (calibration-diagnostics#140). The registry and producer stay here — release-exact scoring at each build's engine pins is engine-adjacent work — but the artifact becomes a scorecard input, which exposes two gaps in reform_validation.json:
-
No executable reform dicts. Scorecard claims key off a
ReformRef; with only a rowidavailable, scored rows usepolicy_refdescriptors ({"policy": "ks_hb2620_eitc"}). The param dicts already exist instate_reforms.json— emitting each row'sreform_params(and non-current-law baseline where applicable, e.g. the OBBBA suite's TCJA-expiration counterfactual) upgrades claims toframework="policyengine_us", making identical policy worlds share a reform key across sources (JCX-35-25 rows could then resolve against the scorecard's harvested JCT claims instead of coexisting as duplicates). -
No publisher slugs. The scorecard derives publishers from citation strings ("CA FTB…" →
ca_admin); abenchmark_publisherfield per spec (e.g.ks_lrd,ct_ofa,jct,census) would make source attribution exact instead of heuristic.
Both are additive to schema v1 (consumers ignore unknown keys). Happy to PR this once the scorecard-side design questions in PolicyEngine/policyengine-scorecard#15 settle.
🤖 Generated with Claude Code
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the code that produces reform_validation.json and reading the existing state_reforms.json data used for reform_params. Review policyengine-scorecard#15 and #16 before changing the schema, then verify that each emitted row contains the applicable reform data and benchmark_publisher while remaining compatible with schema v1 consumers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100