Configuration design¶
An engineered-assembly task that seeks a permitted component arrangement meeting requirements or diagnoses why none exists.
Core Idea¶
Configuration design begins with a specified family of available components, rules for how they may be combined, and requirements for an engineered assembly. The task is to find an allowed selection and arrangement that meets those requirements. If the requirements cannot be satisfied with the available components and relations, detecting that inconsistency is also an outcome of the task. A task does not cease to be configuration design simply because this particular instance has no solution.[1]
The distinction is between a problem to solve and its possible result. A completed system configuration records one assignment of components, connections, parameters and boundaries. Configuration design asks which such assignment, if any, can meet the stated requirements. It does not prescribe a universal algorithm: R1's rule system for computer orders and the original VT elevator designer use different implementation methods while addressing the same selection-and-arrangement problem.[1][2][3]
Structural Signature¶
Sig role-phrases: available component types; permitted composition relations; requirements and constraints; configuration attempt and feasibility result.
- Available component types. A catalogue identifies the parts that may be selected, with properties relevant to the task. If every part may be invented without bounds, this particular configuration problem is no longer specified.[1]
- Permitted composition relations. Connection, placement, containment or compatibility rules determine how selected parts may jointly form an assembly. A parts list alone does not establish a valid arrangement.[1][2][3]
- Requirements and constraints. Customer functions and applicable restrictions define what a proposed arrangement must achieve or avoid. They also allow a finding that no permitted arrangement meets all requirements.[1][2][3]
- Configuration attempt and feasibility result. The task seeks a selection and relation assignment. A feasible case yields one or more satisfying assemblies; an infeasible case yields an inconsistency diagnosis. Neither branch requires a particular search or optimization procedure.[1]
These four roles identify the task across unlike assemblies. Cabinet and cable rules in a computer order differ from elevator equipment and layout constraints; both specify components, allowed relations, requirements and a search for a satisfying arrangement.[2][3]
What It Is Not¶
It is not the finished configuration. A target declaration can name one system's components, relations and parameter values. That declaration is the successful branch's product or a proposed target. It is not the task of selecting that product, and an infeasible task may have no such product at all.
It is not one solver technique. R1 uses recognition-driven rules, while the original VT work describes knowledge-based backtracking and constraint repair. Those mechanisms can solve particular instances but do not define all configuration-design tasks.[2][3]
It is not every problem called configuration. Some Sisyphus-VT benchmark treatments work largely with predefined structure and parameter assignment. That narrower task can be useful, but it cannot by itself prove that the structural selection and relation roles occur in all problems carrying the broader label. The full elevator positive here is the original implemented VT system, not the later benchmark.[4][3]
It is not the whole engineering design process. Requirements, concept generation, modeling, prototyping, verification and lifecycle handoff can surround a configuration task. The configuration identity does not require that entire workflow in every instance.
Scope of Application¶
In computer-system assembly, R1 takes a customer order for a VAX system and works with available cabinets, devices, boards, cables and connection rules. The order can omit needed components; the configuration work must choose compatible additions and give a spatially coherent assembly. Its production-rule implementation is local to that system.[2]
In elevator-system design, the original VT system takes customer functional requirements and selects equipment and relationships among parts. Safety, installation and maintenance constraints bear on whether the chosen layout is acceptable. Its constraint repair and backtracking differ from R1's rules. The inspected full text is the author-uploaded OCR of the Winter 1987 AI Magazine article; a separately listed same-titled 1988 edition was not inspected for this entry.[3][5]
The same four-role test can guide another engineered-assembly problem only if its available components, allowed relations and requirements are specified. Calling an open-ended invention problem or a parameter-only assignment a configuration-design instance without checking those roles would stretch this entry beyond its evidence.[1][4]
Clarity¶
Write the input contract before discussing a solution: which components are available, which properties matter, what connections or placements are allowed, and which requirements must be met. A particular proposed assembly can then be checked against that contract. This separates a requirement from a design choice and makes a failed assignment intelligible.[1]
State whether a reported result is feasible or inconsistent. If feasible, identify the selected components and relations, not merely a list of parts. If inconsistent, identify the conflicting requirements or lack of available compatible parts. The generic task definition allows either outcome; a diagram from a successful case should not be treated as proof that every input has a valid design.[1]
Manages Complexity¶
Configuration design separates a potentially large search space into a catalogue, an admissible-relations scheme and a requirements test. That separation makes it possible to ask which part of the task causes a failure: a missing component, an impermissible connection, or requirements that cannot be jointly satisfied. It also prevents a solver's execution order from being mistaken for the problem's identity.[1]
The two cases show why relation rules matter. A VAX order is not solved simply by counting required boards if they cannot be placed and connected in compatible cabinets. An elevator design is not solved simply by naming equipment if the relationships and layout violate installation or safety constraints. These are case-specific engineering checks under the same role structure.[2][3]
Abstract Reasoning¶
Represent a candidate assembly as selected components together with relation assignments. Test the candidate against the declared requirements and compatibility rules. If it passes, it is a satisfying configuration; if every admissible assignment fails, the task reaches the inconsistency branch. The question is whether an assignment exists under the given rules, rather than whether a favored algorithm found one quickly.[1]
For example, as a schematic counterfactual rather than a claim about the historical systems, suppose two required devices each demand an exclusive connection and the catalogue has only one compatible connection. The task remains configuration design even if the requirements cannot both be met. The diagnostic is that the permissible-component and connection system has no satisfying assignment, not that the task was never posed.[1]
Knowledge Transfer¶
The transferable method within engineered assembly is to map each new case to the same four questions: what may be selected, how may selected items relate, what must the whole satisfy, and what counts as a feasible or inconsistent result? R1 and original VT have different parts and methods, but both admit those questions.[2][3]
The transfer stops where the task lacks an available component system or permitted composition relations. The general act of designing for a purpose is wider, and the state of an already configured system is a different object. Their vocabulary may be useful for comparison, but the configuration-design test should not be projected onto them without the actual roles.[1]
Examples¶
R1/XCON computer order¶
A customer order specifies a desired VAX system. The available types include computer equipment such as cabinets, peripherals and cables. Permitted relations include compatible bus and cable connections and cabinet placement. The requirements come from the order and installation constraints. R1 supplies missing needed components and organizes them into an installable arrangement in this successful case.[2]
Mapped back: VAX catalogue → bus/cabinet/cable rules → customer order and compatibility → satisfying computer assembly. R1's recognition-driven rules are an implementation of this task, not an additional constitutive role.[2][1]
Original VT elevator system¶
A customer's functional specification calls for an elevator system. The available types are equipment and parts; the permitted relations include equipment compatibility and spatial layout. Requirements and constraints include performance, safety, installation and maintenance. The original VT designer proposes and repairs component choices and relationships, producing a configured design in the successful case described by its authors.[3]
Mapped back: elevator equipment catalogue → part relations and layout → customer and safety requirements → satisfying elevator design. The 1987 system's backtracking is a case-specific way to search; a later parameterized Sisyphus-VT benchmark is not substituted for this full positive.[3][4]
Structural Tensions¶
The inspected works establish task roles, successful implementations and the possibility of inconsistent requirements. They do not establish one opposed-pressure trade-off with the same diagnostic in both computer and elevator cases. In particular, describing every configuration task as a choice between speed and optimality would import an optimization objective that the generic definition does not require. The relevant distinction here is feasibility versus infeasibility, which is an outcome branch rather than a universal value trade-off.[1]
The entry's autonomy test is nonetheless concrete: after removing the broad idea of design and the declarative product called a configuration, the task still asks whether a bounded component and relation system satisfies requirements. That question has its own input contract and failure diagnostic. It is why this domain-specific entry remains an independent current-catalog root until a source-supported intermediate can carry its full task signature.[1]
Structural–Framed Character¶
The four-role task is structurally repeatable across the computer and elevator cases. Its component and relation vocabulary travels between engineered assemblies, but the meaning of a valid connection, installation constraint or acceptable performance remains tied to the engineering domain. The term is evaluatively neutral: a configuration problem can be well or poorly solved, and it can be infeasible, without losing the task identity.[1][2][3]
Human or organizational framing enters through the customer requirements and the choice of available components. In the inspected sources, task qualification follows the component, relation and feasibility roles rather than a formal institutional designation; engineering organizations still determine which catalogues and requirements govern a particular task. The core feasibility relation does not depend on R1's rule system or VT's backtracking, though an actual engineering application needs such a method or equivalent reasoning. Applying the entry to R1 and VT recognizes the same task roles in different artifacts; applying it to an arbitrary collection of things without permitted relations would import an engineering frame without the defining structure.[1]
Its character: a structurally repeatable but moderately framed engineering task, identified by its component-and-constraint contract rather than by an institution's label or one solver's method.
Structural Core vs. Domain Accent¶
The liftable skeleton is a constrained assignment problem: choose items and relations under requirements, then find a satisfying assignment or detect inconsistency. That skeleton resembles broader formal constraint reasoning. The domain accent is the engineered assembly itself: component catalogues, interfaces, placement, compatibility, and a realizable artifact are what make the assignment a configuration-design task.[1]
The full domain identity does not automatically become a Prime. A similar abstract assignment structure can appear in scheduling or logic, but those cases do not literally select and connect engineered components. Removing component and interface semantics leaves a broad satisfiability pattern, not this particular task. Whether that broader skeleton merits a separate Prime is an open future-Prime question; this named entry remains domain-specific and asserts no typed parent on that basis.[1]
Instantiates / Related Primes¶
The live Design Prime is a plausible broad neighbor because successful R1 and VT work specifies artifacts for customer purposes under constraints. Its full live signature also discusses generation, revision and evaluation, and it inherits Planning and Foresight commitments. The present source packet does not establish all those roles for every configuration task, especially a one-shot infeasible input. The current catalog therefore has no strict Design edge from this entry.
The live System Configuration Prime names a declared actual or intended arrangement with assignments. A successful configuration-design task can produce such a declaration; an infeasible task may produce none. Treating the task itself as a kind of System Configuration would confuse the work with one possible result. The broader Engineering Design Process includes more lifecycle and verification steps than this task requires.
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 component catalogue. It lists available parts but does not seek an assignment under requirements.
- A system configuration. It declares one arrangement; configuration design asks whether an admissible arrangement can be found.
- A parameter-only benchmark. Parameter choice under a fixed structure may be a narrower problem. It is not evidence that every configuration-design case selects components and their relations.[4]
- A solver. Rules, backtracking and optimization procedures may be used, but no one method defines the task.[1][2][3]
- The entire engineering design process. Prototyping, lifecycle handoff and configuration control may surround the task without being its four defining roles.
References¶
[1] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u
[2] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l
[3] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m
[4] 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. registry ↩a ↩b ↩c ↩d
[5] AI Magazine, “AI Magazine Volume 8 Issue 4 Winter 1987,” publisher issue listing, identifying the inspected original VT article. registry ↩