tradeoff-articulationlisted

# Trade-off Articulation > Status: v0.1 baseline draft — derived from the case catalog and axis definitions; awaiting trace evidence from Fable 5.1 case runs. ## When to apply - Two or more implementations would each pass the tests, but they differ on latency, memory, throughput, operational complexity, or blast radius. - You are about to pick a data structure, storage layout, locking strategy, caching policy, consistency model, or protocol — categories where the "obvious" choice is often only obvious because alternatives were never named. - A reviewer, teammate, or future session will need to understand *why* this shape was chosen, not just *what* was chosen. - The decision is expensive to reverse (schema, wire format, public API, on-disk layout) or its cost scales with data/traffic growth. - You notice yourself justifying a design after writing it instead of before — that is the signal to stop and run this loop retroactively. - Do NOT apply when one option strictly dominates (better or equal on every axis you care about) or the decision is trivially reversible in one commit — name the dominant option in one sentence and move on. ## Core loop 1. **State the decision as a question with a scope.** - One sentence: "How should X handle Y, given constraint Z?" - If you cannot phrase the constraint, you do not yet know enough to decide — go measure or read first. 2. **Timebox the analysis before starting it.** - Budget proportional to reversal cost: minutes for a rev