PolicyEngine / PolicyEngine/policyengine-scorecard

Reform-period-metric view: every source's score for one target in one place

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

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

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.