critical-curves: decision toward JAX zero-contour in modeling viz + feasibility task

campaigns.yaml

@@ -157,14 +157,15 @@ campaigns:
   evidence: https://github.com/PyAutoLabs/autofit_profiling/issues/4
 - id: critical-curves
   title: Critical curves and evaluation grids
-  status: needs-decision
-  updated: '2026-11-06'
-  next: 'No new campaign measurement. Phase 3b cap fix remains shipped; project wiki still incorrectly says #646 awaits
-    merge/release. Seed coverage and path completion remain unresolved; retain marching-squares decision and ask the
-    human whether to scope the next phase. Check-in 2026-10-17: no project wiki/results/issue change since 2026-10-13
-    beyond autolens_profiling#420/#422/#424 (interferometer only); releases 2026.10.16.1/.2 and 2026.10.17.1 supply
-    no new measurement. Check-in 2026-11-06: no campaign measurement. Adjacent: PyAutoLens#808 (cluster plot_critical_curves/plot_caustics
-    now read general.critical_curves_method). Still needs a human decision on whether to scope the next phase.'
+  status: active
+  updated: '2026-11-06'
+  next: 'Human decision 2026-11-06 (chat): move toward the JAX zero-contour engine for critical curves in modeling-run
+    visualization, starting with a feasibility phase ("or doing work to figure out if its feasible"). Next bounded
+    step: task critical_curves_jax_modeling_viz_feasibility (correctness on posterior draws per scale against the
+    pre-registered two-pixel rule, cold/warm cost per visualization call on CPU and A100, cheap incomplete-curve detection
+    and marching-squares fallback; GO/NO-GO per scale). No default changes until a later phase. Prior: phase 3a cluster
+    NO-GO for default seeds (autolens_profiling#364); phase 3b cap fix PyAutoGalaxy#646; PyAutoLens#808 cluster plots
+    read critical_curves_method.'
   evidence: https://github.com/PyAutoLabs/autolens_profiling/blob/4db4d988e520a82219152743748c3188d485a4ba/wiki/campaigns/critical_curves.md
 - id: certified-solver
   title: Certified positive solver
@@ -591,3 +592,14 @@ tasks:
     Still parked.'
   issue: https://github.com/PyAutoLabs/PyAutoArray/issues/629
   evidence: https://github.com/PyAutoLabs/PyAutoArray/pull/637
+- id: critical_curves_jax_modeling_viz_feasibility
+  campaign: critical-curves
+  title: 'Feasibility: JAX zero-contour critical curves and caustics in modeling-run visualization'
+  status: ready
+  priority: medium
+  path: tasks/critical_curves_jax_modeling_viz_feasibility.md
+  updated: '2026-11-06'
+  next: Filed 2026-11-06 (human decision). Research only, no default change. Issue through start_dev (autolens_profiling,
+    with a Mind prompt referencing this task) when prioritised; uses the phase-4 posterior draws (autolens_inference#59)
+    as the correctness corpus.
+  evidence: https://github.com/PyAutoLabs/autolens_profiling/pull/364

dashboard.md

@@ -1,6 +1,6 @@
 # PyAutoPulse — profiling dashboard
 
-<!-- pulse-campaigns:10bb316908e8807a27bae7d29a3b5e07a08acc4900cd75a3fe6c9890a72c8f4e -->
+<!-- pulse-campaigns:b371fb8025668c6fa7dc5615aa826c8ef33c13d92435224ac399cc8b08988069 -->
 ## Profiling Check In
 
 <details><summary>Full check-in prompt</summary>
@@ -149,14 +149,15 @@ Reviewed 2026-11-06. B4a (autofit_profiling#3) and B4b (autofit_profiling#5, iss
 
 </details>
 
-<details><summary>Critical curves and evaluation grids — needs-decision</summary>
+<details><summary>Critical curves and evaluation grids — active</summary>
 
-Reviewed 2026-11-06. No new campaign measurement. Phase 3b cap fix remains shipped; project wiki still incorrectly says #646 awaits merge/release. Seed coverage and path completion remain unresolved; retain marching-squares decision and ask the human whether to scope the next phase. Check-in 2026-10-17: no project wiki/results/issue change since 2026-10-13 beyond autolens_profiling#420/#422/#424 (interferometer only); releases 2026.10.16.1/.2 and 2026.10.17.1 supply no new measurement. Check-in 2026-11-06: no campaign measurement. Adjacent: PyAutoLens#808 (cluster plot_critical_curves/plot_caustics now read general.critical_curves_method). Still needs a human decision on whether to scope the next phase.
+Reviewed 2026-11-06. Human decision 2026-11-06 (chat): move toward the JAX zero-contour engine for critical curves in modeling-run visualization, starting with a feasibility phase (&quot;or doing work to figure out if its feasible&quot;). Next bounded step: task critical_curves_jax_modeling_viz_feasibility (correctness on posterior draws per scale against the pre-registered two-pixel rule, cold/warm cost per visualization call on CPU and A100, cheap incomplete-curve detection and marching-squares fallback; GO/NO-GO per scale). No default changes until a later phase. Prior: phase 3a cluster NO-GO for default seeds (autolens_profiling#364); phase 3b cap fix PyAutoGalaxy#646; PyAutoLens#808 cluster plots read critical_curves_method.
 
 [Campaign evidence](https://github.com/PyAutoLabs/autolens_profiling/blob/4db4d988e520a82219152743748c3188d485a4ba/wiki/campaigns/critical_curves.md)
 
 ### Active tasks
 
+- [Feasibility: JAX zero-contour critical curves and caustics in modeling-run visualization](https://github.com/PyAutoLabs/PyAutoPulse/blob/main/tasks/critical_curves_jax_modeling_viz_feasibility.md) — ready: Filed 2026-11-06 (human decision). Research only, no default change. Issue through start_dev (autolens_profiling, with a Mind prompt referencing this task) when prioritised; uses the phase-4 posterior draws (autolens_inference#59) as the correctness corpus.
 
 </details>
 

tasks/critical_curves_jax_modeling_viz_feasibility.md

@@ -0,0 +1,39 @@
+Filed: 2026-11-06 (human decision in chat: "I think making critical curve thing use JAX for modeling runs with visualization makes sense to me" … "or doing work to figure out if its feasible")
+
+# Feasibility: can the JAX zero-contour engine draw critical curves and caustics during modeling-run visualization?
+
+Type: research
+Target: autolens_profiling
+Repos:
+- @autolens_profiling
+- @PyAutoGalaxy
+- @PyAutoLens
+Themes:
+- critical-curves
+- visualization
+- jax
+Difficulty: medium
+Priority: medium
+Campaign: critical-curves
+
+## Question
+
+Modeling runs draw critical curves and caustics on fit figures: in `fit_imaging_plots`, at quick-update and stage-end visualization. Today that uses `marching_squares` (`visualize/general.yaml: critical_curves_method`). PyAutoGalaxy already wires a JAX engine, `zero_contour` (`jax_zero_contour.ZeroSolver`, in `LensCalc.*_via_zero_contour_from` and `plot_utils._critical_curves_method`). Is `zero_contour` **correct and cheaper** for modeling-run visualization, at which scales, and with what seed policy and fallback?
+
+## Evidence so far (this campaign)
+
+- Phase 3a (2026-10-02, autolens_profiling#364): NO-GO for blindly routing *cluster* plots to zero-contour. The default ±3″ automatic seeds missed both cluster tangential curves, and an explicit far-source curve had a 20.65″ closing chord (path not completed). Galaxy-scale was not the subject.
+- Phase 3b: the evaluation-grid cap preserves the field (PyAutoGalaxy#646).
+- PyAutoLens#808: cluster plotting reads `critical_curves_method`.
+- Docs drift: PyAutoGalaxy `plot_utils` docstrings call `zero_contour` the default, while the config default is `marching_squares`.
+
+## Feasibility phase (bounded, research only, no default change)
+
+1. **Correctness corpus.** The lifecycle day-zero datasets per scale: galaxy (imaging/hst, interferometer/sma), multi_galaxy/hst, group/euclid, cluster/simple, plus the phase-3a cluster witness. Evaluate on posterior draws from the phase-4 modeling runs (autolens_inference results), not only the truth, because modeling-run figures show fits away from the truth. Apply the pre-registered rule: every reference component found, each within two fine-grid pixels (0.1″ galaxy control, 0.25″ cluster), paths closed. Report seed coverage and path completion per scale.
+2. **Cost in the modeling-run context.** Per-visualization call, both cold (including compile) and warm: marching squares (NumPy grid, and the JAX grid where used) against zero-contour, on CPU and A100, at the visualization cadence of a real run. Report the compile cost amortised over a run's visualizations, not just a single warm call.
+3. **Failure detection and fallback.** Can an incomplete or missed curve be detected cheaply (e.g. curve count against the marching-squares coarse grid, closure check), so a fallback to marching squares is automatic?
+4. **Outcome.** GO / NO-GO per scale, a recommended default plus seed and fallback policy, and the docs-drift fix. Any library or config change ships as its own later phase via start_dev.
+
+## Notes
+
+- Visualization cost only matters if it's a noticeable share of a modeling run's wall. The phase-4 walltime rows (autolens_inference#59) and the quick-update plotting cost task give the denominator.