Configuration design¶
An engineered-assembly task that seeks a permitted component arrangement meeting requirements or diagnoses why none exists.
Core Idea¶
Configuration design asks whether available components can be selected and connected into an engineered assembly that meets stated requirements. The task starts with a component catalogue, rules for permitted relations, and requirements or compatibility constraints. It yields a valid arrangement if one exists, or diagnoses inconsistent requirements if none does. The task remains configuration design even when this particular input has no solution.[^ref-7919e99cd03b]
The task differs from its possible product: a completed system configuration declares one arrangement, while configuration design seeks an acceptable arrangement or determines that the given conditions cannot be met. It does not require one particular algorithm.[^ref-7919e99cd03b]
Use Within the Domain¶
R1/XCON applies the task to VAX computer orders, working with devices, cabinets and cable or bus connections. The original 1987 VT expert system applies it to elevator equipment, part relationships and layouts under functional, safety and installation requirements. These are unlike assemblies with the same four roles: available components, permitted relations, requirements, and a feasibility result. Both papers describe successful cases; the generic task definition also allows an inconsistency result.[ref-d60d7ba5ee1c][ref-b594b5cd0a5a][ref-fe6127f224ab][ref-7919e99cd03b]
The current catalog places this task as a zero-edge root. Design is a broad conceptual neighbor, but its full live signature and Planning/Foresight ancestors do not follow from every configuration task, including an infeasible one. A finished System Configuration is a possible successful result rather than the task itself; a future source-supported intermediate could later refine the graph placement.
Clarity¶
State which parts are available, how they may connect or be placed, and which requirements must hold. Then state the result as either a satisfying component-and-relation assignment or a diagnosis that the requirements conflict with the available system. A parts list alone is not a configured assembly, and an unsolved possibility space is not a completed outcome.[^ref-7919e99cd03b]
Manages Complexity¶
Separating catalogue, relation rules and requirements shows why a proposal fails. A computer order may have the right devices but lack compatible cabinet or cable placement. An elevator design may select equipment but violate layout or safety restrictions. The role map also keeps a solver's sequence separate from the problem it addresses.[ref-d60d7ba5ee1c][ref-b594b5cd0a5a]
Abstract Reasoning¶
Consider possible selections and relation assignments, then test each against the declared requirements. If at least one permitted assembly passes, the task has a satisfying configuration. If none passes, the result is inconsistency, not absence of a configuration-design task. The generic definition allows either branch without demanding optimization or a fixed search procedure.[^ref-7919e99cd03b]
Knowledge Transfer¶
In another engineered-assembly setting, ask what may be selected, how selected parts may relate, what the whole must satisfy, and how feasibility or inconsistency will be reported. That test transfers from computer equipment to elevator equipment. It does not turn every purposeful design, finished configuration record or parameter-only benchmark into this structural selection task.[ref-d60d7ba5ee1c][ref-b594b5cd0a5a][^ref-00fca8324237]
Example¶
Computer order: R1 takes a VAX order, supplies needed components and uses compatible cabinet, bus and cable relations to produce an installable assembly. Its production rules are one method for solving the task.[^ref-d60d7ba5ee1c]
Elevator design: The original 1987 VT system selects elevator equipment and relationships, checks functional and safety requirements, and repairs an unacceptable proposal. Its backtracking is another method, not part of the general task definition. The later Sisyphus-VT benchmark is a narrower parameterized comparison, not the full elevator positive used here.[ref-b594b5cd0a5a][ref-00fca8324237]
Neighborhood in Abstraction Space¶
Configuration design sits in a sparse region of the domain-specific corpus (69th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Software & Systems Architecture (32 abstractions)
Nearest neighbors
- Duck Typing — 0.85
- Cutting Stock Problem — 0.84
- Interface-Based Programming — 0.83
- Packing Problem — 0.83
- Structure chart — 0.83
Computed from structural-signature embeddings · 2026-10-17
Not to Be Confused With¶
A finished system configuration records an arrangement; configuration design seeks one or finds the requirements inconsistent. A component catalogue lists possibilities without solving the task. A specific solver such as a production-rule system or backtracker is a method, not the identity. A parameter-only benchmark may use a fixed structure and so cannot alone establish the component-and-relation selection roles of this entry.[ref-7919e99cd03b][ref-00fca8324237]
References¶
[^ref-7919e99cd03b]: Sanjay Mittal and Felix Frayman, “Towards a Generic Model of Configuration Tasks,” Proceedings of the 11th International Joint Conference on Artificial Intelligence (1989), pp. 1395–1401, especially §2.1 on printed p. 1396, original proceedings PDF. [^ref-d60d7ba5ee1c]: John McDermott, “R1, An Expert in the Computer Systems Domain” (the printed title uses a colon after “R1”), Proceedings of the First National Conference on Artificial Intelligence (1980), especially PDF p. 1, original AAAI proceedings PDF. [^ref-b594b5cd0a5a]: Sandra Marcus, Jeffrey Stout and John McDermott, “VT: An Expert Elevator Designer That Uses Knowledge-Based Backtracking,” AI Magazine 8, no. 4 (Winter 1987), pp. 41–58, DOI 10.1609/aimag.v8i4.622, author-uploaded full-text OCR. The inspected text is the 1987 edition; OCR may contain errors. [^ref-fe6127f224ab]: AI Magazine, “AI Magazine Volume 8 Issue 4 Winter 1987,” publisher issue listing, identifying the inspected original VT article. [^ref-00fca8324237]: B. J. Wielinga, J. M. Akkermans and A. Th. Schreiber, “A Formal Analysis of Parametric Design Problem Solving,” especially §3.3 on Sisyphus-VT, author-hosted paper. The author packet inspected a search-index rendering of this boundary source; it is not a full positive case here.