PolicyEngine / PolicyEngine/microcosm

reform_validation_payload: embed executable reform dicts + publisher slugs for scorecard claim identity

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

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:

  1. No executable reform dicts. Scorecard claims key off a ReformRef; with only a row id available, scored rows use policy_ref descriptors ({"policy": "ks_hb2620_eitc"}). The param dicts already exist in state_reforms.json — emitting each row's reform_params (and non-current-law baseline where applicable, e.g. the OBBBA suite's TCJA-expiration counterfactual) upgrades claims to framework="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).

  2. No publisher slugs. The scorecard derives publishers from citation strings ("CA FTB…" → ca_admin); a benchmark_publisher field 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

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 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.