Triage cannot settle whether an unfamiliar requirement is easy or hard inside the spike's timebox — what do you commit to?

## Triage is timeboxed on purpose Classifying an unfamiliar requirement can consume an afternoon or a fortnight, and the value curve is steep at the start and flat afterwards. The first pass buys most of what is available: a skeleton, a candidate match, the restrictions the requirement might carry. After that you are doing research, and research is a decision a lead makes deliberately, not something a spike drifts into. So the real question is not "how do I finish the triage" but "what do I commit to with an unfinished one". ## The two wrong calls are not symmetric | Wrong call | How it fails | When it is discovered | Cost to reverse | |---|---|---|---| | Called routine, actually hard | The method stops finishing as inputs grow | Late, under real data, after commitments | High: rewrite plus a schedule already promised | | Called hard, actually routine | Approximate answers shipped where exact ones were available | Often never | Low technically, but the quality loss persists unnoticed | The first failure is louder and more expensive, which is why an unresolved triage must never default to it — and defaulting is exactly what happens when nobody says the word *unresolved*, because estimates are written as though the work were ordinary. The second failure is cheaper but more insidious: an approximation that nobody revisits becomes the permanent behaviour of the product, and the free exact answer is never reclaimed. ## Buying evidence cheaply inside the box 1. **Build a brute-force oracle.** An exhaustive method on small instances is quick to write, and comparing it against a candidate approach tells you whether the approach is even correct before you argue about its cost. 2. **Measure the growth, not the runtime.** Run representative data at several sizes and look at the shape of the curve. A cliff between two adjacent sizes is worth more than any classification argument in the room. 3. **Ask the requirement, not the algorithm.** Does the business need the optimum, or a defensible answer produced consistently? A large share of triages dissolve here, because the hard version was never required. 4. **Hunt one restriction.** Ask whether the input is always tree-shaped, always two-valued, always small in the one dimension that matters — and whether that is guaranteed or merely current. ## What to commit to when it stays open - **A boundary.** Put the solver behind an interface so the implementation can be replaced without touching callers. This is the cheapest insurance available and it costs nothing if the verdict turns out to be routine. - **A guard, not a hope.** Reject inputs beyond the size you have measured, with a clear error. An unenforced assumption disappears at the next requirement change. - **A named risk.** Record what is unresolved, what would settle it, and who owns settling it. An unowned risk is a rediscovery. - **A staged commitment.** Promise the sizes you have evidence for, and treat the larger ones as a separate decision with its own trigger. ## The part a lead actually owns Engineers can classify; only a lead can decide how much uncertainty the plan carries and who is told. That means making "unresolved" a legitimate, speakable outcome in your team rather than an admission of failure — because the moment it is embarrassing, it stops being reported, and the expensive failure mode becomes the default. It also means resisting the opposite reflex: a team that reaches for approximation at the first sign of combinatorics gives away exact answers that were free, and nobody ever files a ticket about a result that is merely slightly worse than it needed to be.