Repository navigation
Evaluate Smokescreen; write adoption PRD if it holds up #234
Description
Activity
- added a parent issue
on Jul 7, 2026 Smokescreen (DESC; JOSS, arXiv:2604.18111) implements Muir et al. (2020) data-vector blinding: draw a hidden cosmological-parameter shift, compute the theory data vector at fiducial vs. shifted cosmology, apply the difference to the measured vector — noise and covariance untouched. It is
saccin,saccout, with theory delegated to a firecrown likelihood'scompute_theory_vector(). It ships the discipline layer: string→seed hashing, encrypted storage of the original vector, multi-blind bookkeeping. In use by LSST DESC; validated externally on a KiDS 6×2pt setup.Verdict
Adopt. The shift arithmetic is trivial either way — what we're buying is a battle-tested implementation of the one module where a silent bug can unblind or corrupt the analysis, plus community trust: "we blind with the DESC tool LSST and KiDS use" needs no further defense. Reimplementing means owning the design, testing, and credibility of bespoke blinding code — the wrong side of the trade. If firecrown ever genuinely limits us, the package is small and forkable.
What adoption requires
sp_validation today has no sacc and no firecrown; inference is CosmoSIS+CAMB fed by 2pt-FITS builders. So:
- sacc as data-vector container — rewrite the per-statistic FITS builders as sacc builders (mechanical). Independently worthwhile: sacc gives us interchange with other surveys and a COSEBIs format (
galaxy_shear_cosebi_ee/bbare standard types), which we currently lack entirely. - A firecrown
TwoPointlikelihood over ξ±/Cℓ — needed only inside the blinding box, not for sampling. CosmoSIS+CAMB inference is untouched: a small sacc→2pt-FITS shim feeds2pt_likeas today. - Version pins — Smokescreen has chased firecrown API breaks; pin smokescreen/firecrown/sacc/pyccl as a set.
- Theory cross-check — compare CAMB (sampler) vs CCL/firecrown (blinding) predictions once on our exact binning. Cheap, and wanted regardless.
COSEBIs
Nothing in the DESC stack predicts COSEBIs, but nothing needs to (cf. #233): we blind the raw ξ± and Cℓ and derive blinded COSEBIs, which are linear functionals of ξ±. Same structure makes B-mode tests transparent to the blind (a theory-difference shift is pure E-mode). One requirement: evaluate the shift as a smooth function on a fine θ grid, not on coarse data bins. Acceptance test (agreed with Sasha): verify on mocks that B-mode estimators are unchanged by the blind.
Risks
- Discipline is social, not cryptographic — anyone with the seed can recompute the shift. True of any scheme; the PRD defines key custody.
- firecrown API churn — pin; worst case, fork.
- Shift-grid fidelity for derived COSEBIs — the mock test catches it.
Proposed path
- This evaluation as a comment here → collect objections.
- Short PRD: sacc adoption, Smokescreen insertion point, key custody, CAMB↔CCL cross-check, B-mode mock test.
- Draft PR wiring the minimal loop: ξ±/Cℓ → sacc → Smokescreen → shim → existing CosmoSIS chain.
— Claude (Fable) on behalf of Cail.
- sacc as data-vector container — rewrite the per-statistic FITS builders as sacc builders (mechanical). Independently worthwhile: sacc gives us interchange with other surveys and a COSEBIs format (
@sachaguer tell me if you have any comments, next i'll open a issue with a concrete PRD which we can then divide into several PRs
It sounds good to me. We will have to regularly update each other and @LisaGoh about the evolution of this. We could quickly be stuck at the junction cosmo_val/smokescreen and smokescreen/CosmoSIS. Good communication should make this transition more fluid. We should also update the team regarding this strategy.
PRD posted as #241 — comments there please. Notable deltas from the evaluation above: SACC lands at measurement time (fine-θ ξ± is what gets blinded, COSEBIs derive from it), ρ/τ ride along as custom SACC types (unblinded), and #228 resolves itself (every consumer normalizes n(z) internally). Draft implementations of the proposed PRs will follow once the PRD settles.
— Claude (Fable) on behalf of Cail.
Done: the evaluation landed and the adoption PRD is #241 (agreed in principle; implementation under way in its sub-issues). Smokescreen held up, with the caveat that we fork it (UNIONS-WL/Smokescreen#1) for theory-backend independence.
— Claude (Fable) on behalf of Cail.
From the 2026-07-07 tomography call (notes): take a close look at the Smokescreen code and report — how well-built is it, what would the SACC data-vector switch cost, can it be integrated without becoming a workflow blocker. If it holds up, write a PRD for adopting it (covering rules for what may be done with the catalogue while blinded, and pipeline automation so blinding needs no external person in the loop).