PolicyEngine / PolicyEngine/policyengine-scorecard
Reform-period-metric view: every source's score for one target in one place
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 6d 12h
- Merged PRs (30d)
- 32
Description
Max (2026-08-29, from the Belgium PIT-reform lane): "we should be able to see all scores for a given reform-period-metric in one place."
Reform validation today is row-per-claim, keyed by source. The Belgium case makes the gap concrete: three sources publish a revenue change for the same reform at the 2030 horizon — SPF Finances −€4.0B, Cour des comptes −€5.0B, PolicyEngine −€4.16B — and they render as three separate table rows, with the period-basis caveats repeated per row instead of stated once for the group.
Ask: a grouped surface keyed by (reform, period, metric) that renders every source's value side by side.
Existing analogues this would serve immediately:
- BE: the three PIT-reform 2030 estimates above (period bases differ and stay labeled unresolved — the group view must carry that per pair, not resolve it).
- US: JCT / CBO / TPC / PWBM scoring the same provision and window (the OBBBA triangle; the two-child-limit pentagon is the UK cousin).
- UK: HMRC ready-reckoner vs PE per tax head and forecast year.
Design notes from the registry as it stands:
- The grouping key already exists in the DB:
ReformRef+period+metric(+ unit concept). No new ingest needed for a first cut. - Cross-source display needs pairwise status/benchmark-class semantics — today's
benchmark_class/status is PE-vs-external; source-vs-source cells in a group view are constructions too and need the same descriptive labeling (no "closest", no implied winner — doctrine #9). - Baselines differ across sources (#13 registry) — a group view must show each member's baseline, or mismatched-baseline members render as plain disagreement.
- Related but distinct: #10 (assumptions registry: why they differ), #9 (app views). This issue is the where they all are surface.
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 tracing the existing row-per-claim rendering and the registry grouping key of ReformRef, period, metric, and unit concept. Review benchmark_class/status and baseline fields, then define a grouped surface that places source values side by side while preserving pairwise labels, per-source baselines, and unresolved period-basis caveats without implying a winner.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data-visualization, databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100