Skip to content

Design Downselection

Procedure — instantiates Coarse-to-Fine Search

Implements the archetype in design work by comparing rough concepts first and investing detailed engineering, prototyping, or testing in the most promising concepts.

Version
v2 · 2026-08-28 · History
Mechanism #
2671
Type
Procedure
Form family
Decision, Gate & Allocation
Solution family
Optimization & Search
Problem family
Decision, Search & Optimization Failure
Problem subfamily
Hidden, Unbounded & Poorly Pruned Search Space
Origin domain
Engineering & Design
Also from
Operations Research
Instantiates
Coarse-to-Fine Search

Design Downselection treats whole concepts as the units of a coarse-to-fine search: it generates a spread of rough alternative designs, compares them cheaply on sketch-level estimates against shared criteria, and then spends the limited engineering, prototyping, and test budget deepening only the concepts that survive the comparison. Its distinctive feature is that the thing being refined is not a point in a parameter box or a candidate in a queue but an architecture — a qualitatively different approach — so the coarse representation is a sketch-and-estimate, and refinement means committing real engineering hours to fewer, better concepts. The whole discipline turns on not over-investing in any one idea before the rough comparison has earned it.

Example

A spacecraft team must choose how a lander touches down on Mars. Early on they deliberately generate divergent concepts rather than one: airbags, retro-rockets on legs, a parachute-plus-crushable-legs stack, a sky-crane that lowers the rover on tethers, and a couple of hybrids. Detailed engineering of all six is impossible on the schedule, so they compare rough: back-of-envelope mass, landed accuracy, terrain tolerance, cost, and technical risk, each concept scored relative to a familiar datum design in a simple decision matrix.

Two concepts dominate the sketch-level trade; the rest are set aside. Only now does the expensive work begin — detailed CAD, subscale drop tests, guidance simulation — and it is spent only on those two, funded from a fixed concept-development budget. As real numbers arrive, the matrix is revisited; if a survivor's landed-accuracy estimate collapses under detailed analysis, a set-aside concept can be pulled back for a second look. The procedure's value is that six architectures were compared for the cost of two, and the two that got real engineering were the two the rough pass said deserved it.

How it works

  • Bound the concept space. Frame the design problem so a set of genuinely distinct concepts can be generated — the boundary of architectures in play.
  • Represent each concept coarsely. Capture every concept as a sketch plus rough estimates against shared criteria, entered in a decision matrix scored relative to a datum.
  • Compare and carry survivors forward. Keep the concepts that dominate the rough trade — ideally more than one — and set the rest aside without deleting them.
  • Refine within the budget. Spend detailed engineering, prototyping, and testing only on survivors, drawn from a fixed concept-development budget; update the matrix as real data replaces estimates.

Tuning parameters

  • Number of concepts generated — breadth of the initial set. More concepts widen the search and lower the odds of missing a good architecture, but dilute the rough-evaluation effort across more sketches.
  • First-pass estimate coarseness — how rough the comparison numbers are. Coarser estimates are faster and keep more concepts in play; finer early estimates decide sooner but cost more and can decide on the wrong precision.
  • Number carried forward — how many concepts survive to detailed work. Carrying two-plus hedges against a wrong early estimate; carrying one is cheapest and most fragile.
  • Budget split — how the fixed development budget divides between generating/comparing concepts (breadth) and engineering survivors (depth).

When it helps, and when it misleads

Its strength is that it refuses premature commitment to a single architecture: it keeps several genuinely different approaches alive at low cost and reserves expensive engineering for the ones a structured rough comparison endorses — the logic of Pugh controlled convergence[1], where concepts are scored against a datum and iterated before one is chosen. It fits engineering, product, and systems design wherever the alternatives are architectures, not settings.

Its failure is a concept killed on a rough estimate that later proves wrong — a false-negative architecture that never got the detailed work that would have vindicated it. Related is matrix gaming: choosing the criteria or weights to justify a concept the team already favors, so the "objective" comparison ratifies a decision instead of testing it. The classic misuse is downselecting to a single concept too early, while the estimates are still too coarse to trust. The guarding discipline is Pugh's own: keep two or more concepts alive through at least one round of refinement, subject the criteria and weights to challenge, and revisit set-aside concepts when a survivor's real numbers disappoint.

How it implements the components

  • search_space_boundary — framing the problem so a set of distinct concepts can be generated bounds the space of architectures under search.
  • coarse_representation — the sketch-plus-rough-estimate decision matrix is the low-resolution model that lets concepts be compared before any are engineered.
  • refinement_step — detailed CAD, prototyping, and testing on survivors is the targeted depth added after the rough pass.
  • evaluation_budget — the fixed concept-development budget governs how much detailed work the survivors can receive.

It runs no explicit re-opening protocol for a wrongly killed concept (false_negative_check, backtracking_path); that audit-and-recover machinery is carried by Search Tree Pruning with Refinement and Diagnostic Narrowing.

Editorial Notes

Form Classification

Form family: Decision, Gate & Allocation

Rationale: Design Downselection operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it implements the archetype in design work by comparing rough concepts first and investing detailed engineering, prototyping, or testing in the most promising concepts.

Independent corroboration: The frozen evidence defines Design Downselection as 'Implements the archetype in design work by comparing rough concepts first and investing detailed engineering, prototyping, or testing in the most promising concepts', so its operative form is Decision, Gate & Allocation.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Engineering & Design

Origin pattern: Single lineage

Present-day reach: Multi-domain

Rationale: Engineering concept selection cohered Pugh controlled convergence for comparing rough concepts against a datum and iteratively narrowing with evidence.

Related originating lineages:

  • Operations Research — Multi-criteria decision methods supplied weighted comparison and dominance screening.

Review resolution: Engineering concept selection cohered Pugh controlled convergence for comparing rough concepts against a datum and iteratively narrowing with evidence. The retained alternate lineages materially shaped the mechanism's form.

Review outcome: Reconciled after independent review; high confidence.

Notes

The unit of search is what separates this from Coarse Grid Search: grid search refines a point in a parameter space by shrinking spacing, whereas downselection refines a whole architecture by adding engineering detail. The two often nest — a design is downselected, then its chosen architecture's parameters are grid-searched — but they are not the same move.

References

[1] Pugh, S. Total Design: Integrated Methods for Successful Product Engineering. Addison-Wesley Publishing Company (1991). Describes Pugh controlled convergence as an iterative concept-selection matrix that scores alternatives against a datum and repeats the cycle. registry