Tracking: Reconciliation migration epic — execution checklist

[Polichinel]

Epic: #31

Checklist of every issue in the recommended execution order — cross them off as the epic progresses. Slice 1 (the numpy leaf + bit-exact parity) is already done in PR #30.

Order of execution

• Capture the offline parity oracle + decide the country↔grid id system #32 — Capture the offline parity oracle + decide the country↔grid id system · planning needs-decision
• CM/PGM → PredictionFrame adapters #33 — CM/PGM → PredictionFrame adapters · implementation
• Country↔grid grouping core via cross_level_align #34 — Country↔grid grouping core via cross_level_align · implementation
• Frames-native reconciliation validation guards #35 — Frames-native validation guards · implementation
• ReconciliationModule orchestration (numpy-native; drop wandb + multiprocessing) #36 — ReconciliationModule orchestration; drop wandb/multiprocessing · implementation
• End-to-end reconciliation parity gate vs frozen views-reporting #37 — End-to-end parity gate · testing
• CIC for ReconciliationModule + migration docs #38 — CIC + migration docs · documentation
• Wiring: expose reconciliation API + pipeline-core ensemble repoint #39 — Wiring / pipeline-core repoint · implementation blocked
• Phase out reconciliation in views-reporting (closes views-reporting#72) #40 — Phase out reconciliation in views-reporting (closes views-reporting#72) · implementation blocked

Dependency graph

#32 → #33 → #34 ┐
              #35 ┘→ #36 → #37 → #39 → #40
                     #36 → #38

#34 and #35 both depend on #33 and can proceed in parallel; #36 joins them. #38 (docs) can run alongside #37. #39/#40 are cross-repo and gated on parity.

Done when

All boxes checked, epic #31 acceptance criteria met, views-reporting#72 closed, and C-37 (principled-algorithm upgrade) handed to its follow-on epic.

[Polichinel]

Progress: S0–S6 done and on PR #30 (the in-repo migration). The frames-native ReconciliationModule is end-to-end parity-proven (bit-for-bit vs the frozen oracle), numpy-only. Remaining: S7 (#39) pipeline-core repoint and S8 (#40) views-reporting phase-out — both cross-repo and blocked until #30 merges. C-37 (principled-algorithm upgrade) handed to its follow-on epic.

[Polichinel]

In-repo migration merged. S0–S6 (#32–#38) are done and merged to development in PR #30 (the leaf, cm/pgm adapters, cross_level_align grouping, validation, ReconciliationModule + CIC; bit-exact parity; scale-ready after C-38).

Remaining:

• S7 (Wiring: expose reconciliation API + pipeline-core ensemble repoint #39) pipeline-core repoint — ON HOLD pending a design discussion (the pipeline-core change will be decided with the team first).
• S8 (Phase out reconciliation in views-reporting (closes views-reporting#72) #40) views-reporting phase-out — blocked on S7.
• C-37 (sample-alignment precondition) and the C-38 memory residual are the documented S7 entry-gates.

[Polichinel]

Cross-repo: the pipeline-core side of S7 (#39) is now planned as a full epic — views-platform/views-pipeline-core#193 (tracking: views-platform/views-pipeline-core#199). Key findings there: the live reconciliation path is point-only (pgm_cm_point), so C-37/C-38 are de-risked for production; and there's a dependency-direction (ADP) decision to settle since views-postprocessing already depends on pipeline-core. Per your instruction, no pipeline-core code is being touched — just the plan.

[Polichinel]

Update 2026-06-24 — reframe. Slices #32–#38 done (the in-repo reconciler, already probabilistic-ready). Remaining is cross-repo, now two tracks:

• B1 point repoint + views-reporting removal (Wiring: expose reconciliation API + pipeline-core ensemble repoint #39/Phase out reconciliation in views-reporting (closes views-reporting#72) #40 → views-reporting#72).
• B2 NEW: probabilistic reconciliation on pipeline-core's PredictionFrameEnsembleManager (the UN deliverable — new pipeline-core issue under #193, gated on C-37, honor C-38).

FAO / rusty_bucket is independent (no reconciliation). Plus a new this-repo issue: the unfao delivery path is point-based and must be adapted to carry rusty_bucket's pooled draws.