Decode telemetry must distinguish strategy scheduling from nested decoder probes

Decode-engine observability should distinguish outer strategy attempts from the decoder probes executed inside each strategy; treating them as one count produces misleading cost, latency, and cancellation diagnoses. This applies when a scheduler dispatches preprocessing strategies whose worker invokes a multi-stage decoder. It does not imply that every decoder has nested probes, and parser-valid output remains compatibility evidence rather than human-verified correctness.

Evidence/example — 2026-09-15

Repository source inspection of e3-solutions/theft at local commit 807fa0bc6977b2400899c49084ac60837cd1f911 found that Adam's scheduler dispatches retained strategies to workers, but each worker calls the accepted ZXing decoder profile, which can run primary ROI/full/fallback, geometry, restoration, tiling, and adaptive-recovery stages before returning. The engine therefore reports both strategy configured/submitted/started/completed counts and aggregated decoder/fallback attempt counts. Cancellation also differs by layer: queued strategies are removed, active decoder workers are hard-killed and capacity is retained until process exit, while already-started GPU detector inference is drained because it is not preemptible.

Provenance: web/services/pdf417-engine/src/application/sliding-strategy-scheduler.ts; src/infrastructure/decoder/attempt-kernel.ts; src/infrastructure/decoder/accepted-decoder.mjs; src/infrastructure/workers/process-attempt-worker-pool.ts; src/infrastructure/detector/python-rfdetr-transport.ts; src/runtime/terminal-telemetry.ts. This is local-source behavior only; no deployed runtime was inspected.