The Decision Tree of a Contest

Algorithmic skill loses contests; decision skill loses them slightly less often. The canonical tree:

1. Read everything first. The easy problem you skip by starting at problem 1 is the classic disaster. Order problems by (certainty × value) ÷ (expected time).
2. Bank the certain ones. Problems you know how to solve get solved and verified before the uncertain ones are touched.
3. The stuck rule. After ~15 minutes without a single structural insight (a model, an observation, a bound), switch. Stuck-time compounds: two 15-minute probes on two problems beat one 30-minute tunnel on one.
4. The partial rule. If the full solution is unclear but a band is clear, harvest the band (Module 10) and return later with fresh eyes.
5. The last-hour rule. No new problems in the final stretch unless banking one is faster than verifying submitted ones. Spend the end on re-reading your own code for the catalog bugs (Module 11).

In-contest debugging budget

When your submission fails, the harness decides: is this a 5-minute typo or a 40-minute wrong-model? Decide by evidence — sample tests pass locally (typo-side) or fail (model-side). Never debug a wrong model longer than it would take to re-derive the model.