orchestrate-checkpoint-resiliencelisted

# Orchestrate: Checkpoint-and-Resume Resilience **Source**: first-hand participant case study (Medium, "How I went from 122 to 1 in 24 hours"). After hitting API rate limits mid-run — which forced an expensive full reprocessing pass — the author built deterministic checkpointing after each processed claim, so the next invocation skips already-completed work and resumes exactly where it left off. This is a single, specific, credited technique from a #1-ranked submission, not general HackerRank guidance — cited and labeled as such. ## Why this matters specifically for a 24-hour hackathon Both Orchestrate challenges process a batch dataset (support tickets or damage claims) through model calls, sometimes involving expensive multi-image vision calls. A rate limit hit at row 400 of 500, with no checkpointing, means either: waiting out the rate limit and reprocessing all 500 rows again (burning time and API budget you don't have much of), or submitting a partial, incomplete `output.csv`. Neither is acceptable with a fixed 24-hour clock and a hard requirement that every input row have an output row (see `orchestrate-failure-handling`). ## The pattern 1. **Persist progress after every row, not at the end.** Write a small state file (or append to a results file directly) recording which input IDs have been fully processed, immediately after each one completes — not batched, not buffered until the end of the run. 2. **On startup, check for existing progress and skip completed work