PolicyEngine / PolicyEngine/policyengine-scorecard

Baseline as a first-class attribute of every score

Open
#13 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 (8/2): "we should have the baseline as a first class attribute of the score in our db." The day supplied four independent proofs: PWBM tables scored vs TCJA-extension; JCX-29-25 scored vs current policy (twin of JCX-35-25 vs present law); TPC's CTC set scored vs current law + Senate Title VII; and PE's own two-child-limit run, where the 2026 current-law baseline already contains AB2025's abolition so "removal" had to be measured against a reinstated counterfactual. A score's meaning IS its (reform, baseline) pair — baseline can't live half-inside ReformRef.baseline JSON and half in conditions.baseline_policy strings.

Schema change

  1. baselines registry table: baseline_key (hash) · label (closed slug vocabulary, extend deliberately: current_law | current_policy | tcja_extension | pre_ab2025 | current_law_plus_senate_title_vii | …) · description · framework · spec_json (nullable — many external baselines are named conventions, not expressible parameter dicts) · provenance (the source's own words defining it).
  2. baseline_key column on external_scores, pe_results, and pe_exhibits (FK to registry). Claim-id hashing unchanged (ReformRef keeps carrying baseline content for the hash) — this is an additive queryable projection, no id migration.
  3. comparisons view exposes both the claim's baseline label and the PE result's actually-run baseline. Guard: rows where claim-baseline ≠ pe-baseline can never render as plain agreement — auto-annotate constructed (or concept_mismatch) unless a registry equivalence says otherwise. App (#9): baseline chip on every row, same pattern as vintage chips.
  4. Migration of existing data: Urban rows → current_law (2023); fullpart/solo exhibits → baseline current_law with input-override reform; harvest ingest maps the staged baseline_policy / baseline_hint / conditions.baseline fields into registry entries (PWBM, JCT, TPC ones enumerated in COLLATION.md).
  5. PE-side rule: every run records the baseline it actually executed (e.g. tonight's two-child rows: reform=pre_ab2025→current_law direction made explicit rather than implied by sign).

Grounding artifacts: ~/populace-sotsn-takeup/results/uk/two_child_reinstate_2026.json (the reinstated-counterfactual construction), COLLATION.md §ingest-worklist item 3 (baseline variants are load-bearing).

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

Read COLLATION.md §ingest-worklist item 3 and the two_child_reinstate_2026.json grounding artifact first, then trace the external_scores, pe_results, pe_exhibits, and comparisons data paths. Done means baselines are registry-backed, existing data is migrated, executed and claimed baselines are exposed and mismatches are annotated, and every score displays its baseline.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend-api-design, database
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.