Design for Implementation

one_liner: Real-world feasibility.

aliases:
design for manufacturability
design for assembly
DFM
DFA
design for X
design for operations

core_idea:
Design for Implementation is the systematic discipline of constraining design decisions to account for the characteristics, limitations, and costs of the systems and processes that will produce, assemble, operate, maintain, or retire the design. The essential commitment is that designing an artifact (product, building, service, organizational process) is not complete when the functional requirements are met and the ideal performance is achieved; the design must also be implementable within the constraints of production, deployment, operation, and end-of-life processes.

Every design-for-implementation effort specifies (1) the implementation context or production system that will realize the design (which manufacturing process, which assembly sequence, which supply chain, which operational environment), (2) the constraints and costs of that implementation system (material choices available, process tolerances, labor costs, lead times, maintenance accessibility), (3) the design trade-offs that arise from those constraints (a design optimized for performance may require expensive machining; a design optimized for manufacturability may sacrifice some performance), and (4) the iterative feedback loop between design and implementation: design choices constrain implementation options, implementation constraints inform design revisions.

The deeper insight is that a design is not "done" at the engineering drawing stage; a design is only complete when it has been validated against actual production, assembly, and operational realities. This originated in manufacturing engineering (Design for Manufacturability, circa 1980s-1990s, Boothroyd-Dewhurst method) and extended to assembly (Design for Assembly, Dewhurst 1986), to quality (Design for Six Sigma, circa 2000s), and more broadly to any implementation context (Design for Serviceability, Design for Disassembly, Design for Sustainability). The mechanism works because it forces the designer to confront hidden costs and constraints early, before tooling, procurement, and production processes are committed. A design that works perfectly on paper but is expensive or impossible to manufacture is a failure of design discipline, not a manufacturing problem<!-- FACT-D34-121 -->[^boothroyd-dewhurst-1991].

structural_signature:
- *The explicit identification of the implementation system that will produce, assemble, or operate the design* <!-- FACT-D34-122 -->[^boothroyd-dewhurst-1991]
- *The enumeration of constraints and costs inherent in that implementation system (process capabilities, material properties, labor and capital costs, timeline, scalability)* <!-- FACT-D34-123 -->[^dewhurst-1997]
- *The quantification of implementation trade-offs: how does design choice X change production cost, assembly time, quality yield, operational complexity, maintenance burden?* <!-- FACT-D34-124 -->[^stoll-1999]
- *The iterative feedback between design evolution and implementation feedback, with design revisions made when implementation analysis reveals infeasibilities or unacceptable costs* <!-- FACT-D34-125 -->[^stoll-1999]
- *The distinction between design-for-standard-implementation (optimizing for the implementation system that will actually be used) and design-for-flexible-implementation (leaving implementation options open to be decided later)* <!-- FACT-D34-126 -->[^ulrich-eppinger-2015]
- *The transition from design intent (what we want to achieve) to implementation specification (how the artifact must be detailed for a specific production or operational system to realize it)* <!-- FACT-D34-127 -->[^otto-wood-2001]

what_it_is_not:
- **Not the same as meeting functional specifications.** A design meets specifications if it performs as required; it meets design-for-implementation if it can be produced, assembled, and operated economically and reliably. A design can meet specs but be impossible to manufacture profitably.

- **Not a constraint on creativity.** Design-for-implementation is sometimes caricatured as "engineers preventing designers from being creative." In practice, implementation constraints often inspire creative solutions. A designer learning that a chosen material is unavailable or prohibitively expensive may discover a better material through that constraint.

- **Not a substitute for manufacturing or operational expertise.** Design-for-implementation requires input from manufacturing engineers, supply-chain specialists, and operations personnel. A design team without that expertise will make implementation-unfeasible designs no matter how much they intend to respect constraints.

- **Not a guarantee of lowest cost or optimal performance.** Design-for-implementation is about implementability and cost-effectiveness, not absolute optimization. A design can be successfully implementable but more expensive than competitors' designs. The design-for-implementation trade-off is explicit: this design is implementable in this system at this cost; different choices would change the trade-off.

- **Not universally applicable to all design contexts equally.** Design-for-implementation is most critical for high-volume manufacturing (where implementation efficiency multiplies across millions of units), for safety-critical systems (where operational reliability is non-negotiable), and for complex supply chains (where supplier constraints are binding). For bespoke, custom designs or for designs where volume is very low, the leverage of design-for-implementation is smaller.

- **Not static.** Implementation systems evolve — new manufacturing processes become available, supply-chain alternatives emerge, operational contexts change. Designs optimized for one implementation system may become uneconomical when the system changes. This requires design-for-implementation to be revisited periodically.

broad_use: Manufacturing and product design (Design for Manufacturability — DFM — optimizing tolerance stack-up for achievable process capability; selecting materials and processes available from suppliers; designing parts to avoid expensive secondary operations; Design for Assembly — DFA — minimizing part count, simplifying assembly sequence, avoiding asymmetrical parts that are installed backwards), automotive engineering (designing engine components for robotic assembly, designing underbodies for automated welding, designing subsystems for quick removal and replacement during service), electronics manufacturing (designing PCBs for automated insertion and soldering, minimizing unique part types to simplify supply chain, designing for thermal management within package constraints), pharmaceuticals (designing drug formulations and delivery systems compatible with existing manufacturing processes, designing dosages compatible with manufacturing tolerances), architecture and construction (designing buildings for available construction methods and local labor, designing façade systems compatible with installation equipment, designing for disassembly and material recovery), software engineering (designing systems for deployment on target infrastructure, designing for operational monitoring and troubleshooting, designing database schemas for the performance characteristics of available storage systems), organizational design (designing workflows compatible with available skill levels and technology, designing decision processes compatible with communication infrastructure), and infrastructure systems (designing water systems compatible with available maintenance expertise, designing transportation networks for construction equipment and labor availability).

clarity: Naming design-for-implementation explicitly signals that implementation is a design constraint, not a downstream problem to be solved in manufacturing. The clarity also creates a boundary: what is the design team's responsibility (design for implementability), and what is manufacturing's responsibility (optimize implementation given the design)? Without clarity, design teams may treat implementation as someone else's problem, or conversely, manufacturing may blame design for every implementation challenge.

manages_complexity: Complex products involve hundreds of components and thousands of interactions. Optimizing all interactions simultaneously is intractable. Design-for-implementation decomposes the problem: design to specifications under implementation constraints, rather than optimizing all interactions globally. For instance, Boothroyd-Dewhurst DFM analysis provides heuristics for design choices (minimize part count, standardize parts, design for linear assembly) that simplify the optimization landscape without requiring exhaustive global optimization. This heuristic-based approach makes complex design problems tractable.

abstract_reasoning: The analyst or designer asks: What is the production or operational system that will realize this design? What are its constraints and costs? Which design choices are expensive or infeasible given these constraints? What alternative designs are compatible with the implementation system? For each design alternative, what is the total cost of ownership: design cost, production cost, assembly cost, quality yield, logistics, field service, end-of-life? How does the design change if we assume a different implementation system (different manufacturer, different supply chain, different operational context)? Is the design robust to variation in implementation (will it work if a supplier is substituted, if labor costs increase, if volumes scale up or down)? After production begins, what design revisions are justified based on implementation feedback?

knowledge_transfer:
| Implementation context | Design constraint | Typical design trade-off | Optimization metric |
| --- | --- | --- | --- |
| High-volume injection molding | Mold cost, cycle time, part geometry limitations | Avoid thin walls, draft angles, undercuts | Unit cost across volume |
| Precision machining | Tool access, cutting-tool life, setup time | Minimize part count, avoid complex internal features | Batch cost and cycle time |
| Manual assembly by skilled labor | Labor cost per unit, ergonomics, error rates | Design for quick assembly, clear error-proofing | Labor hours and quality yield |
| Robotic assembly | Part presentation, tool programming, cycle time | Design for linear assembly, symmetrical parts, fixturable geometry | Cycle time and capital utilization |
| On-site construction | Weather, labor availability, equipment access | Design for prefabrication where possible, simple connections | Schedule and labor efficiency |
| Software deployment on commodity servers | Scalability, database query latency, memory footprint | Design for horizontal scaling, asynchronous processing, caching | Cost per transaction and latency |
| Organizational process | Available skill levels, communication latency, decision-making authority | Design for minimal handoffs, clear decision rights, automation where feasible | Cycle time and error rates |

Transfer principle: the same diagnostic reasoning (identify implementation system, enumerate constraints, quantify trade-offs, iterate design to respect constraints) applies across domains.

formal_abstract:
Boothroyd and Dewhurst (1991) in *Product Design for Manufacture and Assembly* and Dewhurst (1997) formalized the Design for Manufacturability and Assembly methodology: systematically analyze each component for manufacturability (can the process produce it within tolerance? at what cost?), analyze the assembly sequence for efficiency (how many parts can be combined? what is the theoretical minimum number of parts?), and compute a design efficiency metric (theoretical minimum assembly time divided by actual assembly time). The methodology provides heuristics: minimize part count, eliminate adjustment and fasteners, use symmetrical parts, avoid flexible components. Stoll (1999) extends the framework to Design for Manufacture and Assembly (DFMA) as an iterative design discipline: designers propose a design, manufacturing engineers analyze it for DFM/A efficiency, designers revise based on feedback, and the cycle repeats until an acceptable design-efficiency score is reached. The deeper insight is that DFM/A is not about manufacturing limitations constraining design; it is about using manufacturing knowledge to inform better design. Ulrich and Eppinger (2015) frame design-for-X (manufacturability, assembly, serviceability, sustainability, cost) as a set of design criteria to be weighted alongside functional performance and aesthetics. The trade-off is explicit: a design cannot optimize for all criteria simultaneously; the designer must choose which criteria matter for the specific product and market<!-- FACT-D34-128 -->[^boothroyd-dewhurst-1991].

**Mapped back:** This instantiates the signature directly — the explicit identification of the implementation system (manufacturing process, labor model, Boothroyd-Dewhurst DFM/A methodology, D34-122), the enumeration of constraints (process capabilities, assembly sequence limitations, cost structure, D34-123), the quantification of trade-offs (design-efficiency metrics, cost models, D34-124), and the iterative feedback between design and manufacturing analysis (D34-125).

applied_industry:
A consumer electronics manufacturer designs a smartphone for high-volume production in multiple regional factories. The design team, working with manufacturing engineers, identifies several design-for-implementation choices. (1) **Material selection:** the designer proposes aluminum for structural rigidity; manufacturing analysis reveals that aluminum requires expensive anodizing and careful machining. Feedback suggests glass-filled plastic as an alternative: cheaper to mold, acceptable stiffness, easier to color. Revised design uses plastic. (2) **Component assembly:** the designer proposes a traditional approach with 47 separate components assembled with fasteners and connectors. DFA analysis shows 200+ assembly steps and high error rates. Revised design uses snap-fit assembly reducing parts to 12 and assembly steps to 15. (3) **Tolerancing:** initial tolerances are tight (±0.1 mm) to ensure fit-and-function; manufacturing analysis reveals such tolerances are costly in high-volume molding. Revised tolerances (±0.3 mm) still ensure function but dramatically reduce rejection rates and scrap. (4) **Supply chain:** design assumes a single-source supplier for a critical module; business analysis reveals supply-chain risk (single point of failure). Revised design uses components from two alternative suppliers, requiring design changes to accommodate dimensional variations from both suppliers. (5) **Serviceability:** design assumes sealed construction; operational feedback reveals that users want to replace batteries. Revised design includes a service panel for battery replacement. Each decision is a trade-off between design intent (what we want) and implementation reality (what we can economically manufacture and support). The final design is a compromise, but it is a compromise made deliberately, with understanding of costs and trade-offs<!-- FACT-D34-129 -->[^ulrich-eppinger-2015].

**Mapped back:** Shows design-for-implementation as iterative discipline — identification of implementation system (multiple regional factories, molding and assembly processes, D34-122), enumeration of constraints (material costs, assembly process capability, tolerance achievability, supplier alternatives, D34-123), quantification of trade-offs (cost per unit, assembly yield, supply-chain risk, D34-124), and iterative revision of design based on manufacturing feedback (D34-125).

title: Performance optimization versus implementation cost

body:
A design optimized purely for performance (lightest weight, fastest processing, best aesthetics) may incur high implementation costs (exotic materials, complex machining, difficult assembly). A design optimized purely for implementation cost (simplest manufacture, cheapest materials, minimum assembly) may sacrifice performance. The tension is between what the product should be able to do and what it costs to produce it. A common failure is optimizing for performance early in design, then discovering that manufacturing costs are unacceptable, forcing expensive redesigns late in the cycle<!-- FACT-D34-130 -->[^boothroyd-dewhurst-1991].

- **T2: Design flexibility versus implementation commitment.**
  Leaving implementation options open (we'll decide on manufacturing process later) postpones commitment but delays design decisions and increases risk of late-stage surprises. Early commitment to a specific implementation system (we will injection-mold this in China) constrains design space but enables optimization and early cost estimation. The tension is between the flexibility of postponing decisions and the efficiency of early commitment. A common failure is designing for flexibility, then discovering that the flexibility is illusory (different manufacturing processes have different cost structures, and no single design optimizes all)<!-- FACT-D34-131 -->[^ulrich-eppinger-2015].

- **T3: Design-for-standard-process versus design-for-differentiation.**
  Designing for standard, widely-available processes (commodity injection molding, standard electrical connectors, off-the-shelf components) minimizes cost and risk. Designing for custom or specialized processes (precision machining, proprietary assembly, custom materials) can enable differentiation but incurs higher cost and longer lead times. The tension is between the safety of standard processes and the market advantage of differentiation. A common failure is pursuing differentiation through custom manufacturing without understanding the cost and risk implications<!-- FACT-D34-132 -->[^otto-wood-2001].

- **T4: Design robustness versus implementation specialization.**
  Designing for robustness across multiple implementation systems (this design works in any injection-molding factory, any assembly labor context) requires accepting some inefficiency in each system. Designing for specialization (optimized for our specific factory with our specific labor and equipment) maximizes efficiency but becomes fragile if implementation context changes (factory closes, labor costs shift, new equipment is introduced). The tension is between robustness and efficiency. A common failure is over-specializing a design to a specific manufacturer, creating lock-in and dependency<!-- FACT-D34-133 -->[^stoll-1999].

- **T5: Design validation versus implementation discovery.**
  Validating a design through simulation, analysis, and laboratory testing occurs in a controlled environment; real-world implementation may reveal failures not discovered in validation. Postponing all validation until actual production (learning implementation constraints from manufacturing, operational feedback) is risky and costly but grounds the design in reality. The tension is between the safety of upfront validation and the realism of implementation discovery. A common failure is validating a design thoroughly but against the wrong implementation assumptions (validated for ideal manufacturing conditions but actual suppliers have lower capability)<!-- FACT-D34-134 -->[^dewhurst-1997].

- **T6: Design documentation and implementation interpretation.**
  A detailed design specification is necessary for manufacturing to reproduce the design consistently. However, overly detailed specifications can be brittle — if one detail becomes infeasible due to supply-chain changes or cost pressures, the entire design is considered non-compliant. Under-specified designs give manufacturing freedom to interpret and optimize but risk uncontrolled variation and quality issues. The tension is between specification precision and specification flexibility. A common failure is specifications that are overly detailed in areas where flexibility is needed, and underspecified in areas where consistency is critical<!-- FACT-D34-135 -->[^ulrich-eppinger-2015].

prose:
_(Pass B — deferred)_

### Catalog cross-references (v1, batches 02–29)

Solution archetypes that reference this prime (per `solution_archetypes/_catalog/catalog_v1_batches_02_29.yaml`):

**As related prime (1):** `proceduralization`

notes:
Design for Manufacturability and Assembly (DFM/A) originated in manufacturing engineering and industrial design in the 1980s-1990s (Boothroyd-Dewhurst, circa 1984). The formalization as a quantitative methodology (design-efficiency metrics, assembly-sequence analysis) enabled systematic comparison of design alternatives. The extension to "Design for X" (X = Manufacturability, Assembly, Cost, Serviceability, Sustainability, Reliability) reflects the recognition that implementation constraints vary by context. In software and organizational design, the equivalent discipline appears as infrastructure-driven design (design systems to the capabilities of available infrastructure) and process-driven design (design workflows to available labor and decision-making structures). Contemporary design practice recognizes that design-for-implementation is not a final check but an ongoing conversation between design, manufacturing, supply chain, and operations throughout the product lifetime. The concept interfaces with Margin of Safety (design includes margins to accommodate manufacturing variation), Constraint Satisfaction (implementation provides the constraints), and Quality Management (DFM/A contributes to quality by eliminating difficult or error-prone steps).

Contemporary practice extends the original DFM/A foundation with Lean Manufacturing principles (Womack-Jones 1996), Design for Six Sigma (Yang-El-Haik 2003), Concurrent Engineering (Prasad 1996), and supply-chain integration (Fine 1998 *Clockspeed*) — recognizing that implementation context spans not just immediate production but full lifecycle including assembly, distribution, service, and end-of-life recovery.


Design for Lifecycle Adaptability

type: prime

one_liner: Plan for change.

status: draft

aliases:
design for changeability
design for disassembly
design for evolution
modularity for lifecycle

core_idea: Design for Lifecycle Adaptability is the engineering practice of intentionally structuring a system, product, or process such that it can be *modified, updated, reconfigured, repurposed, or deconstructed* at different stages of its operational life without excessive cost, complexity, or compromise to core function. This is characterized by (1) the anticipation during design of how the system might evolve — what requirements might change, what components might need upgrade or replacement, what performance characteristics might shift — and the deliberate embedding of adaptability mechanisms (modular interfaces, redundancy, excess capacity, staged assembly) to accommodate foreseen evolution, (2) the separation of *change-prone elements* (user interfaces, algorithm parameters, feature sets, component versions) from *stable core elements* (fundamental architectures, load-bearing structures, critical protocols) such that changes to the former do not require redesign of the latter, (3) the recognition that *every system has a lifecycle* — it is born (design, manufacture, deployment), evolves (maintenance, upgrades, extensions, configuration), and dies (decommissioning, recycling, repurposing) — and that adaptability decisions made during design profoundly affect the cost and feasibility of evolution and end-of-life stages, (4) the commitment to *ease of partial change*: a well-adapted system can be modified piecemeal (replace one component, upgrade one subsystem) without requiring wholesale redesign or downtime, and (5) the understanding that adaptability reduces waste — systems designed for easy reconfiguration or upgrading are used longer, their components are reused or recycled rather than discarded, and the total lifecycle cost and environmental impact are reduced. The deeper insight is temporal: static design (optimize for current requirements, assume future requirements unknown) is brittle; adaptive design (anticipate categories of change, build flexibility in) is resilient. Design for Lifecycle Adaptability originated in mechanical engineering (design of machinery for easy maintenance and upgrade), manufacturing systems (production lines that can be reconfigured for different products), and architecture (buildings designed for renovation or conversion). The principle formalized through design-for-disassembly (Ulrich, 1995, focusing on end-of-life disassembly for reuse and recycling), design-for-changeability frameworks (Fricke and Schulz, 2005), and epoch-era analysis (Ross, Rhodes, and Hastings, 2008) which model how systems evolve through discrete change epochs. The mechanism works because anticipating change during design is vastly cheaper than retrofitting adaptability after deployment; systems designed with adaptability built in can evolve gracefully, whereas systems designed for static conditions become increasingly costly to modify as they age<!-- FACT-D35-046 -->[^ulrich-1995].

structural_signature:
- *The anticipation of change scenarios during design: identification of what elements are likely to change (requirements, technologies, regulations) and what elements should remain stable* <!-- FACT-D35-047 -->[^ross-rhodes-hastings-2008]
- *The separation of change-prone from stable elements through modular partitioning, clear interfaces, and bounded coupling* <!-- FACT-D35-048 -->[^ulrich-1995]
- *The design of adaptability mechanisms: redundancy, excess capacity, staged implementation, or reconfigurability that enable evolution without redesign* <!-- FACT-D35-049 -->[^fricke-schulz-2005]
- *The emphasis on ease of partial modification: change to one element should not require downstream redesign cascades* <!-- FACT-D35-050 -->[^baldwin-clark-2000]
- *The attention to assembly and disassembly sequences: components designed to be assembled and reassembled with minimal cost or specialized equipment* <!-- FACT-D35-051 -->[^boothroyd-alting-1992]
- *The assessment of lifecycle cost and environmental impact: designing for reuse and recycling, not just operational efficiency* <!-- FACT-D35-052 -->[^ellen-macarthur-2013]

what_it_is_not:
- **Not the same as modularity.** Modularity is about decomposition for understanding and management; lifecycle adaptability is about designing that decomposition such that modules can be swapped, upgraded, or removed during operation. A modular system need not be adaptable; an adaptable system must be modular.

- **Not the same as flexibility.** Flexibility (a system that can handle variable inputs or operating conditions) is a design goal; adaptability (a system that can be modified over time) is different. A flexible control system (one that can handle multiple input patterns) is not necessarily adaptable (it may be impossible to upgrade its components). Conversely, a system designed for easy upgrade may have less flexibility (less ability to handle unexpected conditions).

- **Not the same as fault tolerance.** Fault tolerance (a system that continues to function despite component failures) is about resilience to sudden unexpected events. Adaptability is about planned, foreseen evolution. A fault-tolerant system remains functional when a component fails; an adaptable system can replace components before failure or incorporate new capabilities.

- **Not a guarantee of infinite lifetime.** Designing for adaptability extends useful life and reduces costs, but nothing is truly indefinite. Eventually, new requirements become so different from the original design that adaptation is infeasible, and replacement or complete redesign becomes necessary.

- **Not costless.** Designing for lifecycle adaptability requires upfront investment — additional design analysis, modular architecture (often more expensive than monolithic), and preparation for future change. For systems with short lifespans or well-understood static requirements, this overhead may exceed benefit. Adaptability is an investment whose returns accrue over the system's full lifecycle.

- **Not about over-engineering.** Adaptability does not mean designing with unlimited excess capacity or preparing for every conceivable change. It means identifying likely changes (based on domain experience and forecasts) and designing to accommodate those specific categories of change while accepting that unforeseen changes will require redesign.

broad_use: Automotive design (chassis and platform architectures designed to accommodate multiple vehicle models, engine generations, and regulatory variations; modular powerplant designs enabling rapid replacement or upgrade), aircraft design (fuselage and systems designed for mid-life upgrades of avionics, engines, and seating without major structural changes), computer and electronics manufacturing (processor sockets enabling CPU upgrades, memory slots for RAM expansion, modular power supplies, standardized interfaces enabling component replacement), information systems (microservices architectures enabling independent service updates, API versioning enabling backward compatibility, database schemas designed for schema evolution), buildings and real estate (modular construction enabling reconfiguration of internal spaces, system separation enabling independent upgrade of electrical, HVAC, plumbing systems), software applications (plugin architectures enabling feature additions without core code changes, configuration files enabling customization without recompilation), manufacturing and production (reconfigurable assembly lines enabling tooling changes for different products, modular jigs and fixtures), organizational processes (decoupled workflows enabling changes to one process without affecting others, staged implementation of process changes), and policy and regulation (modular legal codes enabling repeal or amendment of specific sections without toppling the entire system, sunset clauses enabling phase-out or renewal without permanent commitment).

clarity: Naming Design for Lifecycle Adaptability explicitly signals the commitment to evolution and long-term thinking. The alternative — designing solely for current requirements — leads to brittle systems that become increasingly costly to modify over time. An explicit adaptability commitment makes visible the lifecycle thinking: stakeholders recognize that requirements will evolve, that the system will outlive some of its original design assumptions, and that planning for change is part of good design. This clarity prevents a common failure: designing beautiful systems that solve today's problems perfectly but become expensive to modify when requirements evolve, leading to wasteful replacement rather than graceful adaptation.

manages_complexity: Adaptability manages complexity by distributing change over the system's lifetime. Rather than making a single perfect design upfront (which requires anticipating all possible futures), adaptable design makes a good-enough design with hooks and mechanisms for improvement. Early versions of the system address core needs; later versions address evolved needs without discarding earlier investments. Complexity of individual change is reduced (each adaptation is a bounded, localized modification) even as the total system evolves to greater sophistication. Lifecycle thinking also reduces the complexity of decommissioning: systems designed for disassembly can be recycled or repurposed rather than discarded whole, reducing waste and hidden costs.

abstract_reasoning: The designer asks: What are the likely sources of change in this system over its intended lifetime? Will requirements evolve (new features, new users, new use cases)? Will technologies change (available materials, manufacturing techniques, regulatory standards)? Will operating conditions shift (load, duration, environment)? Rather than designing to a single point (current requirements, current technology), the designer identifies *categories of change* and designs mechanisms to accommodate them. For each category, the designer asks: If this change occurs, what is the cost of adaptation? Can we design now to reduce that future cost? The designer then specifies: Which elements will remain stable (foundational architecture, core protocol, primary structure)? Which elements are expected to change (specific components, material choices, feature parameters)? How are stable and change-prone elements separated? What redundancy or excess capacity is built in? Can components be replaced independently or must a cascade of changes propagate? After the design is specified, the designer verifies: If we upgrade one component, how many other components must be changed? Can we test the upgraded component independently? How long does the modification take? Can the system continue operating during modification (staged implementation) or must it be shut down?

knowledge_transfer:
| Domain | Stable core | Change-prone elements | Adaptation mechanism | Lifecycle benefit |
| --- | --- | --- | --- | --- |
| Automotive | Platform, chassis geometry | Engine, transmission, electronics, trim | Modular engine/transmission mounts, standardized interfaces | Product variants from one platform; mid-life facelifts |
| Aircraft | Fuselage structure, systems layout | Avionics, engines, seats, interior | Modular bay architecture, standardized electrical/data buses | Avionics upgrades without major rework; engine swaps between variants |
| Electronics | Circuit board layout, power delivery | Processors, memory, storage, peripherals | Standardized sockets, connectors, form factors | Easy CPU/RAM upgrades; component replacement without rework |
| Software | Core algorithms, API contracts | Feature implementations, configuration parameters | Plugin architecture, configuration files, versioning | New features without core changes; adaptation to new environments |
| Buildings | Structural frame, utility routing | Interior layout, systems (HVAC, electrical, plumbing) | Modular mechanical and electrical systems, independent routing | Reconfiguration for new tenants; system upgrades without structural work |
| Manufacturing | Production sequence, station layout | Equipment, tooling, fixtures | Modular fixtures, standardized material handling | Production line reconfiguration for new products |

Transfer principle: across domains, the same analytical structure applies — identify what must remain stable for the system to function, anticipate what will change, separate them through design, and build mechanisms for change. An automotive engineer designing a platform for multiple models, a software architect designing for feature evolution, and a facilities manager designing a building for reconfiguration are performing the same adaptability analysis under different variable names.

formal_abstract:
Ulrich (1995) in "The Role of Product Architecture in the Manufacturing Firm" establishes that product architecture — how a product is partitioned into components and how those components are integrated — fundamentally determines what changes are possible and how costly they are. A *modular architecture* (components with standard interfaces, loosely coupled) enables independent evolution: one component can be improved or replaced without redesigning adjacent components. An *integral architecture* (tight coupling, custom interfaces, many interdependencies) means that improving one component often requires redesigning several others. Ulrich argues that manufacturing firms with modular product architectures can introduce product variants faster and at lower cost than firms with integral architectures. Fricke and Schulz (2005) in "Design for Changeability (DFC): A Systematic Approach to Estimating the Costs of Product Changes" formalize change-cost estimation: for each potential change, analyze what components are affected, what integration and testing is required, what is the schedule impact. Design-for-Changeability means identifying high-probability, high-impact changes and designing to reduce their cost. Ross, Rhodes, and Hastings (2008) in "Architecting for Evolution" introduce *epoch-era analysis*: systems evolve not continuously but in epochs of relative stability interrupted by eras of significant change. By analyzing past epochs in similar systems, designers can anticipate future change patterns and design accordingly. For example, a satellite platform designed for a 15-year mission might anticipate that 5 years in, communication standards will evolve, requiring electronics upgrades. Building upgrade capability into the design now costs extra upfront but avoids catastrophic obsolescence mid-mission. Allen (1990) on modular adaptability in systems engineering emphasizes that adaptability requires both *design modularity* (independent components) and *change protocols* (well-defined ways to integrate new components or versions without regression). Without change protocols, modular systems can become unmanageable as the number of component combinations grows combinatorially<!-- FACT-D35-053 -->[^ulrich-1995].

**Mapped back:** This instantiates the signature directly — anticipation of change through architecture analysis (Ulrich on architectural impact, Fricke-Schulz on change-cost estimation, D35-047), separation of stable core from change-prone elements (modular architecture enabling independent evolution, D35-048), design of adaptability mechanisms (Fricke-Schulz identifying high-impact changes, Ross-Rhodes-Hastings epoch-era analysis predicting change patterns, D35-049), emphasis on ease of partial modification (modular architecture reducing change propagation, D35-050), attention to assembly/disassembly (component integration protocols, D35-051), and lifecycle thinking (Ulrich on manufacturing cost and time-to-market over product lifetime, D35-052).

applied_industry:
A manufacturing company designs a production line for assembling consumer electronics. The initial requirements specify production of one model at a rate of 5,000 units per month. Traditional design would optimize the line exclusively for that specific model: specialized fixtures, custom material-handling equipment, minimal buffering between stations. However, the company anticipates that over the line's 10-year lifetime, product designs will evolve (new models, new form factors), production volumes will fluctuate, and manufacturing locations might change. To design for lifecycle adaptability, the engineers partition the production sequence into *stable core* (test procedures, quality protocols, statistical process control) and *change-prone elements* (specific equipment, fixtures, component-specific handling, assembly sequence). They design modular fixtures that can be reconfigured to handle multiple form factors, implement buffering between stations to reduce coupling, and establish standardized material-handling protocols so equipment can be swapped. The line includes excess capacity (stations sized for 7,000 units/month even though initial demand is 5,000) to accommodate future product variants with heavier components. Five years in, product designers introduce a new model with different dimensions. Retrofitting the traditional line would require redesigning most fixtures and significant downtime. Retrofitting the adaptable line requires reconfiguring fixtures (2 weeks, cost $50K), updating the assembly sequence (1 week), and baseline-testing the new product (2 weeks). Total cost and downtime are acceptable; the line continues to serve the company for another 5 years. At end-of-life, the modular fixtures and equipment are sold as used manufacturing assets, recovered at 30% of original cost; the monolithic custom-built equipment would have been scrap. The adaptable design cost 15% more upfront but avoided $500K in retrofit costs and generated $200K in salvage value, a clear lifecycle return on investment<!-- FACT-D35-054 -->[^fricke-schulz-2005].

**Mapped back:** Shows lifecycle adaptability as an industrial economics discipline — anticipation of form-factor and volume evolution (D35-047), separation of stable production protocols from change-prone equipment and fixtures (D35-048), design of modular fixtures and standard material handling (adaptability mechanisms, D35-049), emphasis on ease of partial modification without full line redesign (D35-050), standardized assembly and disassembly for fixture reconfiguration (D35-051), and lifecycle cost analysis including retrofit, downtime, and end-of-life salvage (D35-052).

title: Designing for anticipated change versus designing for unknown futures

body:
Design-for-adaptability requires anticipating what will change; but anticipation is imperfect. Resources invested in accommodating likely changes (e.g., modular architecture for component upgrades) may be wasted if the changes don't materialize. Conversely, failing to design for a change that does occur is expensive. The tension is between over-designing for unlikely futures (wasted capability) and under-designing for likely changes (expensive retrofits). A common failure is either investing heavily in adaptability mechanisms that are never used, or assuming changes are unpredictable and designing for static requirements, only to be surprised by expensive mid-life modifications<!-- FACT-D35-055 -->[^ross-rhodes-hastings-2008]*.

- **T2: Adaptability and initial design simplicity.**
  A system designed solely for current requirements can be simpler and cheaper to design and build initially. Designing for adaptability adds complexity upfront: additional modularity, interfaces, redundancy, and contingency planning. This complexity increases initial cost and may reduce initial performance. The tension is between time-to-market and cost-to-build (favor simplicity) versus lifecycle cost and evolvability (favor adaptability). A common failure is optimizing the initial design at the cost of future adaptability, realizing too late that evolution is expensive, or over-designing for adaptability that is not needed during the system's actual lifecycle<!-- FACT-D35-056 -->[^saleh-mark-jordan-2009]*.

- **T3: Modular design and performance optimization.**
  Modular design often requires standardized interfaces and separation of concerns that reduce optimization opportunities. A custom-integrated design (tight coupling) can optimize globally: tuning one component affects another, allowing peak performance. A modular design must optimize each module independently, often yielding lower peak performance. A monolithic heat-sink design might exceed modular thermal management; tightly coupled control algorithms might outperform loosely coupled ones. The tension is between peak performance (integral design) and adaptability (modular design). A common failure is either sacrificing necessary adaptability for marginal performance gains, or building modular systems so loosely coupled that performance suffers unacceptably<!-- FACT-D35-057 -->[^suh-1990]*.

- **T4: Planned adaptability and unexpected change.**
  Design-for-adaptability plans for expected changes (e.g., "we'll need to upgrade this component in 5 years"). But unexpected changes (new regulations, material shortages, completely new requirements) often occur outside the planned adaptability mechanisms. A system designed for expected upgrades may not be adaptable to unexpected evolution. The tension is between over-investing in adaptation mechanisms (many of which are never used) and under-investing (new unexpected changes are expensive to accommodate). A common failure is discovering that the system's anticipated evolution path was wrong, and the adaptability investments don't help with the actual changes needed<!-- FACT-D35-058 -->[^henderson-clark-1990]*.

- **T5: Staged implementation and system integration.**
  Lifecycle adaptability often involves staged implementation (replace component A, then component B, then component C over time, rather than replacing the entire system at once). However, staged implementation can create version-mismatches and integration problems: component A expects version 2 interfaces, component C is still version 1, integration testing becomes complex. The tension is between the cost-savings of staged adaptation (no need to redesign the entire system at once) and the complexity of managing component version combinations. A common failure is either requiring complete system upgrades (losing the benefit of staged adaptation) to avoid version-mismatch complexity, or implementing staged upgrades with insufficient version management, creating fragile mixed-version systems<!-- FACT-D35-059 -->[^thomke-bell-2001]*.

- **T6: Designing for disassembly and structural integrity.**
  End-of-life disassembly and recycling benefit from modular design, easily separated components, and minimal bonding. However, bonding (welding, adhesives, permanent fastening) often provides superior structural integrity and performance compared to modular connections (bolts, snap-fits, modular interfaces). A car welded throughout is stronger and lighter than one with bolted modular subassemblies. The tension is between ease of disassembly and recycling (modularity) and structural performance (integral design). A common failure is either designing for perfect disassembly at the cost of mid-life performance, or optimizing structural performance and discovering that end-of-life disassembly is so costly that modular components are abandoned as waste<!-- FACT-D35-060 -->[^ellen-macarthur-2013]*.

prose:
_(Pass B — deferred)_

### Catalog cross-references (v1, batches 02–29)

Solution archetypes that reference this prime (per `solution_archetypes/_catalog/catalog_v1_batches_02_29.yaml`):

**As related prime (1):** `scale_transition_management`

notes: Design for Lifecycle Adaptability is grounded in systems engineering, product architecture, manufacturing engineering, and environmental sustainability. The formalization as an explicit design principle originated with the study of how product modularity affects manufacturing flexibility and lifecycle cost (Ulrich, Clark, Baldwin), evolved through design-for-disassembly and circular-economy thinking, and continues through digital and organizational systems. The principle interfaces with Modularity (adaptable systems require modular structures) and with Margin of Safety (excess capacity enables adaptation without performance loss). The concept increasingly intersects with sustainability (designing for disassembly and reuse reduces waste), with regulatory compliance (designing for regulatory evolution), and with technology forecasting (anticipating what technologies and standards will change). The practice is evolving from reactive maintenance (fix things when they break) toward proactive adaptation (design systems that gracefully evolve).


Design Patterns

one_liner: Reusable solutions.

aliases:
architectural patterns
reusable solutions
pattern_language

core_idea:
<!-- FACT-D51-361 -->[^alexander-1977][^gof-1994]
Design Patterns are a knowledge-capture and transmission methodology characterized by the systematic identification of recurring design problems across multiple independent instances of practice within a domain, followed by extraction and documentation of proven solutions in an abstraction-level that enables transfer across instances while remaining actionable in local contexts. The pattern format—which names the pattern, describes problem and context, specifies solution structure, enumerates consequences and trade-offs, and provides documented uses—originates in Christopher Alexander's architectural pattern-language work (Alexander, 1977), achieved canonical formalization through Gamma, Helm, Johnson, and Vlissides' *Design Patterns* in software engineering (Gamma et al., 1994), and has since generalized across domains including software architecture, urban planning, user-interface design, pedagogy, organizational design, game design, and security engineering. A design pattern encodes tacit practitioner knowledge into explicit, reusable, teachable form; it is fundamentally a device for converting and sharing experiential learning across teams and generations of practitioners.

structural_signature: The core structural primitive consists of: (1) problem recurrence—many design problems appear repeatedly across contexts; (2) solution stability—solutions to those problems share a core structure despite local variations; (3) abstraction capability—explicit documentation at an intermediate level of generality enables solution transfer without requiring full rediscovery; (4) template format—the pattern document itself (name, problem statement, context conditions, solution structure, consequences, known uses, related patterns) serves as a reusable transmission vehicle. A design pattern is not the solution itself but the documented *structure* of the solution, positioned at a level of abstraction that lies between universal principle and specific implementation, a positioning Alexander (1979) develops in *The Timeless Way of Building* as the central methodological move of pattern-language work.<!-- FACT-D51-362 -->[^alexander-1979] This signature manifests wherever a design domain has accumulated deep practitioner experience across many independent instances: architecture, software engineering, user-interface design, instructional design, organizational change management, game design, and narrative construction.

prose:
### Catalog cross-references (v1, batches 02–29)

Solution archetypes that reference this prime (per `solution_archetypes/_catalog/catalog_v1_batches_02_29.yaml`):

**As related prime (1):** `emergent_formalization`

notes: Alexander's *A Pattern Language* (1977) is the origin point; the Gang of Four *Design Patterns* (1994) is the canonical adaptation to software. The subsequent 30+ years of pattern literature in software, cloud infrastructure, security, pedagogy, and organizational design confirm that pattern-language thinking is a general knowledge-transfer device, not domain-specific. The discipline of identifying, documenting, and composing patterns is increasingly recognized as core to professional design practice across domains.


Design Prototyping

one_liner: Early models for testing.

aliases:
prototype
rapid prototyping
low-fidelity prototype
high-fidelity prototype
proof-of-concept
prototyping

core_idea: Design Prototyping is the intentional creation of preliminary, partial, or simplified versions of a product, system, interface, or structure for the explicit purpose of learning about feasibility, form, function, user interaction, or manufacturability before committing to full-scale production or implementation. The essential commitment is to *systematic risk reduction through tangible embodiment*: rather than relying solely on analysis, drawings, or imagination, the designer materializes design decisions (even incomplete or rough ones) in a form that can be tested, evaluated, and iterated upon with real users, manufacturing processes, or environmental conditions. Every prototyping effort specifies (1) the specific question or hypothesis the prototype is designed to answer (Does this ergonomic shape work? Can this algorithm execute in real time? Will users understand this mental model?), (2) the fidelity level or scope appropriate to that question (paper sketch, 3D-printed proof-of-concept, functional alpha, or near-production beta), (3) the intended stakeholders or evaluators (end users, manufacturing engineers, safety certifiers), and (4) the acceptance criteria or evidence that the question has been answered satisfactorily. The deeper insight is epistemological: the designer's understanding of whether a design will work evolves from abstract prediction toward concrete evidence, and prototyping collapses the gap between intention and reality by forcing the design into the world where assumptions can be tested and challenged. Prototyping originated in industrial design (automotive clay models, product styling studios, 1920s-1950s), but formalized as a disciplined design method in software (rapid prototyping, iterative user testing, 1980s-1990s, Xerox Alto, Apple's human interface philosophy) and later in systems engineering (digital simulation, hardware-in-the-loop testing) and organizational design (pilot programs, organizational structure experiments). The mechanism works because it surfaces failures, mismatches, and surprises at the prototype stage (when revision is affordable) rather than the production or deployment stage (when revision is costly or impossible). A prototype is not a small version of the final product; it is a learning tool, and the learning is often about what not to build as much as what to build<!-- FACT-D34-091 -->[^schrage-2000].

structural_signature:
- *The explicit formulation of the question or hypothesis the prototype is designed to test* <!-- FACT-D34-092 -->[^houde-hill-1997]
- *The selection of fidelity level or scope proportionate to the design question, rejecting both unnecessary realism and insufficient tangibility* <!-- FACT-D34-093 -->[^houde-hill-1997]
- *The materialization of design decisions into a testable embodiment (physical, digital, process-based, or organizational)* <!-- FACT-D34-094 -->[^schrage-2000]
- *The structured evaluation of the prototype against acceptance criteria or learning objectives, not merely informal impression* <!-- FACT-D34-095 -->[^otto-wood-2001]
- *The distinction between throw-away prototypes (used only for learning, discarded) and evolutionary prototypes (versions of the final product refined iteratively)* <!-- FACT-D34-096 -->[^sommerville-2010]
- *The cycle of prototype → test → learn → refine → iterate, with decision gates determining when prototyping is complete and production intent can be established* <!-- FACT-D34-097 -->[^sommerville-2010]

what_it_is_not:
- **Not the final product.** A prototype is a learning instrument; it may be discarded, repurposed, or evolved into production, but the prototype itself is not the shipping design. Confusing prototype with product leads to designs that are brittle, over-optimized for prototype scenarios, and untested at scale.

- **Not a complete design specification.** A prototype embodies some design decisions (form, interaction flow, material properties) and intentionally leaves others unspecified or rough. The decision to leave details unspecified is deliberate, not an oversight. A prototype that attempts to specify everything is not a prototype but a premature final design.

- **Not a substitute for user research or analysis.** Prototypes reveal how people interact with a design, but they do not replace systematic research into user needs, constraints, or mental models. A prototype validated with three users in a lab may not generalize to thousands of users in the wild. User research informs what to prototype; prototyping validates whether the research insights translated to workable designs.

- **Not a guarantee of success.** Prototyping reduces design risk by surfacing failures early, but it does not eliminate risk. A successful prototype does not guarantee a successful product. Environmental conditions, scale effects, manufacturing variations, or post-deployment context can reveal failures invisible in prototyping. Prototyping is risk *reduction*, not elimination.

- **Not costless or timeless.** Prototyping requires resources — materials, tools, labor, time. The cost-benefit trade-off between the cost of prototyping and the cost of failure without prototyping is real and must be evaluated. High-consequence designs (aerospace, medical devices, safety-critical systems) justify extensive prototyping; low-consequence designs (casual games, marketing collateral) may justify minimal prototyping. The decision to prototype is itself a design decision.

- **Not universally applicable.** Prototyping is most valuable when design uncertainty is high, when failure consequences are significant, or when user behavior is unpredictable. For highly specified, well-understood, low-risk designs (copy a known product), prototyping may add little value.

broad_use: Product design and development (automotive clay models to validate ergonomics and aesthetics before tooling; consumer electronics prototypes to verify manufacturability and thermal performance; furniture design using cardboard mockups or 3D models to assess spatial proportions), software and user-interface design (wireframe prototypes to validate information architecture before development; interactive prototypes to test user workflows and mental models; A/B testing as a continuous prototyping and evaluation cycle), architectural and built environment (scale models to visualize massing and spatial relationships; virtual-reality walkthroughs to test circulation flows and sightlines before construction; temporary installations to evaluate how buildings perform in context), organizational and policy design (pilot programs to test new organizational structures, workflows, or policies before organization-wide rollout; mock-ups of organizational changes to surface unintended consequences), drug development and pharmacology (early-stage cellular and animal models as prototypes of drug efficacy and safety before human trials; clinical trial design as iterative prototyping of dosing, delivery, and patient populations), infrastructure and systems engineering (hardware-in-the-loop simulation to prototype control-system behavior; field pilots of grid technologies or water systems before large-scale deployment), instructional design and pedagogy (lesson-plan pilots to refine teaching methods before full deployment; simulation environments to prototype learning experiences), industrial process engineering (process simulations and small-batch runs to prototype manufacturing sequences before full-scale production), and urban planning (temporary pop-up parks or street-design mockups to prototype civic changes before permanent infrastructure investment).

clarity: Naming prototyping explicitly signals a shift from imagined design to tangible design, from theoretical feasibility to empirical evidence. The act of prototyping forces specificity: vague ideas ("an intuitive interface") become concrete decisions ("users click here to navigate to settings"). The prototype becomes a shared reference artifact around which designers, engineers, users, and stakeholders can coordinate. It also creates a boundary: what is within the prototype scope (tested, validated) and what is outside (deferred, assumed). This boundary prevents the common failure mode where designs are assumed to work at every scale and in every context until deployment reveals otherwise. The clarity also manages stakeholder expectations: showing a rough prototype early signals "this is preliminary, this is intended to fail in some ways, feedback is welcome" differently than showing a polished mockup, which signals "this is nearly final, you should evaluate fitness for your needs."

manages_complexity: Complex systems (aircraft, vehicles, digital platforms, organizational structures) have too many interdependent variables to optimize by analysis alone. Prototyping decomposes the optimization problem into stages: prototype the most uncertain, highest-consequence components first (the ones whose failure would force a redesign); validate that they work; then move to lower-consequence components. This staged approach allows large teams to work in parallel: while one team prototypes the core engine concept, another prototypes the user interface, a third prototypes manufacturing feasibility. Prototypes also surface emergent properties that analysis missed — unexpected interactions, emotional responses, usage patterns — because humans and systems behave in ways not captured by specifications. By making those surprises visible in a prototype, the design team can adjust before scale.

abstract_reasoning: The analyst or designer asks: What is the core question this design must answer? Is it feasible? Will users understand it? Can we manufacture it? Can we operate it safely at scale? What fidelity of prototype is necessary to answer that question credibly — is a pencil sketch sufficient, or do we need a functional alpha? Who should evaluate the prototype — the design team, end users, manufacturing engineers, regulators? What acceptance criteria or learning objectives would constitute success: Does the prototype need to pass a performance test, or is understanding user interaction enough? What decision would be made based on the prototype result — proceed to full development, pivot the design, cancel the project? After the prototype is evaluated, what do we now know that we did not know before? Has the core uncertainty been reduced? What new uncertainties have the prototype revealed? Is another prototype cycle needed, or is the learning sufficient to proceed to implementation?

knowledge_transfer:
| Context | Prototype type | Question answered | Stakeholders | Fidelity |
| --- | --- | --- | --- | --- |
| Automotive design | Clay model | Does the form language work? | Design team, marketing | Low (shape only, no function) |
| Software interface | Wireframe mockup | Is information architecture clear? | UX/product team, users | Low (layout, no interaction) |
| Medical device | Working prototype | Can the mechanism function safely? | Engineers, regulators | Medium (functional but not at scale) |
| Urban planning | Pop-up installation | Do people use the space as intended? | City officials, residents | Medium (temporary, real context) |
| Manufacturing process | Pilot run | Can the process scale and hold tolerances? | Manufacturing, quality teams | High (near-production conditions) |
| Pharmaceutical | Animal model | Is the drug candidate safe and efficacious? | Researchers, regulators | Medium (biological model, not human) |
| Organizational change | Pilot program | Does the new structure improve outcomes? | Leadership, affected teams | Medium (limited scope, real operations) |

Transfer principle: the same diagnostic reasoning (formulate the question, choose fidelity appropriate to that question, structure evaluation around acceptance criteria, extract learning, decide next steps) applies across domains. A designer building a clay model, a software team building a wireframe, and an operations team running a pilot program are all executing the same disciplined process under different variable names.

formal_abstract:
Schrage (2000) in *Serious Play* documents the innovation practice of IDEO and argues that prototyping is a form of thinking, not a communication tool. When designers build prototypes, they are not illustrating pre-formed ideas; they are developing ideas through the act of building and testing. Schrage studies how physical prototyping (building models, sketching, testing, iterating) accelerates learning compared to meetings and discussions alone. His case studies show teams repeatedly discovering, through prototyping, that their mental model of "what users want" or "what is feasible" was incomplete. The deeper insight is that prototyping is an epistemic practice: it is how designers learn what is possible, what users actually need versus what they say they need, and what trade-offs are real versus imagined. Houde and Hill (1997) in "What Do Prototypes Prototype?" formalize the taxonomy: role (what is the purpose?), look-and-feel (what is the aesthetic and emotional experience?), implementation (what is the technical approach?), and integration (how does it interact with other systems?). A single prototype cannot answer all four questions simultaneously; effective teams build different prototypes for different questions (a visual model to answer look-and-feel, a working prototype to answer implementation). Buxton (2007) in *Sketching User Experiences* extends the framework, arguing that prototyping is a form of conversation between the designer and the design; the prototype "talks back," revealing what was assumed to be simple but is actually complex, what was feared to be impossible but is achievable<!-- FACT-D34-098 -->[^buxton-2007].

**Mapped back:** This instantiates the signature directly — the explicit formulation of the question the prototype answers (D34-092), the selection of appropriate fidelity (Houde-Hill taxonomy of role, look-and-feel, implementation, integration, D34-093), the materialization of design decisions (Schrage's emphasis on prototyping as thinking, D34-094), the structured evaluation against acceptance criteria (understanding what the prototype teaches, D34-095), and the distinction between throw-away prototypes (visual models discarded) and evolutionary ones (implementations refined toward production, D34-097).

applied_industry:
An automotive manufacturer designs a new vehicle interior, aiming for higher customer satisfaction in seat comfort and dashboard usability. The design team formulates multiple questions: (1) Does the ergonomic shape reduce fatigue on long drives? (2) Do customers understand the new gesture-control interface? (3) Can the seats be manufactured with the new materials within cost targets? For question 1, the team builds full-scale foam mockups of seats with various shapes and conducts a driving simulator study with 30 customers, each spending 4 hours in different seat configurations and rating comfort. Based on the prototype feedback, the team refines the lumbar curve and reduces seat width slightly. For question 2, the team builds an interactive digital prototype of the dashboard, including gesture recognizers and haptic feedback, and conducts a usability study with 20 users performing common tasks (change climate, adjust audio, navigate to destination). The prototype reveals that users gesture toward the windshield (interpreting the dash as a window) rather than the physical touch surface, requiring a redesign of gesture zones and visual affordances. For question 3, the team conducts a pilot manufacturing run using the new seat materials and assembly process, producing 100 seat units for validation testing. The pilot reveals tolerancing challenges in foam compression that require tighter quality control but do not require material substitution. Each prototype is scoped to answer a specific question; together, they de-risk the final vehicle design. A prototype that attempted to answer all three questions at once (a fully functional, hand-built pre-production seat) would be wastefully expensive and would not generate the specific learning needed for each design decision<!-- FACT-D34-099 -->[^otto-wood-2001].

**Mapped back:** Shows prototyping as iterative, multi-question discipline — each prototype scoped to a specific hypothesis (D34-092), fidelity chosen proportionate to the question (D34-093), materialized in testable form (D34-094), evaluated against structured acceptance criteria (user-rating scales, usability task completion, manufacturing tolerance validation, D34-095), and iteratively refined based on learning (D34-097).

title: Fidelity versus time-to-answer

body:
Higher-fidelity prototypes (fully functional, all features, production-ready aesthetics) provide more realistic data but take longer and cost more to build. Lower-fidelity prototypes (paper sketches, wireframes, single-feature alphas) can be built quickly and iterated rapidly but may not reveal scale effects, manufacturability issues, or real-world usage patterns. The tension is between the seductive promise of high-fidelity prototypes (they look like the real product, so feedback feels more credible) and the practical efficiency of low-fidelity prototypes (they answer the core question faster and cheaper). A common failure is over-investing in fidelity for questions that lower-fidelity prototypes could answer, delaying learning and burning resources<!-- FACT-D34-100 -->[^buxton-2007].

- **T2: Prototyping rigor versus exploration freedom.**
  Structured prototyping (formulating a hypothesis, defining acceptance criteria upfront, evaluating rigorously) maximizes learning and prevents confirmation bias. However, exploration (building without a specific question, seeing what emerges, playing with materials and ideas) generates novel ideas and unplanned discoveries. Some innovations arise from rigorous hypothesis-testing; others emerge from unstructured exploration. The tension is between the discipline that ensures learning is systematic and comparable, and the openness that enables serendipity. A common failure is either purely exploratory prototyping (building many things, learning nothing systematic) or purely rigid hypothesis-testing (missing the unexpected breakthroughs)<!-- FACT-D34-101 -->[^schrage-2000].

- **T3: User feedback validity and laboratory context.**
  Prototypes evaluated in a laboratory or controlled context (usability study, focus group) provide structured feedback but may not reflect how users actually interact in real-world contexts (noise, distractions, emotional stakes, social context, time pressure). Prototypes tested in real context (field trials, deployed alphas, in-the-wild evaluation) provide ecologically valid feedback but are harder to control, harder to interpret, and expensive to scale. The tension is between the internal validity of controlled evaluation (did we learn the actual truth about the design?) and the external validity (does the learning apply to real deployment?). A common failure is deriving strong conclusions from laboratory prototypes, then being surprised by real-world usage patterns<!-- FACT-D34-102 -->[^norman-1988].

- **T4: Prototype as learning tool versus prototype as stakeholder communication.**
  A prototype designed to maximize designer learning (rough, emphasizing unknowns, encouraging iteration) looks unfinished and may alarm stakeholders worried about quality or readiness. A prototype designed to communicate confidence to stakeholders (polished, aesthetically refined, looking production-ready) may suppress critical feedback because the polish implies that the design is further along than it actually is. The tension is between the honesty that invites iteration (rough prototype signals "this is early, please critique it") and the credibility that stakeholders trust (polished prototype looks like someone knew what they were doing). A common failure is a prototype that is rough enough to confuse stakeholders but polished enough to suppress their honest feedback<!-- FACT-D34-103 -->[^buxton-2007].

- **T5: Scope definition and feature creep.**
  A narrowly scoped prototype (test one feature, one user scenario) learns precisely but may miss interactions with features not included in the prototype. A broadly scoped prototype (multiple features, multiple scenarios) risks becoming so complex that you cannot tell what failed or why. The tension is between the clarity of narrow scope and the realism of broad scope. A common failure is adding features to a prototype "just to be complete" or "because it would be easy to include," turning a focused learning tool into a broad system whose failures are difficult to diagnose<!-- FACT-D34-104 -->[^sommerville-2010].

- **T6: Prototype fidelity and manufacturability mismatch.**
  A hand-built prototype may be beautiful and functional but use materials, tolerances, or assembly methods that cannot scale to production. A production-feasible prototype may look rough and awkward because it respects real manufacturing constraints. The tension is between prototyping for aesthetic and functional validation (building a version that looks and feels like the vision) and prototyping for manufacturability (building a version that respects process constraints). A common failure is validating a beautiful prototype and then discovering that the beauty cannot be economically manufactured, forcing a design pivot after stakeholder expectations have been set<!-- FACT-D34-105 -->[^otto-wood-2001].

prose:
_(Pass B — deferred)_

### Catalog cross-references (v1, batches 02–29)

Solution archetypes that reference this prime (per `solution_archetypes/_catalog/catalog_v1_batches_02_29.yaml`):

**As related prime (1):** `progressive_fidelity_increase`

notes: Design prototyping as a formal discipline originated in product design (industrial design studios, automotive styling, 1920s-1950s) but was formalized and theorized in software engineering (rapid prototyping as a response to the inadequacy of waterfall models; Sommerville 2010) and human-computer interaction (user-centered design, participatory design; Norman 1988, *The Design of Everyday Things*). The 1980s-1990s saw the explosion of rapid prototyping tools (digital design software, 3D printing, software frameworks for UI prototyping) which democratized prototyping and shifted it from an expert practice to a team-wide discipline. Contemporary prototyping integrates with Divergence-Convergence (prototyping as the activity that tightens the convergence loop), User Research (prototypes as vehicles for gathering behavioral data), and Design for Implementation (prototypes that test not just functional requirements but manufacturability and operational constraints). The concept of "fail fast" (rapid iteration through prototyping cycles) has become a cultural meme in tech and innovation, though this has sometimes obscured the deeper practice of structured prototyping with clear questions and acceptance criteria.


Designed-Out Misuse

one_liner: Affordances and defaults are arranged so the misuse path is costly or impossible while the legitimate path stays easy, preventing harm before enforcement has to act.

core_idea:
Designed-out misuse is the structural pattern in which an environment's affordances and defaults are arranged so that the misuse path is costly, unattractive, or impossible while the legitimate path remains easy — preventing harmful behaviour *before* enforcement, deterrence, or detection has to do any work.<!-- FACT-D61-801 -->[^norman-2013] The load-bearing distinction is asymmetry: the environment treats the misuse path and the legitimate path differently *by construction*, not by uniform restriction. A locked door asymmetrically blocks entry; a stair without a handrail uniformly burdens everyone. The discipline is to find the asymmetric move rather than the blunt one.

The pattern carries four structural commitments. **Asymmetric affordance treatment** — the environment makes the misuse path expensive while leaving the legitimate path unburdened. **Pre-enforcement temporal placement** — the intervention sits upstream of any monitoring, judgement, or sanction, so by the time an enforcement apparatus would normally fire, the misuse has already become structurally unattractive or impossible. **No actor-input dependency** — the intervention does not require the actor to be deterred, persuaded, attentive, well-informed, or even well-intentioned; the structural arrangement does the work regardless of actor state. **Legitimate-path preservation** — the legitimate use is not burdened proportionally; the wanted user moves freely while the unwanted path is selectively expensive. The prime's hardest constraint is the last: it is easy to suppress misuse by burdening everyone, and the degraded form, where no asymmetric move exists and the design collapses into general restriction, is exactly where most ethical critique lands. The framing is value-neutral as structure — the same asymmetric move that prevents child poisoning also enables hostile architecture against vulnerable populations<!-- FACT-D61-802 -->[^rosenberger-2017] — so the ethical evaluation is downstream of the structural recognition.

structural_signature:
*the affordance-and-default set of the environment* — *the misuse path and the legitimate path it distinguishes* — *the asymmetric treatment burdening one but not the other* — *the pre-enforcement temporal placement upstream of any monitoring or sanction* — *the independence from actor state* — *the legitimate-path-preservation constraint that separates selective design from uniform restriction*

A configuration exhibits designed-out misuse when each of the following holds:

- **An affordance-and-default set.** The environment presents a set of available actions, defaults, and paths of least resistance — road geometry, default configuration, connector shape, control layout — that an actor moves through.
- **A distinguished misuse path and legitimate path.** A normative line separates an unwanted (misuse) path from a wanted (legitimate) path; the pattern presupposes both a design intent and a category of "misuse" to be averted.
- **Asymmetric treatment.** The environment treats the two paths differently *by construction*, making the misuse path costly, unattractive, or impossible while leaving the legitimate path unburdened — the load-bearing move that distinguishes a locked door from a missing handrail.
- **Pre-enforcement placement.** The asymmetry sits upstream of any monitoring, judgement, deterrence, or sanction, so the misuse is structurally unattractive before an enforcement apparatus would normally act.
- **Actor-state independence.** The intervention does not require the actor to be deterred, attentive, informed, or well-intentioned; the structural arrangement does the work regardless of the actor's reflective state, which is what makes it robust where enforcement is fragile.
- **Legitimate-path preservation.** The legitimate use is not burdened proportionally — the wanted user still moves freely. This is the hardest constraint: without it the design collapses into uniform restriction, the degraded form where ethical cost concentrates.

The components compose so that an entire enforcement category can be retired by a one-time structural change, with the binding difficulty always the asymmetry: the configuration is well-formed only when a selective move burdens the misuse path while leaving the legitimate path free, and degraded whenever the only available move burdens everyone.

what_it_is_not:
- **Not `error_proofing_poka_yoke`.** Poka-yoke prevents
  *accidental* error by the well-intentioned operator;
  designed-out misuse blocks *intended or indifferent*
  misuse and is explicitly actor-state-independent. Poka-yoke
  is a special case scoped to accidental error.
- **Not `affordance`.** An affordance is the neutral fact of
  what an environment makes possible; this prime is the
  *deliberate asymmetric arrangement* of affordances to make
  the misuse path costly while the legitimate path stays
  free. Affordance is the material; this is the design move.
- **Not `no_one_is_above_the_rules`.** That concerns uniform
  *enforcement* of a rule after the fact; designed-out
  misuse sits *upstream of enforcement*, making the misuse
  structurally unavailable so no rule need be enforced.
- **Not `free_riding`.** Free riding is a misuse *to be
  prevented*; this prime is the *preventive structure*. One
  is the problem (under-contribution to a commons), the
  other a class of solution.
- **Not `lock_in`.** Lock-in raises the cost of *leaving* a
  chosen path; designed-out misuse raises the cost of *the
  misuse path specifically* while leaving the legitimate
  exit free. Lock-in is typically uniform, not selectively
  aimed at misuse.
- **Common misclassification.** Calling uniform restriction
  "designed-out misuse." A speed bump that wrecks ambulances
  or a cap arthritic adults cannot open burdens everyone;
  catch it by asking whether the legitimate user still moves
  freely — if the wanted path is burdened too, the design
  has collapsed into blunt restriction, not selective
  design-out.

broad_use:
- **Architecture and urban planning**: crime prevention through environmental design, defensible-space design, anti-skate fixtures, traffic-calming geometry that makes dangerous speeds physically uncomfortable.<!-- FACT-D61-803 -->[^newman-1972]
- **Cybersecurity**: secure-by-default configuration, least-privilege defaults, sandboxing, capability-based security<!-- FACT-D61-804 -->[^saltzer-schroeder-1975] — the misuse path costs exploitation effort while the legitimate path runs unmodified.
- **Product safety (poka-yoke)**: child-resistant caps, asymmetric connectors that fit only one way, dead-man switches<!-- FACT-D61-805 -->[^shingo-1986] — the wrong action is mechanically blocked while the right action is unchanged.
- **Public health policy**: reformulation driven by sugar taxes, indoor smoking restrictions, default-opt-in organ donation<!-- FACT-D61-806 -->[^thaler-sunstein-2008] — the harmful path acquires cost or friction while the healthy path stays the default.
- **Highway engineering**: narrowed lanes, raised crossings, and chicanes make dangerous speeds physically uncomfortable for the driver, not merely punishable.<!-- FACT-D61-807 -->[^ite-traffic-calming-1999]
- **Digital platform design**: anti-spam friction, rate limits, default-private settings — the abuse path costs the abuser more than the legitimate user.
- **Aviation cockpit design**: physically distinct shapes for flap, gear, and throttle controls so the wrong-lever misuse path is blocked at the hand rather than corrected by attention.<!-- FACT-D61-808 -->[^fitts-jones-1947]

clarity: The prime makes a single design question visible: which misuse classes are currently handled by downstream enforcement, and which could instead be handled by upstream structural asymmetry? It separates two otherwise-blurred regulatory stances — *detect-and-punish*, the enforcement stack, and *design-out-the-opportunity*, the structural stack — and gives designers a vocabulary for shifting load from the former to the latter. The clarifying separation is between interventions that depend on the actor's reflective state (deterrence, persuasion, attention) and interventions that work regardless of it (structural asymmetry); naming the second as a distinct category exposes that many "we need more enforcement" debates have a structural alternative that was never put on the table. The prime also clarifies *failures of design*: a system that relies entirely on enforcement to suppress a recurrent misuse has implicitly accepted that no asymmetric structural option exists — which is sometimes true and sometimes a missed opportunity, and naming the pattern forces that judgement into the open rather than leaving it as a default. Once named, every enforcement proposal admits the counter-question "could the affordance set be reshaped instead?"

manages_complexity: Designed-out misuse collapses a whole class of failure modes into a single structural intervention. Instead of monitoring every actor for every potential transgression — a policing load that scales as actors times transgressions — the designer pays a one-time structural cost (the asymmetric affordance) and the entire class of misuse becomes structurally unavailable or expensive. Traffic-calming geometry, for instance, retires an entire category of enforcement (speed cameras, traffic stops, awareness campaigns) by making the misuse path bodily uncomfortable; the complexity is *moved* from runtime monitoring to design-time analysis, and runtime monitoring shrinks to the residual cases the structure cannot handle. The intervention catalogue is portable across substrates: *raise-the-cost* (make the misuse path expensive), *remove-the-opportunity* (eliminate the affordance entirely), *channel-toward-default* (make the legitimate path the path of least resistance), *make-the-misuse-conspicuous* (force the misuse to advertise itself), and the shape constraint *preserve-the-legitimate-affordance* (the discipline that keeps the design from collapsing into uniform restriction). The compression is that a CPTED planner, a security engineer, a safety engineer, and a platform-policy analyst draw from the same five-move catalogue, so a move learned in one substrate transfers as an option in the next, and the recurring monitoring cost is replaced by a bounded structural-analysis cost.

abstract_reasoning: The prime enables a specific reasoning move: decompose the intervention space along the enforcement/design axis *before* choosing a control. Faced with a misuse problem, the analyst first asks "can the affordance set itself be made asymmetric in a way that disposes of this misuse class?" before asking "how do we detect and punish it better?" The structural option, where available, dominates because it requires no actor cooperation, no monitoring infrastructure, and no judgement at the point of action — its independence from actor state is what makes it robust where enforcement is fragile. The non-obvious consequence is that the right question is rarely "how do we deter this?" but "what asymmetric structural move makes the misuse path expensive while leaving the legitimate path free?", and the hardest part of answering it is the asymmetry constraint: a move that burdens everyone is structurally available but ethically and practically degraded, so the reasoning must explicitly seek the selective move and recognise when none exists. The reasoning generalises across any substrate with intentional actors, affordances, and a normative distinction between misuse and legitimate use — though that very dependence on intentional actors and a normative "misuse" category bounds the prime to human-design substrates, since the pattern cannot apply where there is no design intent and no normative line to draw.

knowledge_transfer: The move transfers across substrates as a recognisable family. A cybersecurity engineer reading about crime prevention through environmental design recognises sandboxing and capability-based security as the same asymmetric-affordance move in a different substrate; a traffic engineer designing a school zone borrows poka-yoke's asymmetric-mechanical-fit logic when designing chicanes that physically force slower speeds; a platform-policy analyst reading about traffic-calming recognises rate-limiting and default-private settings as the structural analogue of narrowed-lane geometry — an asymmetric environmental cost imposed on the misuse path. The role mappings transfer directly — *misuse class* ↔ speeding / exploitation / operator error / abuse / wrong-lever actuation; *legitimate path* ↔ lawful driving / normal use / correct operation / good-faith posting / correct control; *affordance set* ↔ road geometry / default configuration / connector shape / friction design / control layout; *asymmetric intervention* ↔ chicane / least-privilege default / keyed connector / rate limit / distinct grip. The intervention vocabulary — raise-cost, remove-opportunity, channel-default, make-conspicuous, preserve-legitimate — transfers as a checklist across all substrates, and the only substrate-specific work is finding the selective move that burdens the misuse path without burdening the legitimate one. The transferred and non-obvious lesson is that an entire enforcement category can often be retired by a one-time structural change, and that the binding difficulty is always the asymmetry: the value of the prime is that it forces the designer to look for the selective structural option before defaulting to monitoring, and to recognise honestly when the only available move is general restriction — the degraded form whose burden on legitimate users is where the ethical cost concentrates.

formal_abstract: Capability-based security in operating-system design is the prime in its cleanest engineered form, where the asymmetry is provable rather than behavioural. The *affordance-and-default set* is the set of operations a process can invoke. The *legitimate path* is a process accessing exactly the resources it was granted; the *misuse path* is a compromised or malicious process reaching resources it was never granted. The *asymmetric treatment* is structural: in a capability model, a process can only act on a resource if it holds an unforgeable token (a capability) for it<!-- FACT-D61-809 -->[^dennis-vanhorn-1966], so the legitimate path — using held capabilities — runs unmodified at full speed, while the misuse path — forging a reference to an ungranted resource — is not merely punished after the fact but *made impossible to express*. This sits *upstream of enforcement* (no runtime monitor watches for bad accesses; the access simply cannot be named) and is *independent of actor state* (the malicious code's intent is irrelevant — it has no token). The *legitimate-path-preservation* constraint is satisfied because least-privilege grants leave authorised work untouched. Contrast the degraded uniform-restriction form the prime warns against: a coarse "deny all network access" policy that also blocks the program's legitimate updates burdens everyone and is exactly the missing-handrail anti-pattern.<!-- FACT-D61-810 -->[^saltzer-schroeder-1975] **Mapped back:** the operation set is the affordance set, forging an ungranted reference is the misuse path made structurally costly-to-impossible while held-capability use stays free, and the whole arrangement works pre-enforcement and regardless of the attacker's sophistication — the asymmetric structural move rather than the blunt one.

applied_industry: Two physical-design instances show the same asymmetric move in genuinely different domains. First, traffic-calming geometry in a school zone: the *affordance set* is the road's physical layout. The *misuse path* is dangerous speed; the *legitimate path* is lawful, attentive driving. Rather than relying on speed cameras and patrols (the detect-and-punish enforcement stack, which depends on the driver's reflective state and scales as drivers-times-trips), the engineer installs chicanes, narrowed lanes, and raised crossings that make excessive speed *bodily uncomfortable* — an asymmetric environmental cost that falls on the misuse path while a careful driver at the posted limit passes unburdened. This is pre-enforcement, actor-state-independent (it works on the inattentive and the defiant alike), and it retires an entire enforcement category with a one-time structural cost. Second, poka-yoke in manufacturing and product safety: an asymmetric connector that physically fits only one way makes the wrong-assembly *misuse path* mechanically impossible while the correct assembly is unchanged; a child-resistant cap requires a push-and-turn coordination that an adult performs easily but a toddler cannot, burdening the misuse path selectively.<!-- FACT-D61-811 -->[^shingo-1986] In each, the binding difficulty is the prime's hardest constraint — finding the *selective* move. A speed bump that also wrecks ambulances, or a cap so stiff that arthritic adults cannot open it, has collapsed into uniform restriction<!-- FACT-D61-812 -->[^bix-2009], the degraded form where the burden on legitimate users becomes the locus of ethical and practical cost. **Mapped back:** road geometry and connector shape are the affordance sets; speeding and mis-assembly are the misuse paths made costly by construction; lawful driving and correct assembly are the preserved legitimate paths; and the discipline in both is to find the asymmetric move (chicane, keyed connector) rather than the blunt one that burdens everyone.