[juaristi22]

Microcosm fixes from reconciling PolicyEngine's static cost of removing the £100,000 limit on England's working-parent hours against CenTax's (Removing the childcare cliff edge, September 2026), and from Vahid's two review rounds. The dashboard is PolicyEngine/uk-childcare-100k-threshold#8. Part of #1339.

Rebuilt on main 8b0224e (after #1333) and re-locked to policyengine-uk 2.147.2. This lands before #1344, which rebases onto it (María's ruling of 2026-10-22 on Vahid's finding B). The earlier history is replaced: the reverted SPI items 3 and 4 and their reverts are dropped, and the pin passes are regenerated once at the end.

What changes

1. Nested childcare take-up (frs_take_up). would_claim_universal_childcare = extended OR u < r, where r is the rate among units not claiming the extended hours.
   • Independent draws let a family over £100k hold extended-yes and universal-no. Removing the limit then funded its 3-4-year-old's universal 15 hours too.
   • The take-up gate targets the nested marginal and fails on extended-without-universal.
   • The contract now refuses a nested rate whose receipt predates the conditional basis (fitter tool version 5).
2. Copies re-draw their childcare draws (childcare_copy_take_up, a new stage after every copy stage). SPI, high-value-home and CGT copies re-draw the childcare flags and hours on their own benefit units instead of inheriting their host's.
3. ONS single-year age targets. The UK's ages 3-6 and England's 0-6, from the mid-2025 estimates (published 1 October 2026).
4. policyengine-uk 2.147.2 (Stop early years hours once a child starts school, and start working parent hours with the next term policyengine-uk#2570). Early-years hours stop when a child starts school, from its date of birth; working-parent hours start the term after the minimum age (9 months). Every re-derived pin, the concept coverage (311 to 314 inputs) and the cited versions follow. Other changes since 2.145.0 that move results:
   • Universal Credit LCWRA and carer elements follow the claimants (2.146.3);
   • HBAI income takes property income after finance costs (2.147.1);
   • additional State Pension uprating (2.145.1);
   • dependants' income is no longer counted in the legacy means tests (2.147.0);
   • Carer Support Payment applies its earnings limit (2.146.1). The Carer's Allowance take-up stage still leaves Scotland closed; its stated reason is updated, and opening Scotland is a UK Carer's Allowance: would_claim follows reported receipt, so earnings-limit reforms reach 4,600 new carers against an official 61,000 #1319 follow-up.
5. DfE rows at the spring term (Vahid's finding A).
   • DfE counts registrations in January by age on 31 December. Each DfE row now counts the children funded in the term that starts on 1 January of the model year, by that age (uk_runtime/dfe_spring_term.py, routed through the measure resolver).
   • It uses the engine's date-of-birth school start, not current_education.
   • The universal and early-learning measures count every child of the DfE age, as the term after the birthday does; the engine still gates these on the age on 6 October.
   • A child is counted under one DfE entitlement: early learning takes precedence at age 2, and at 3-4 a working-parent child is one that uses more than the universal 15 hours.
6. DfE single-age rows (England, January 2025):
   • bound: working parent at 9 to 11 months and ages 1, 2 and 3, and universal nursery at age 3, beside the working parent 2-to-4, early learning and universal-only rows;
   • signed out: the age-4 cells, which the bound rows fix, plus totals, estimates and percentages, with the reasons in the accounting note;
   • the 9-to-11-months row has its own uprating hold, approved by María on 2026-10-22.
7. Under-2 take-up, one rate per DfE age (María's ruling: "bind them with their own take up").
   • Each child of DfE age 0 or 1 in a claiming unit draws whether it uses the hours, at its age's rate. A non-user gets max_free_entitlement_hours_used 0; everyone else keeps the engine's 30.
   • The DfE age is the age on 31 December, as DfE counts registrations (Vahid's finding E, round 3). dfe_spring_term.dfe_age_at_31_december restates the engine's date of birth so the build stages, which run without the engine, key on it; an engine test holds it to policyengine-uk.
   • DfE registered 42% of eligible 9-to-11-month-olds and 70% at age 1 in January 2025, against about 85% at 2-4 (the 2026 release revises these to 44% and 69%). One rate fitted at 2-4, or one rate for both ages, funded the wrong number of them.
8. Fitter tool version 7.
   • Scope: model year 2025, on the spring-term measures; six rates, the two under-2 shares included, each scaling the children of its DfE age.
   • Receipt: it records each rate's estimand (Vahid's finding C: the Tax-Free Childcare rate is a fit to HMRC's two rows, not a take-up estimate for newly eligible families) and which rates sit at a bound and why.
   • Contract: it refuses a receipt from version 6 on without those.
   • Input guard: the fitter refuses a spine without stored birth months.
9. A realised-take-up report (Vahid's item 3): tools/report_uk_childcare_realised_take_up.py. It gives each flag's contract rate beside its realised unweighted and weighted share at a built file's final weights. Cells under 10 source households read "<10".

The refit (tool version 7, local spine at 6aea1ec)

Rate	Value
Tax-Free Childcare	0.9697
Working parent	0.8262
Universal, conditional (at its lower bound)	0
Early learning for 2-year-olds	0.6551
Under-2 usage, DfE age 0	0.6962
Under-2 usage, DfE age 1 (at its upper bound)	1

Row, before calibration	Model / DfE or HMRC
Working parent 2 to 4	0.999
Working parent 9 to 11 months	1.000
Working parent age 1	0.943
Early learning for 2-year-olds	1.000
Universal-only	1.052
HMRC TFC children / top-up	1.064 / 0.927
Diagnostic: working parent age 2 / age 3, nursery age 3	1.091 / 0.933, 1.009

The national calibration binds every row; the receipt records each residual.

Build

Built at 829c1bc (before the DfE-age keying of item 7, which the next build from main carries) on the signed 9427392 spine, certified on 23 October and published to the inspect lane as microcosm-uk-2024-25-national-20261023T075039Z-a133f37a; not promoted to latest.

• Certification: all 19 release-cut gates pass. The first attempt at 9427392 blocked on uk_export_surface: main's war_widows_pension_reported (Split War Widow's Pension (FRS code 9) out of bsp_reported #1222) had no allow-list entry. 829c1bc adds it, and a new engine-free test runs that gate on the spine's declared columns.
• Calibration: every DfE childcare row and both HMRC Tax-Free Childcare rows land within ±0.2%; 99.1% of all rows are within 10%.
• Head-to-head: loss 0.038 against the promoted 6cba5d71's 0.080 (855 rows won, 403 lost) and a858c100's 0.077 (817 won, 441 lost); every DfE row and both TFC rows won against each.
• Realised take-up (benefit units with a child under 5, final weights): Tax-Free Childcare 0.969 against a contract rate of 0.970, working parent 0.852 against 0.836, early learning for 2-year-olds 0.644 against 0.655.
• Rows by DfE age, eligible pools and the January 2026 comparison: in the round-3 reply.

For review

• Census year. The rows bind January 2025, which sets where the file lands. At model year 2025 the engine's spring term is January 2026, one birth cohort later. Against January 2026 the working-parent rows at 9 to 11 months and ages 1, 2 and 4 come out 5–9% low, and early learning for 2-year-olds and universal-only about 10% high (table in the round-3 reply). Binding January 2026 is a follow-up.
• Universal and 2-year-old start. The measure mirrors the term after the birthday; Universal hours and the 2-year-old offer start on the age at 6 October, not the term after the birthday policyengine-uk#2588 asks the engine to do the same. Until it lands, the universal and early-learning rows count children born from 7 October to 31 December, whom the engine does not fund that year. Calibration partly meets DfE's counts with them, so universal and targeted spend come out a little low.
• Gate note wording. The take-up signal gate's note still says "whole-year age". Rewording it would move the gate pins that the published certificate is checked against, so it changes at UK #1334: draw UC take-up by award band, and measure the HMRC income rows over each person's year #1344's re-pin.
• Bound rows. The working parent 2-to-4 and universal-only rows stay bound, and the age-4 cells stay signed out because those rows fix them (María, 2026-10-22).
• Unmodelled starts. The FRS records neither deferred school starts nor council-funded independent reception places, so the model undercounts 4-year-olds in nursery slightly.

Not in this PR

• The design-weighted SPI copy prior (branch uk-cc-spiprior) and the SPI pay floor (uk-cc-spipay), each for its own PR.
• The copies' stream offset docstring (Vahid's item 7).
• Opening Scotland to the newly entitled Carer's Allowance draw now that the engine applies Carer Support Payment's earnings limit (UK Carer's Allowance: would_claim follows reported receipt, so earnings-limit reforms reach 4,600 new carers against an official 61,000 #1319).
• A signed spine-swap difference entry for the new person column.

Tests

• Engine-free: the touched tests pass, and tools/ci_test_plan.py verify is ok.
• Engine: the spring-term measures are checked on hand-built households: date boundaries, claim-off families, the DfE-age-2 corner, a child outside England and a deferred start. The build stages' DfE age matches the engine's at 2024-2026, including the 7 October boundary.
• Pin pass: the compile-parity receipts, coverage manifest, H2 fixture and gate-battery pins are regenerated; after the DfE-age keying, the coverage manifest and H2 fixture again (the gate pins do not move).

Disclosure control: the figures here are weighted national aggregates and public DfE, ONS and HMRC figures. Every fitted or diagnostic row rests on at least 10 FRS source households, and nothing rests on unit records.

🤖 Generated with Claude Code

[vahid-ahmadi]

@juaristi22 thanks, this is my review at 45b8f34f6.

Verdict. The six fixes are well aimed and the nesting fix (item 1) is clearly right. But this head should not be built as the release yet. The contract still carries the tool version 4 rates while the code now reads the universal rate as a conditional rate (finding 1). The pin pass is also still open (finding 2). Separately, the take-up that is supposed to fix the £100k cell is not conditioned on income anywhere in this diff. DfE and CenTax both point to take-up for newly eligible families being higher than our contract rate, not lower (finding 3). So I would not expect this PR to close the gap to CenTax through take-up. The gap more likely sits in who is eligible and what each child costs. Findings 1 and 2 must be fixed before the build. Everything else can follow.

What I ran (and what I didn't)

• Fresh worktree at 45b8f34f6, uv sync --all-packages --locked --extra uk.
• The engine-free tests for every touched area, plus tests/engine/uk/test_uk_spi_income.py: 594 passed, 7 skipped, 4 failed. All four failures are pin-pass items the PR body already lists:
  • test_uk_spi_spine.py::test_readers_of_the_support_record_take_the_declared_allocation_reason: the committed record still holds the old SPI allocation reason, without the "design weights to the power 0.5" clause.
  • Three in test_uk_release_input_coverage_manifest.py: the manifest needs regenerating.
• tools/ci_test_plan.py verify: ok.
• CI: no checks are reported on the branch.
• Overlaps checked against your open PRs UK #1326: 2023-24 Scottish property income by NSND band (project tool, not for merge) #1327, Draw UK QRF stages from uniforms keyed on each record's id, and tie pension contributions to pay #1332 and Lock policyengine-uk 2.145.0, follow its bus fares and bind thin target rows #1333 (finding 9).
• Sources checked: DfE Funded early education and childcare, January 2026 (published 2 July 2026), and the CenTax report (Advani et al., September 2026), sections 2.5, 4 and Appendix C.
• Not run: no build or refit. That needs licensed FRS/SPI data, so every effect on the static cost below is a direction, not a measurement.

Findings

1. must: the universal rate changes meaning before it is refitted. take_up_contract.json:294-306, frs_take_up.py nest_universal_childcare.

   • The code now draws universal = extended OR u < 0.4353.
   • The contract note says 0.4353 "was fitted as an unconditional rate (tool version 4) and is carried unchanged".
   • At r_e = 0.6579 the universal flag's share therefore jumps from 0.435 to 0.6579 + 0.3421 × 0.4353 = 0.807.
   • The signal gate cannot catch this, because _target_share now targets the nested marginal and so passes by construction.
   • A build at this head would overstate universal hours in the baseline and miss the DfE universal-only row. It would also move funded-hours spend (£8.80bn against DfE's £9.9bn on the 19 October release) for the wrong reason.
   • As your checklist says, this still has to land: please land the tool version 5 refit of all four rates on this branch, and add a test that fails if the receipt is version 4 while nested_under is set. The build should wait for both.

2. must: finish the pin pass before the build. The coverage manifest, the SPI allocation reason in the support record, and the compile-parity receipts are stale (the four failures above). These are known, but they are release-blocking, and the "still to land" checklist in the PR body is still unticked.

3. should, and it matters for what this PR can achieve: take-up is not conditioned on income, and the sources do not support a lower rate for families over £100k.

   • No change in the diff makes the extended rate depend on income. Every unit draws at one flat r_e.
   • So the drop in the over-£100k cell's would-claim (73.8% on the 19 October release) comes only from the copies' re-draw (item 5). It moves the realised share back towards r_e.
   • The refit then raises r_e, because reception children leave the DfE rows (item 2).
   • DfE's January 2026 release estimates that 91% of eligible 3-4-year-olds (388,700) and 80% of eligible 9-month-to-2-year-olds take up the working-parent entitlement.
   • CenTax's static cost also applies DfE's take-up rate by age to newly eligible parents (report, Appendix C, p. 75 and footnote 44). It does not use a lower rate.
   • Their roughly 60% "live account" share (Figure 2.1) is used only in the low-cost scenario. The 33% share at £100,000-£120,000 reflects current ineligibility, not demand.
   • If a later change lowers take-up for families over £100k to match CenTax, I don't think any source supports it, and it would go against CenTax's own method.
   • DfE notes that its eligible-population estimates should be treated with caution, particularly for 2026.
   • With a contract rate of about 0.66-0.75 against DfE's 80-91%, we already cost newly eligible families at a lower take-up than CenTax does. Yet we come out about 25% higher. That points to the eligible pool or the cost per child (finding 6), not take-up.
   • A low fitted r_e that still hits DfE's 388,700 registered children also suggests our eligible pool is larger than DfE's estimate. The test that tells these apart is the build's count of parents over £100k with a child aged 9 months to 4 and a working partner, against CenTax's "almost 200,000 potentially eligible parents" by 2030 (p. 41). Please put that count in the build receipt.

4. should: there is no diagnostic for the concentration the SPI prior change is meant to fix.

   • The square-root shape was chosen on whole-calibration measures: rows at the weight-ratio cap, Kish ESS, and the standard error of the £125-150k band.
   • The only weight fence is global: uk_weight_ratio max/median ≤ 1151 (gates.json:823).
   • On the 19 October release, ten records carried 34% of the 30-hours cost, and the release still passed that fence.
   • Damping by GROSS4 should lower the prior of young-family copies, which the PR says are over-represented. That helps, but nothing here shows that it does.
   • Please add a receipt for the over-£100k, child-aged 0-4 cell: its Kish ESS, and the share of its weight held by its top ten source households (as a share, which is disclosure-safe). Also give the before and after numbers for the shapes you screened.

5. should: the hours floor narrows a pool the dashboard's labour supply channel reads. spi_income.py:787.

   • The floor lifts drawn SPI pay to the twin's own hours at the minimum wage. That is right for the 30-hours and TFC minimum-income tests.
   • It also means fewer SPI-twin partners with positive hours fail the minimum-income test.
   • The dashboard's "partners into work" response (in the dashboard repo, not here) depends on how many families over £100k have a partner who fails that test. The floor will shrink that response.
   • Only a note for the release: please report the floor's added amount next to the HMRC SPI employment-income targets, so the size of the side effect on those targets is visible.

6. should: the remaining eligibility drivers sit outside this PR, so please list them on UK: childcare take-up draws, the take-up fit pool, SPI-channel copy weights and the young-child age profile distort the £100k childcare costing #1339.

   • Reception children keep funded hours in policyengine-uk (listed under "Not in this PR"). Calibration now leaves them out of the DfE rows, but the reform still funds them. That inflates the 30-hours cost against CenTax, whose 3-4 base is DfE's, which excludes reception.
   • The only working-parent target is working_parent_children_2_to_4. The 9-23-month group, 241,500 children in DfE January 2026 (30,700 aged 9-11 months plus 210,800 aged one), is not bound. On the 19 October release we had 366k under-3s against DfE's 501,700.
   • Adding the under-2 row, at least as a diagnostic, is cheap. It would show whether one flat r_e fits both age groups, given that DfE's take-up rates differ (80% against 91%).

7. nit: the copies' streams depend on the frame's id offset. childcare_copy_take_up.py:17-21.

   • The draws are keyed on source id + k × offset, where the offset sits above every id in the frame. They are deterministic for a given frame.
   • If the offset is computed from the frame's ids rather than fixed, any upstream change that moves the maximum id re-keys every copy's draws, which makes builds hard to compare.
   • Keying on (source benefit unit id, clone path, clone index) would make them stable. Fine as a follow-up.

8. nit: the reason text for the age targets. The reason text for each new age row dates the request (2026-10-21) but not the data. The national 0_4/5_9 bands and the region 0_9 cells use the same ONS mid-2025 series, so the nesting is consistent. It would help to name the feed's release date in ons_single_year_ages_0_6, as the 0-2 rows do through UK local surface, consumption and high-value homes: remaining items (consolidation) #1278.

9. should: merge order with Lock policyengine-uk 2.145.0, follow its bus fares and bind thin target rows #1333 and Draw UK QRF stages from uniforms keyed on each record's id, and tie pension contributions to pay #1332.

   • Lock policyengine-uk 2.145.0, follow its bus fares and bind thin target rows #1333 touches ten of this PR's files: frs_take_up.py, spi_support.py, spi_income.py, spi_spine.py, graph.py, sources.yaml, source_stages.json, gates.json and two tests.
   • Draw UK QRF stages from uniforms keyed on each record's id, and tie pension contributions to pay #1332 touches spi_income.py, spi_spine.py and the same two tests.
   • UK #1326: 2023-24 Scottish property income by NSND band (project tool, not for merge) #1327 has no overlap.
   • Whichever of these lands second needs its regenerated artefacts (stage manifest, coverage manifest, receipts) rebuilt on top of the first. So please fix the order before the pin pass, or the pin pass will be done twice.

Expected effect on the 30-hours static cost

This can only be read as a direction, not a size:

• Nesting (item 1): down. About £0.14bn a year, the PR's own figure.
• Copies' re-draw (item 5): down. The over-£100k cell's realised take-up falls from about 74% towards r_e.
• Refit without reception (item 2): up. It raises r_e for everyone, newly eligible families included.
• Age targets (item 6): small and up. More 1- and 4-year-olds, fewer 5-year-olds.
• SPI prior and pay floor: unclear. They depend on how the cell re-weights.

On balance I'd expect a fall of the order of £0.1-0.2bn, partly offset by the refit. I would not expect the result to reach CenTax's £0.80bn unless reception children are also removed from the reform cost.

What looks right

• Nesting universal under extended, the refusal when a manifest drops nested_under, and the gate check that fails on extended-without-universal.
• Leaving reception out of both the fitter and the calibration bindings, which matches DfE's January basis.
• Restoring the UK release input-coverage contract: 145-required gate, effective-mass semantics, and the real-donor HMRC replay #420 positive-weight guard and refusing to shape by fitted weights (National staging rebuild fails the current terminal gates: constant source_year release column and SPI weight tail above the reviewed maximum #630).
• Re-drawing the copies' childcare draws with the same helper, salts and contract, and leaving native units unchanged. The tests cover nesting on copies and every clone path.
• Disclosure handling in the new receipts: "<10" cells and no minima or maxima.

🤖 Generated with Claude Code

[vahid-ahmadi]

@juaristi22 thanks, this is my second review, at 3bb28f8f5.

Verdict. Both musts from round 1 are fixed: the four rates are refitted at tool version 5, and the pin pass is done (tests and CI green). I have no must this round. The branch merges cleanly with main, and on the a858c100 build it does what it set out to do: on CenTax's basis the dashboard now lands at £0.87bn / £0.96bn against CenTax's £0.80bn / £0.98bn. Two things should be settled before this becomes the promoted release, though neither blocks the merge. First, the universal rate now sits at its lower bound of 0, so universal take-up is exactly the extended draw. The fit is pushed there by a row that has the same 31 December age problem you used to sign out the age-4 cells (finding A). Second, a858c100 was built without #1332, which has since merged, and #1344 changes who is on UC. So the v5 rates and the receipts will need one more refit once the merge order is fixed (finding B).

Round 1 findings at this head

1. Universal rate changed meaning before the refit: resolved. The v5 refit landed in 0b8e7ac39: extended 0.7594, targeted 0.8478, Tax-Free Childcare 0.9912, conditional universal 0. On the a858c100 file, would_claim_universal_childcare equals would_claim_extended_childcare for every benefit unit, as a rate of 0 should give. The guard test I asked for (fail if the receipt is pre-v5 while nested_under is set) is not there. Now only a nit.
2. Pin pass: resolved. Receipts, coverage manifest, gate-battery pins and the H2 fixture are all regenerated. The four failures from round 1 now pass, and CI is green at this head.
3. Take-up not conditioned on income: still true by design, but my round-1 point needs correcting. I compared DfE's 80-91% with the contract rate. I should have compared it with the realised, weighted rate. On a858c100, in the cell of families with a child under 5 and an adult with over £100k of pay plus self-employment income (a pay proxy, not ANI):
   • the extended draw is 0.75 unweighted, which matches the contract, so the copies' re-draw works;
   • weighted, it is 0.85, because calibration moves weight towards claimers (copies 0.88, natives 0.80; copies hold 59% of the cell's weight). The same lift shows outside the cell (0.81 for all families with a nursery-age child);
   • 0.85 sits inside DfE's 80-91%.
     So newly eligible families are now costed at about DfE's take-up, not below it. My round-1 claim that we cost them lower than CenTax does no longer holds. The useful follow-up is to record the realised weighted rate in the receipt next to the contract rate, because the weighted rate is what the reform cost actually uses.
4. No concentration diagnostic: partly resolved, and moved. Item 3 is reverted, so this belongs on the uk-cc-spiprior PR. For the record, on a858c100 the cell above has a Kish ESS of about 130. Its ten largest source households hold 23% of its weight, from a few hundred source households in all. The dashboard reports that the ten largest records carry 27% of the 30-hours cost, down from 34%. That is better, but there is still no receipt in the build.
5. Pay floor narrows the partners-into-work pool: moot here. Item 4 is reverted. Please carry it to the uk-cc-spipay PR.
6. Eligibility drivers outside this PR: partly resolved. The DfE single ages bind working-parent ages 1, 2 and 3, which covers the under-2 row I asked for. Reception hours, 9-11-month-olds, DfE funding rates and ANI pension contributions are listed under "Not in this PR". Please confirm they are on UK: childcare take-up draws, the take-up fit pool, SPI-channel copy weights and the young-child age profile distort the £100k childcare costing #1339 or open as pe-uk issues. One caution on the dashboard check against DfE: the bound rows are January 2025, and the dashboard compares with January 2026 (379k vs 388.7k at 3-4, 438k vs 501.7k under 3). The under-3 gap partly reflects the September 2025 expansion, so it is not a failure of the fit.
7. Copies' streams depend on the frame's id offset: open, nit. The docstring still keys on source id + k × offset, with the offset taken from the frame. Fine as a follow-up.
8. Feed release date in the ONS reason text: open, nit. ons_single_year_ages_0_6 still names the mid-2025 series but not the feed's release date.
9. Merge order: changed, see finding B.

What I got wrong in round 1. I expected the fixes to cut the 30-hours cost by about £0.1-0.2bn. As shipped it went from £1.01bn to £0.96bn, a fall of only £0.05bn, though the engine also moved from 2.132.6 to 2.134.4. The refit raised the extended rate from 0.66 to 0.76, and that offset more of the nesting gain than I allowed. My point that the remaining gap was reception, not take-up, did hold.

New findings

A. should: the universal fit is at a corner, driven by a row with the age-4 reference-date problem. take_up_contract.json (universal_childcare receipt), uk_population_targets.json (universal_only_children).

• You signed out the age-4 DfE cells because DfE's ages are at 31 December, when about two-thirds of funded 4-year-olds are in reception. On a858c100, 52% of England's 4-year-olds are in primary. That is about what interview-date ages should give, so the model is not wrong here; the two bases differ.
• universal_only_children (nursery universal at 3 and 4, less working parent at 3-4) and the working parent 2-to-4 row both count those same 4-year-olds outside primary. observation_basis: january_stock is only a label: nothing in the code moves ages to 31 December.
• So the fitter is absorbing a basis mismatch. The universal rate goes to 0, universal-only still comes out 3.6% high and working parent 2-to-4 3.9% low, and calibration then fixes the rest through weights.
• This matters for the reform, because 4-year-olds outside reception are the pool that gains hours when the limit goes.
• Either re-reference the measure to 31 December ages, or treat universal_only_children like the age-4 cells, for example by binding the age-3 nursery row only. Then the universal rate is fitted on the same basis as the rows you kept.

B. should: refit once the merge order is fixed.

• Draw UK QRF stages from uniforms keyed on each record's id, and tie pension contributions to pay #1332 (keyed QRF draws, and pension contributions tied to pay) merged at 18:08 on 21 October. This branch starts before it, so a858c100, the v5 fit's input spine and the receipts were all built without it. Its re-keyed QRF draws move pay. Its pension change will feed ANI, the £100k test, once policyengine-uk deducts pension contributions, as the dashboard's CenTax basis already does. The merge is clean in text, but no main commit will reproduce a858c100.
• UK #1334: draw UC take-up by award band, and measure the HMRC income rows over each person's year #1344 overlaps this PR in 25 files, including take_up_contract.json, frs_take_up.py and the gate pins. Its UC take-up by award band moves who is on UC, and UC childcare and Tax-Free Childcare are mutually exclusive, so it moves the Tax-Free Childcare pool the 0.9912 rate was fitted on.
• Lock policyengine-uk 2.145.0, follow its bus fares and bind thin target rows #1333 is now conflicting and overlaps in 15 files.
• Whichever of UK: childcare take-up at the spring term, under-2 take-up and single-age targets behind the £100k childcare costing (policyengine-uk 2.147.2) #1338 and UK #1334: draw UC take-up by award band, and measure the HMRC income rows over each person's year #1344 lands second needs the childcare rates refitted and the pin pass redone, and the dashboard (Register populace-uk 2023 (private; beats enhanced FRS 6/6) #8) rerun on that build. Settling the order now avoids doing this twice.

C. should: Tax-Free Childcare take-up near 1. The v5 rate is 0.9912. Weighted, it is 0.998 in the over-£100k cell. The two HMRC rows still cannot both be met: children with used accounts come out 11% high, top-up spend 14% low. So the rate is set by the spend row, not by an observed take-up. I've raised the effect on the reform's Tax-Free Childcare leg on the dashboard PR. Here I'd only ask that the receipt say plainly that the rate is not a take-up estimate for newly eligible families.

D. nit: the DfE single-age values. The four rows read the pinned feed, which I could not open, so I have not checked their values against DfE's January 2025 tables. The definitions and filters look right: reception left out from age 2, no primary filter at age 1, universal age 3 counting working-parent children.

What I ran (and what I didn't)

• Fresh worktree at 3bb28f8f5, uv sync --all-packages --locked --extra uk.
• Touched engine-free tests: 836 passed, 7 skipped. Engine tests for childcare targets, the take-up contract and SPI income: 23 passed. tools/ci_test_plan.py verify: ok. CI at this head: all ten checks green.
• Merged with current main locally (clean). Engine-free suites on the merge: UK 5,949 passed and 2 failed, shared 4,110 passed, data 1,053 passed and 1 failed. All three failures come from my machine, not the PR. There is no node binary for the Orrery test, and an import-path error in one test_release.py test; both fail the same way on main alone. The third is the "engine unavailable" test, which fails because I installed the UK extra.
• Read the a858c100 release file (sha256 checked) for weighted aggregates only: the nesting equality, realised take-up by copy and native, the cell's ESS and top-ten share, and the share of 4-year-olds in primary. No figure here rests on fewer than ten source households.
• Not run: no build or refit (licensed data), and no dashboard rerun. The cost figures are from the dashboard PR.
• Disclosure: this PR publishes national targets and metadata receipts only, with no small-area figures. The regenerated artefacts hold no record-level or small-cell counts.

What looks right

• The v5 refit is honest about its corner: it keeps the bound and records the residuals instead of hiding them.
• The copies' re-draw does what it says: unweighted draws in the high-income cell match the contract.
• The age-4 sign-out reasoning is right and well documented. Finding A only asks for the same rule to be applied to the rows it touches.
• Reverting items 3 and 4 for this build when they broke the property_purchases guard was the right call.

🤖 Generated with Claude Code

[juaristi22]

@vahid-ahmadi Thanks for round 2. Everything is addressed on the rebuilt branch. It's on main 8b0224e and re-locked to policyengine-uk 2.147.2, which carries PolicyEngine/policyengine-uk#2570 (the issue you raised on #8 about reception and 9-11-month-olds). Could you review once more? The body has the full list; point by point:

A. The universal fit at a corner (the 31 December basis). The DfE rows are now measured at the spring term.

• What a row counts. The children funded in the term starting 1 January of the model year, by their age on 31 December (dfe_spring_term.py).
• School start comes from the engine's date-of-birth school start, not current_education, so the January stock label is now true of the measure.
• The age-4 cells stay signed out because the bound 2-to-4 and universal-only rows fix them.
• Two corrections from a critique pass:
  • a family that claims only working-parent hours is counted through the engine's gross allocation;
  • a 2-year-old counts under one DfE entitlement only.
• The universal rate is still at 0. With nesting, the claiming families alone exceed DfE's universal-only count (ratio 1.065). The receipt now says so in at_bound_reason, and calibration binds the row.

B. Merge order. María ruled that #1338 lands first. #1344 then rebases onto it and re-pins to 2.147.2, and its session has agreed. The refit and pin pass are done on this head, so #1332 is in the input and #1344 refits after.

C. Tax-Free Childcare. The fitter's receipt now records an estimand for every rate. For Tax-Free Childcare it says the rate reproduces HMRC's two rows, trading one against the other, and is not a take-up estimate for newly eligible families.

Round-1 items:

• 1. Guard. The contract refuses a nested rate fitted before tool version 5. It also refuses a version-6 receipt with no estimand, or at its own bound with no reason.
• 3. Realised rate. tools/report_uk_childcare_realised_take_up.py writes each flag's contract rate beside its realised weighted share at the built file's final weights, including a pay-over-£100k cell. It reads "<10" under 10 source households. I'll post its result with the build.
• 6. Eligibility drivers.
  • Reception and the 9-month start are in policyengine-uk 2.147.2 (#2570).
  • Pension relief in ANI (#2440), the 2029 salary-sacrifice cap (#2462) and DfE's funding rates (#2465) were already in 2.145.0.
  • On the January 2025 against January 2026 caution: the rows bind January 2025, one birth cohort before the engine's spring term. Moving to January 2026 is a follow-up.
• 7. The copies' stream offset. Left as a follow-up, as you suggested.
• 8. ONS release date. The note now names the mid-2025 estimates' release, 1 October 2026.

D. DfE single-age values. All bound values match DfE's published January 2025 figures exactly. The nursery cells come from the 2026 release's 2025 row; the 2025 release has no nursery column, and the four-child difference is hospital-school children with no year group.

New since round 2:

• Under-2 take-up, one rate per age. One working-parent rate fitted at 2-4 overstated the youngest children (DfE registers 44% of eligible 9-11-month-olds and 69% at age 1). The refit gives age 0 a usage of 0.698; age 1 sits at 1, short of DfE by 11% before calibration.
• The 9-to-11-months row is bound with its own approved hold.

The signed national build from this head is next. I'll post the gates, the fit and the costing here and on #8 when it lands.

🤖 Generated with Claude Code

[vahid-ahmadi]

@juaristi22 thanks, this is my third review, at 829c1bc26.

Verdict. Every round-2 finding is dealt with, and I have no must. Moving the DfE rows to the spring term and the engine's date-of-birth school start was the right fix, and the rows now match DfE's January 2025 figures. CI is green at this head. One thing should change before the signed build, because it is cheap now and costs a refit later. The new under-2 usage draw is keyed on the child's age on 6 October, but the rows it is fitted to use DfE's age on 31 December. So the two rates mix age groups, and that is most of why the age-1 rate sits at its bound (finding E). The other points are for the receipt and for the dashboard rerun.

Earlier findings at this head

Round 1:

1. Guard on a nested rate fitted before v5: resolved. The contract refuses a nested rate older than tool version 5, and a version-6 receipt with no estimand, or at a bound with no reason.
2. Pin pass: resolved. Regenerated once at the end. All ten CI checks pass.
3. Realised weighted take-up in the receipt: resolved as a tool. tools/report_uk_childcare_realised_take_up.py does what I asked. Its output waits for the build.
4. Concentration diagnostic: open, but on the uk-cc-spiprior PR, as agreed.
5. Pay floor and partners into work: open, but on the uk-cc-spipay PR, as agreed.
6. Eligibility drivers: resolved. Reception and the 9-month start come from policyengine-uk 2.147.2 (#2570). I checked that pension relief in ANI (#2440), the salary-sacrifice cap (#2462) and DfE's funding rates (#2465) are all merged.
7. The copies' stream offset: open, nit. It is a follow-up, as agreed.
8. ONS release date in the reason text: resolved.

Round 2:

• A. Universal fit at a corner: partly resolved. The basis is fixed: the rows are counted at the spring term by age on 31 December, and school start comes from the date of birth. The rate is still at 0, but at_bound_reason now explains why (see G).
• B. Merge order: decided, not yet carried out. UK: childcare take-up at the spring term, under-2 take-up and single-age targets behind the £100k childcare costing (policyengine-uk 2.147.2) #1338 goes first. UK #1334: draw UC take-up by award band, and measure the HMRC income rows over each person's year #1344 (811f34668) is still on 8b0224e06 and does not contain this head. It overlaps this PR in 27 files, and UK #1334: compute the local metrics from their declarations, and measure the local HMRC rows over each person's year #1347 is stacked on it. The order is UK: childcare take-up at the spring term, under-2 take-up and single-age targets behind the £100k childcare costing (policyengine-uk 2.147.2) #1338, then UK #1334: draw UC take-up by award band, and measure the HMRC income rows over each person's year #1344 rebased with its Tax-Free Childcare and UC childcare rates refitted and its pin pass redone, then UK #1334: compute the local metrics from their declarations, and measure the local HMRC rows over each person's year #1347.
• C. Tax-Free Childcare estimand: resolved. The receipt now says plainly that the rate is a fit to HMRC's two rows, not a take-up estimate for newly eligible families. The rate fell from 0.9912 to 0.9697.
• D. DfE single-age values: resolved, to rounding. The bound rows match DfE's January 2025 release: 29,155 / 195,104 / 242,453 against 29,200 / 195,100 / 242,500 at 9-11 months and ages 1 and 2. Working parent 2-to-4 less age 2 is 379,029, against DfE's 379,000 at 3 and 4. I could not check the single-age split at 3 from the release page.

New findings

E. should, before the signed build: key the under-2 usage draw on DfE age, not on age at 6 October. frs_take_up.py under_two_usage_rates and derive_under_two_childcare_usage; tools/fit_uk_childcare_takeup.py whole_age.

• The draw picks each child's rate from person.age, the whole age on 6 October. The rows it is fitted to use Y - birth_year.
• I checked this on policyengine-uk 2.147.2 with single-child households. A child of whole age 0 with 10 or more months since its birthday was born in October-December 2024, so it is DfE age 1. A child of whole age 1 with 10 or more months was born in October-December 2023, so it is DfE age 2.
• So among the whole-age-0 children funded in the spring term (born 7 October 2024 to 31 March 2025), about half are DfE age 1, aged 12 to 14 months in January. They get the low age-0 rate (0.698). About a quarter of the whole-age-1 children are DfE age 2.
• That fits the receipt. The age-1 rate is pushed to its bound of 1 and DfE age 1 still comes out at 0.894. Roughly a quarter of DfE-age-1 children × (1 − 0.698) is about 7.5% of the row, which is most of the shortfall.
• The fitter handles this consistently, so it is not a bug in the fit. But the two rates mean "a blend of 9-11-month-olds and 12-14-month-olds" and "mostly age 1, some age 2". The estimand text says something else.
• Keying the draw on 2025 − birth_year (the spine already stores birth months) would give each rate the group DfE counts. The age-0 rate would then be a 9-11-month rate, and age 1 would likely come off its bound. The reform funds the youngest children of newly eligible families at whichever rate applies, so this feeds through to the under-3 cost.

F. should: binding January 2025 sets where the dashboard lands, so the receipt should say so.

• The rows bind the January 2025 census, and the model year's spring term is January 2026. You list this as a follow-up.
• It explains the dashboard's 3-4 figure exactly. On a858c100 the dashboard gives 379k working-parent 3-4-year-olds, which is DfE's January 2025 figure (379,000), not January 2026 (388,700). Under-3s will move towards January 2025's 466,700, not January 2026's 501,700.
• This matters most for the under-2 rates. January 2025 was the first year of the 9-month offer, at 15 hours, and the spring term of 2025-26 is the first at 30 hours. A usage rate fitted to that first census probably understates the year being modelled.
• Until a January 2026 fact is allowed, please add January 2026 as diagnostic rows (DfE published it on 2 July 2026), so the receipt shows the gap. That also corrects my round-2 note: the 3-4 gap on the dashboard is the census year, not the fit.

G. nit: why the universal rate is at 0. Universal is drawn as extended OR u < r, and the extended flag is drawn for every benefit unit, including families who can never get working-parent hours. So universal take-up cannot fall below 0.836 for any family. The universal-only row is then fixed only through weights.

• I checked one other possible cause: the hours distribution. It is N(31.1, 5.0) clipped to [0, 30], so almost no working-parent child falls at 15 hours or under and gets moved into universal-only. That is not the cause.
• The pre-calibration split by age (working parent age 2 at 1.105, age 3 at 0.945, universal nursery age 3 at 1.021) shows calibration has to move weight between ages.
• Please add the realised post-calibration rows by single age to the build receipt next to these. No code change is needed for this PR.

H. should: put the eligible pool by DfE age in the receipt. The question from my round 1 is still open, and now there is a number for it. At a family rate of 0.836, with age-1 usage at 1, the frame's working-parent children at DfE age 1 (174k before calibration) imply roughly 225k eligible children. DfE's 195,100 at 70% implies about 279k. DfE says its eligible estimates need caution. But a pool about a fifth smaller, which calibration then makes up through weights, is worth seeing in the receipt: the eligible count by DfE age, unweighted source households and weighted.

I. nit: DfE's under-2 take-up percentages. The PR body says DfE registers 44% of eligible 9-11-month-olds and 69% at age 1. The January 2025 release gives 42% and 70%. If the body's figures come from the January 2026 release, please say so, since the rows are January 2025.

J. should, until pe-uk #2588 lands: the universal and 2-year-old measures count children the engine does not fund. The measures count every child of the DfE age in the spring term. The engine still gates these entitlements on age at 6 October, so it pays nothing for children born from 7 October to 31 December. Calibration will hit DfE's count partly with children who cost nothing in the model, so universal and targeted spend will come out a little low until the engine follows. Please name this in the receipt beside the rows it affects.

How this interacts with policyengine-uk #2570

• #2570 (in 2.147.2) stops early-years hours when a child starts school, using the date of birth. It starts working-parent hours the term after 9 months, and each term counts for a third of the year.
• The DfE rows here read early_years_term_share_before_school and extended_childcare_entitlement_total_per_child, so the fit and the calibration now sit on the engine's own basis. No row reads current_education. That is the right design.
• So reception and 9-11-month-olds are now handled in the engine. In the reform, a 4-year-old keeps only the summer term, and children aged 9-11 months are funded from the next term.
• 2.148.3 has since fixed months_since_last_birthday differing between a simulation and the frame it exports and loads back. The release carries the column (it is on the export surface, and the a858c100 file has it), so this should not bite. It is still worth taking in at the next re-lock.

Release

There is no new release since a858c100. The dataset repo has two staged calibration attempts from 23 October, but nothing has been published, so I have no new aggregates.

What I ran (and what I didn't)

• Fresh worktree at 829c1bc26 (based on main 8b0224e06), uv sync --all-packages --locked --extra uk.
• Every test file this PR adds or changes, engine and engine-free: 954 passed, 6 skipped. tools/ci_test_plan.py verify: ok. CI at this head: all ten checks green.
• policyengine-uk 2.147.2 single-child households to map age on 6 October to DfE age (finding E).
• DfE Education provision: children under 5 years of age, January 2025, for finding D and the take-up rates.
• I read dfe_spring_term.py, the frs_take_up.py diff, the copies' under-2 re-draw (keyed on the copy's own person_id and its own unit's re-drawn flag, which is right), and the v6 receipts.
• I did not read the regenerated pins, manifests or fixtures beyond the tests that check them.
• Not run: no build or refit, and no dashboard rerun. The figures in E, G and H come from the committed receipts and DfE's published tables.

What looks right

• The spring-term measure is careful: it checks the engine's term dates, treats the term share as a float, and counts each child under one DfE entitlement.
• The estimand and at-bound reason on every v6 rate. They make the corners readable without the code.
• The copies' re-draw extends cleanly to the under-2 draw, with a guard against duplicate person ids.
• Signing out the age-4 cells, and the reasons for each signed-out cell in the accounting note.
• Disclosure: national targets and metadata receipts only, and the realised take-up tool reads "<10" for thin cells.

🤖 Generated with Claude Code

[juaristi22]

@vahid-ahmadi Thanks for round 3. E is fixed on this branch (a12885f), and the build results below answer F–J. The national file from 829c1bc is certified and published to the inspect lane: cut tag microcosm-uk-2024-25-national-20261023T075039Z-a133f37a, not promoted to latest. That file predates the E fix; the next build from main carries it.

E. The under-2 draw is keyed on DfE age.

• dfe_spring_term.dfe_age_at_31_december restates the engine's date of birth (birth_instant_from_age, then grid_months_to_yyyymmdd) in numpy, because the build stages run without the engine. It gives the DfE age from the stored age and months since the last birthday.

• On the fit spine it matches the engine's 2025 - birth_year for every person. A new engine test holds it to policyengine-uk at 2024–2026, including the 7 October boundary.

• frs_take_up (and so the copies, the take-up signal gate and the realised-take-up report) draws each child at its DfE age's rate. A child of whole age 1 born from 7 October is a 2-year-old to DfE and is no longer drawn.

• Fitter tool version 7 splits the under-2 contributions by the same DfE age. Refit on the same fit spine:

  Rate or row	v6	v7
  Under-2 usage, DfE age 0	0.698	0.6962
  Under-2 usage, DfE age 1	1 (bound)	1 (bound)
  Working parent	0.8361	0.8262
  Early learning for 2-year-olds	0.6547	0.6551
  Tax-Free Childcare	0.9697	0.9697
  Row: 9 to 11 months	1.015	1.000
  Row: age 1	0.894	0.943
  Row: working parent 2 to 4	1.011	0.999
  Row: universal-only	1.065	1.052

  The age-1 rate stays at its bound, but the shortfall roughly halves, as you expected. On the certified file, the children born October–December 2024 whom the age-0 rate left without hours came to about a tenth of the age-1 row.

• The take-up signal gate's note in gates.json still says "whole-year age". Rewording it would move the gate pins that the published certificate is checked against. It changes with UK #1334: draw UC take-up by award band, and measure the HMRC income rows over each person's year #1344's re-pin, which moves those pins anyway.

F. Census year. Agreed: binding January 2025 sets where the file lands. The table under G shows the gap to January 2026 for every row, from the January 2026 facts already in the pinned feed. Moving the binding rows to January 2026 is a follow-up; until then this table is the comparison.

G. Realised rows by DfE age after calibration (certified file, England, final weights, spring term of 2025-26; nearest 100):

Row	Model	DfE Jan 2025	DfE Jan 2026
Working parent 9 to 11 months	29,100	29,155	30,679
Working parent age 1	195,500	195,104	210,825
Working parent age 2	242,700	242,453	260,238
Working parent age 3	279,100	278,640	278,490
Working parent age 4 (signed out)	100,400	100,389	110,251
Working parent 2 to 4	622,300	621,482	648,979
Universal nursery age 3	566,500	565,954	535,209
Universal nursery age 4 (signed out)	210,600	210,040	216,113
Universal-only	397,600	396,965	362,581
Early learning for 2-year-olds	95,000	95,031	85,629

• January 2026 at ages 3 and 4 comes from DfE's CSV in the feed. Universal-only for January 2026 is derived (751,322 − 388,741), since DfE does not publish it.
• Against January 2026: working parent at 9 to 11 months, 1, 2 and 4 is 5–9% low and age 3 matches; universal nursery age 3 is 6% high, and early learning for 2-year-olds and universal-only are about 10% high.

H. Working-parent eligible pool by DfE age (every family claiming, before school in the spring term, England, final weights; nearest 1,000):

DfE age	Model	DfE estimate Jan 2025 / Jan 2026
1	261,000	283,000 / 278,000
2	316,000	297,000 / 283,000
3	309,000	312,000 / 297,000
4	110,000	123,000 / 128,000

• DfE age 0 is withheld under the small-cell rule, because it could be differenced against the 9-to-11-months row.
• Your round-1 question stands at age 1: after calibration the pool is 6–8% under DfE's estimates, where you estimated a fifth before calibration.

I. Fixed in the body. The January 2025 release gives 42% at 9 to 11 months and 70% at age 1. The 44% and 69% I quoted are the 2026 release's revision of January 2025.

J. Named in the body, beside the universal and 2-year-old rows. Until PolicyEngine/policyengine-uk#2588 lands, those measures count children born from 7 October to 31 December, whom the engine does not fund that year. So calibration partly meets DfE's counts with children who cost nothing in the model, and universal and targeted spend come out a little low.

The build (829c1bc):

• Certification: all 19 release-cut gates pass.

• Calibration: every DfE childcare row and both HMRC Tax-Free Childcare rows land within ±0.2%; 99.1% of all rows are within 10%.

• Head-to-head: against the promoted 6cba5d71 the loss is 0.038 against 0.080 (855 rows won, 403 lost). Against a858c100 it is 0.038 against 0.077 (817 won, 441 lost). Both win every DfE row (8/0) and both TFC rows.

• Realised take-up at final weights (benefit units with a child under 5):

  Flag	Contract	Realised	Pay over £100k
  Tax-Free Childcare	0.970	0.969	0.994
  Working parent	0.836	0.852	0.889
  Early learning for 2-year-olds	0.655	0.644	0.613

  Universal take-up equals working-parent take-up, since the conditional rate is 0. Natives and copies differ by under 0.04 on every flag.

Other points.

• 2.148.3 (months_since_last_birthday round trip): noted for the next re-lock.
• G nit: the universal rate's at_bound_reason now says why it sits at 0: the working-parent flag is drawn for every unit, so no family's universal take-up falls below it.

Could you take one more look at the E commit? The dashboard rerun on the published file goes on #8.

🤖 Generated with Claude Code