Which enhancements act at which processing-chain stage

Generated from arrayprobe_enhancements.registry (each module's declared stage) and .pipeline (which are wired to the automatic driver); never hand-typed. Rebuilt by the documentation build.

The chain (09-conventions.md): decode (raw binary to per-record images) -> framing, imgProc_sm (images to a proc file) -> size distribution, sizeDist (a proc file to an sd file) -> combine (a flight's sd files to one product) -> an optional post-combine export. Two workflows hang off this spine rather than sitting on it, and are the model for "when does this become relevant":

• Diode testing. The diode report, arrayprobe.diode_report.report_from_files(decode, proc), needs a first decode-and-framing pass to already exist – a stuck diode is invisible per particle and only shows up at flight scale. A confirmed mask then drives a second decode-and-framing pass, with the diodes declared in [run].diode_masks, which writes a separately-named masked output. Automatic stuck-bit repair from the report itself is not built.
• Inter-arrival work. arrayprobe intarr-threshold reads an existing proc file and writes the threshold file that sizedist (the size-distribution stage) optionally consumes as its twelfth argument – the threshold is derived before the stage that uses it, not computed inside it.

See also Enhancements · Which enhancements apply to which engine · User guide for the commands themselves · All-on sets, per probe and engine.

UIOOPS enhancements (arrayprobe-uiops-enhancements), by stage

42 modules, each declaring one stage in arrayprobe_enhancements.registry. arrayprobe run --enhancements (enhancements_uiops/src/arrayprobe_enhancements/pipeline.py) applies 13 of 42 automatically once its [enhancements] table resolves them ON; the rest need the reason column below read before they do anything.

How to read the tables. Each row carries at most two tags:

• auto – arrayprobe run --enhancements applies it once its [enhancements] table resolves it ON. Nothing more to do.
• manual – the driver skips it; call the module yourself. The Why manual column quotes the driver's own skip reason.
• needs work – manual only because a piece is not built yet: the driver's reason is its generic no driver adapter yet or no entry_point.
• stated limit – manual for a reason the driver names (decode-time, no file stage, or a module-specific reason such as an analysis that writes no corrected file); read Why manual.

Each Finding is the title of the defect the module corrects, as recorded in the review of the UIOOPS or SODA-2 source; — means it corrects no recorded defect.

The decode stage (raw binary to per-record images)

Replaces the decode itself. Cannot be bolted on after the decode stage has already written its file – there is nothing post hoc to correct, because the particles it would recover were never decoded. A user reaches these by running the corrected reader directly, or via a raw-format reader override; arrayprobe run --enhancements records them as skipped with a reason naming the correction, never silently drops them.

The framing stage (imgProc_sm, per-record images to a proc file)

Acts on a proc file (or the per-particle image array the framing stage holds in memory while building one). Relevant once the framing stage has run at least once – the diode workflow's first pass is exactly this file.

The size-distribution stage and the combine step (sizeDist, a proc file to an sd file, then a flight's sd files to one combined product)

Acts on an sd file, or on a value the size-distribution stage (sizeDist) itself reads or computes – including a flight's already-combined product, which EnhancementSpec.stage's own docstring folds into this same value. Relevant once the size-distribution stage has run, or, for the inter-arrival modules, once a threshold file exists to feed the size-distribution stage's optional twelfth argument.

post-combine (an export or copy of an already-written port output file)

Acts on a finished port output file, any stage's. Relevant last, once there is a file to export or restructure.

no file stage (a reference table or pure function)

No proc/sd/product file to act on – a lookup table or a function that takes call arguments the run configuration supplies rather than anything read from a file.

SODA-2 corrections (arrayprobe-soda2-enhancements) – no per-stage split

19 modules. SODA-2 is a single processing lineage with one source tree, not staged decode/imgProc/sizeDist/combine like UIOOPS – arrayprobe_soda2_enhancements.registry's own docstring gives the reason there is no engine matrix, and the same fact means there is no stage matrix either: a correction here applies or it does not, judged by reachability (live/latent/flagged, the SODA-2 review's own classification of how often the defect fires on real data), not by where in a chain it sits.

How to read this table. The same tags as the UIOOPS tables, read from arrayprobe_soda2_enhancements._adapter's ROUTES and NOT_ROUTED:

• auto – arrayprobe soda2 run substitutes it for the port function it corrects once it resolves ON (SODA-2 corrections are opt-in, except the five in registry.PROTECTIVE, which run by default because SODA-2 has no archived product); the run's .pbp.call sidecar records it as applied.
• manual stated limit – the adapter names why it cannot substitute it, and Why manual quotes that reason. Call its entry point yourself.
• manual needs work – no entry point, or no adapter decision yet.

Reachability is the SODA-2 review's own classification of how often the defect fires on real data. Each Finding is the title of the defect, as that review records it.