Resolve

resolve — dissolve a trade-off instead of trading it

A trade-off ("improving A worsens B") is usually handled by picking a point on the curve and tuning. That's right when the curve is fundamental. But often the conflict is an accident of how the thing is built, and a structural change dissolves it — you get both A and B. This skill hunts for that change, and is honest when there isn't one.

Two failure modes it exists to prevent, in priority order:

1. Confabulating a fix on a genuine dead-end — the worst outcome. Never dress up "you have to pick" as an escape.
2. Padding — listing moves that don't really apply to look thorough. Two real resolutions beat six forced ones. A move that only restates the obvious is not a result.

When to use it — and when not

• Use it on a genuine two-sided tension you're stuck on, especially a fresh design where you haven't found the trick yet.
• Skip it when the trade-off is well-charted and only tuning remains — say so and point to ordinary optimization. Ceremony on a mature curve loses to plain reasoning.

The descent

1. Name it. State "improving A worsens B" and name the single element E that carries both. If a hard identity binds (e.g. "output bits ≤ input bits", "cost = rate × time"), name it now — it decides later whether a fix is real or just moves the work around.

2. Sharpen. Rewrite as "E must be both X and not-X" — concrete and opposite. This is where the reframe lives. Keep it to one line; it's scaffolding, not the deliverable.

3. Look for the escape. Scan these; write down only the ones that genuinely fit, one line why for each. For any that don't apply, a single "space: n/a — nothing varies by location" is enough. Do not manufacture a candidate to fill a box.

• Separate in space — E is X in one place, not-X in another (path, region, instance).
• Separate in time — E is X now, not-X later (phases, staging, precompute; or hide the cost by batching/pipelining). A real later phase, not a reordered single pass.
• Separate on condition — E is X when C holds, else not-X: route by a runtime signal or a threshold on the shared metric (prefer that over a fixed class — it keeps the headline behavior universal).
• Separate whole-vs-parts — decompose the requirement itself: the whole is X, each part not-X (per-key, per-tier, per-segment). Also cut on the unit: can a cohort/aggregate guarantee replace the per-instance one (infer per cohort, not per user)?
• Reparameterize (the highest-leverage move) — can B be derived as a function of A, or of a signal already present, so the two stop being independent dials? Name the exact relation and the signal it rides on. (e.g. freshness from a content hash, not a tuned TTL.)
• Shrink, don't just route — can the quantity itself get smaller (smaller diffs, cheaper check, fewer touched parts) so the same budget goes further? Often beats a fancy separation.
• Trim — delete a part and show its job survives elsewhere. A fix that adds nothing beats one that adds a component. Run this even when a reparam seems to have swallowed it.

Before you answer

• Divergence check. Ask: what would a sharp expert reach for that this scan missed? Name one resolution from an under-weighted angle, or state honestly that the scan already covers the obvious pass. The whole point of the protocol is to beat the obvious pass — if it didn't, say so.
• Dedup. Two moves that reduce to the same mechanism count as one; name the shared principle and drop the duplicate. Don't list both to pad.
• Price each fix. Name the cost it trades in — the new resource, failure mode, or complexity. A fix with no stated cost is under-examined.
• Residual. State what survives every move — the irreducible core, and whether a regime exists where all fixes fail at once. If a live trade-off remains, name the metric to choose the operating point.

The honesty gate

Your output is valid only if one holds:

• it surfaces a resolution the asker didn't already name, or
• it declares "no clean decoupling — genuine trade-off; here's how to choose," and says why.

Real trade-offs are common; "you have to pick" is a complete, correct answer. For a genuine dead-end:

• State the binding constraint first, before any menu, so the list can't be mistaken for an escape.
• Tag each candidate as "routes around the constraint" or "claims to beat it"; kill any beat-it claim on its own terms or drop it.
• When the limit is a short provable bound (pigeonhole, an accounting identity), skip the full scan — state the bound, show why the escape families fail, give the honest pivot.

Output

• Contradiction: A vs B; element E; the "both X and not-X" line; governing identity if any.
• Resolutions: only the moves that genuinely apply, each tagged (space / time / condition / whole-part / reparam / shrink / trim), concrete, with the cost it trades in.
• Verdict: "these N are worth trying, best = … (cost …)" or "genuine trade-off — the constraint is …; choose by …". Keep the prose plain — model the clarity you'd prescribe.