C vs pure Python parity policy

For classic configurations the pure Python backend aims to reproduce the C extension results on the same inputs.

In scope

  • use_c_extension=False

  • oversample=1

  • stamp_mode="grid" (classic substamps)

Compared products (minimum)

  • Difference image

  • Convolved image / background (as returned by the public API)

  • Kernel solution vector

  • Output mask (exact or documented bit policy)

  • Noise map when part of the returned products

Tolerances should start strict (float32 atol / rtol as appropriate) and only be widened with a written justification per product.

Out of scope (no C twin)

  • oversample > 1

  • stamp_mode="connected_regions"

These modes are validated with their own unit tests and real-data soak runs, not by bit-matching the C grid path.

How we test

  • Synthetic / unit tests under tests/ (e.g. connected-region builders)

  • Real-data comparisons (JWST JADES example data under example/data/ and developer notebooks such as dev/compare_c_vs_pure_jwst.ipynb)

  • A curated fixture pack with C golden outputs is planned before promoting 0.2.0 from development to main

Until that fixture harness lands, treat 0.2.0 on development as staging: suitable for further testing, not yet the default install target.