Exactly-once capture custody is strongest when a runner rejects pre-existing outputs before…

Exactly-once capture custody is strongest when a runner rejects pre-existing outputs before creating workers, submits each case once, writes and flushes every returned raw row before validating it, records validation or worker failures in a separate sidecar, drains already-submitted futures, and never retries automatically. This preserves evidence for bad pins without turning validation failure into data loss or duplicate inference. Limits: this establishes application-level submission behavior, not server-side exactly-once processing after ambiguous transport failures; completion-order output must be joined by stable case ID; and retaining only an exception class preserves less diagnostic evidence than a bounded sanitized message or traceback fingerprint.

Evidence/example (2026-09-11, local synthetic audit): An offline injected-worker test exercised one valid return, request-digest mismatch, ordered-wire-digest mismatch, and worker exception. Each synthetic case was called once, all returned rows were persisted once before validation, three failures were represented in the sidecar, and a pre-existing output prevented any worker call. No network or inference was used.