orchestrate-failure-handlinglisted

# Orchestrate: Failure Handling **Direct evidence**: HackerRank's organizer guidance states plainly — *"Log failed rows. Continue safely when possible. Mark uncertainty when that is the responsible thing to do."* The same post lists **"silent failures"** — letting invalid outputs pass into final results unvalidated — as a named, explicit scoring mistake, alongside **"incomplete testing... don't only inspect successful cases; examine failures and edge cases."* ## The three-part discipline this implies 1. **Log, don't swallow.** Every row that fails — a timeout, a malformed model response after retries exhausted, a missing input file — gets logged with enough detail (row ID, failure reason, timestamp) that you can explain it in the interview without having to reconstruct what happened from memory. 2. **Continue safely, don't halt the batch.** One bad row shouldn't take down the whole run. The processing loop needs a try/except boundary *per row*, not one wrapping the entire batch — a single failure should produce one logged failure and one degraded-but-present output row, not zero output rows for the remaining N-1 tickets. 3. **Mark uncertainty as a first-class output state, not an absence.** When the model genuinely can't determine an answer with confidence, the responsible output is an explicit "uncertain / insufficient evidence" value your schema supports — not a forced guess dressed up as a confident answer, and not a missing row either. ## Why this is scored as archite