Reduce-and-measure before you spend — collapse the problem with the constraints in hand, size the reduced cost, verify the reduction is sound, THEN pick the method

Statement

Before committing real effort — a heavy computation, a broad search, a long proof, an expensive verification — run this gate. It is domain-agnostic: it names only a *goal object*, a *candidate set / cost*, and *constraints in hand*.

1. State the goal object precisely. What exactly are you finding, proving, enumerating, or checking? 2. List the constraints and facts already in hand — bounds, invariants, parity, symmetry, known extremal values, equalities. 3. Collapse, don't just bound. Apply the constraints to shrink the candidate set. Prefer *equalities* and reformulations: an equality pins the object to a small or known class; a bound only trims it. Ask explicitly: *does any constraint force the object into a tiny / already-enumerated class?* 4. Measure the reduced cost — cheaply — before choosing a method. How large is the reduced candidate set? How short is the reduced proof? How cheap is the reduced check? Get a *number* first (a count, a size, an estimate). 5. Verify the reduction is SOUND before trusting it. A wrong reduction gives a fast *wrong* answer — worse than brute force. Prove the equivalence / implication and dual-oracle it (a small independent check). Only a verified reduction may replace the original problem. *(always reason: steps 1–4; be sure: step 5.)* 6. Now pick the method, matched to the measured cost. Small/exact → enumerate or prove directly. Still large → search / sample / heavy compute.

Facts

- The anti-pattern this kills: the *"compute harder / reach for the biggest hammer"* reflex — choosing a method (brute force, heuristic search, a big machine) without measuring the reduced problem first. Reaching for a 360-CPU census when the real candidate set has ~5·10⁵ elements is choosing the hammer before sizing the nail. It also picks the *wrong tool*: we wrote a heuristic annealer to *search* a space that was small enough to *enumerate* — right answer only by luck, wrong method because the space was never sized. - Equality > inequality. The decisive collapse is almost always an equality the object is forced to satisfy (here: 30 edges + min-degree-3 ⇒ every degree exactly 3 ⇒ cubic). Bounds trim; equalities pin. Hunt for the equality. - Measuring is cheap and high-value. A size count often costs seconds and can turn a supercomputer job into a laptop job — or reveal that a "search" should have been an exhaustive enumeration. - Soundness is not optional. The reduction is a *claim*; it earns trust the same way every other claim does (Dual-oracle verification — certify every claimed object by two independent oracles, count-certify exhaustive runs, and scan all prior-art branches before claiming novelty). Speed from an unverified reduction is a trap. - Reduction is the expert's move that a pure derive→verify→compute loop does not produce on its own; this gate is the closest domain-agnostic proxy for it. It is a mechanism, carrying no domain vocabulary — the domain lives in the constraints you plug in.

Related

- Dual-oracle verification — certify every claimed object by two independent oracles, count-certify exhaustive runs, and scan all prior-art branches before claiming novelty — step 5: the reduction itself is verified. - Bisociation (Koestler 1964) — creative insight as the collision of two habitually unrelated frames of thought — a reduction is often a reformulation into a smaller / already-solved frame. - Reduction criterion — separable (and PPT) states obey ρ_A⊗I ⪰ ρ; the eigenvalue cap that killed our CCNR fitness — a case done RIGHT: a known implication collapsed an entire class of separability criteria at once (CCNR/majorization blindness), a 3-line proof instead of a search.