Audit SAFETY_MARGIN = 0.1 on disability-benefit category thresholds

[MaxGhenis]

Problem

_category_from_reported_amount in policyengine_uk_data/datasets/disability_benefits.py:59-70 applies a fixed SAFETY_MARGIN = 0.1 (10% slack) when bucketing reported weekly amounts into category labels:

SAFETY_MARGIN = 0.1
...
for category_name, weekly_rate in thresholds:
    category[weekly_amount >= float(weekly_rate) * (1 - SAFETY_MARGIN)] = (
        category_name
    )

The docstring on line 41-44 explains this matches "the category formulas removed from policyengine-uk … against the baseline DWP rates" — i.e., the slack handles uprating timing between when the FRS amount was recorded and when the DWP rate parameter applies.

Concern

A blanket 10% downward shift on the threshold pushes borderline lower-rate cases into higher rate classes more often than the threshold is actually meant to slip. For PIP daily-living standard at £73.90/week (2025-26), 10% slack means anyone reporting ≥ £66.51/week gets classified as STANDARD. Anyone at £66.51 in the source data is below the actual statutory threshold and shouldn't be flagged Standard.

Concrete effects worth checking:

• Does the FRS calibration step rebalance to hit DWP caseload targets per category? If so, the 10% slack is partly absorbed by weight calibration and matters less.
• For categories with closely-spaced rates (PIP DL Standard £73.90 → Enhanced £110.40, a ~50% gap), 10% slack is benign. For more closely spaced rates (DLA care lower vs middle, or AA lower vs higher), 10% could swap categories.
• The transfer pipeline doesn't run this step at all (separate issue), so this question only affects the FRS pipeline.

Suggested investigation

1. Calibrate per-category counts after the threshold step and confirm they match DWP Stat-Xplore breakdowns within the calibrator's tolerance.
2. If counts drift systematically toward higher categories, narrow the safety margin (or replace it with a per-year-aware threshold that uses the actual DWP rate effective on the FRS reference date).
3. If counts match, document the 10% choice with a comment naming the source-year rate vs the target-year rate it's bridging.

Question

Is the 10% number empirically tuned (against what target?) or a placeholder from the removed PE-UK formulas? A pointer to the original PE-UK derivation, or a brief justification, would make this safer to extend or tighten.

Out of scope

• The wider is_disabled_for_benefits scope question — separate issue.
• The transfer pipeline's missing call to add_disability_benefit_categories_from_reported_amounts — separate issue.