1. Mechanical Design Foundations and Systems Thinking

Introduction and Context

Mechanical design is the disciplined activity of converting a need into a physical system that performs specified functions safely, reliably, economically, and sustainably. It is more than selecting dimensions from a catalogue or calculating stresses in an isolated component. A successful design must reconcile competing requirements: strength and weight, performance and cost, precision and manufacturability, innovation and compliance, and present performance with future maintenance and disposal.

At postgraduate level, mechanical design is best understood as a systems activity. A component exists within an assembly; an assembly operates within a machine; and the machine interacts with users, infrastructure, software, energy sources, regulations, and the environment. A design decision made at one level can create consequences at another. Increasing shaft diameter may improve fatigue life but alter bearing selection, housing size, inertia, cost, and vibration behaviour. Systems thinking therefore complements conventional mechanics by asking not only whether a part can withstand a load, but whether the complete solution satisfies its intended purpose under realistic conditions.

This chapter establishes the foundations for the subject. It develops the engineering design process, requirements engineering, functional decomposition, constraints, standards, safety factors, uncertainty management, design reviews, and verification-and-validation planning. These ideas provide the framework for later study of machine elements, numerical analysis, optimization, materials, manufacturing, and reliability.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Describe the stages and iterative nature of the engineering design process.

2. Convert stakeholder needs into traceable, measurable engineering requirements.

3. Decompose a complex design into functions, subfunctions, interfaces, and physical solutions.

4. Distinguish requirements, constraints, assumptions, risks, and design variables.

5. Explain how standards, codes, regulations, and organizational procedures influence design decisions.

6. Select and interpret safety factors without treating them as arbitrary correction multipliers.

7. Manage uncertainty arising from loads, materials, manufacturing, models, and use conditions.

8. Plan design reviews and develop verification and validation strategies.

9. Apply systems thinking to practical mechanical design decisions.

Design as an Integrated Engineering Process

A design process begins with recognition of a need or opportunity. The need may be expressed by a customer, operator, maintenance department, regulator, or business unit. It is initially stated in nontechnical language—for example, “reduce the time required to position a heavy workpiece.” The designer must interpret this statement, identify stakeholders, establish boundaries, and transform it into a problem definition.

A useful generic process contains the following linked activities:

• need identification and problem definition;
• stakeholder and context analysis;
• requirements capture and prioritization;
• functional analysis and decomposition;
• generation of alternative concepts;
• preliminary modelling and trade-off analysis;
• detailed design and material/manufacturing decisions;
• prototype or production realization;
• verification, validation, and acceptance;
• operation, maintenance, feedback, and retirement.

The process is not strictly linear. Test results may reveal that a requirement was ambiguous; manufacturing analysis may require a change in geometry; or a hazard review may invalidate an attractive concept. Iteration is not evidence of poor design. Uncontrolled iteration is poor design. Professional practice distinguishes planned iteration, supported by records and decision criteria, from late rework caused by undocumented assumptions.

A design can be viewed as a sequence of decisions under constraints. At each stage the design team chooses among alternatives using evidence, models, experience, cost information, and risk assessment. Early decisions usually have high influence over lifecycle cost but are made with incomplete information. Consequently, the design process should resolve high-consequence uncertainties as early as practicable.

Problem Framing and Stakeholder Needs

Stakeholders include users, purchasers, operators, maintainers, manufacturers, owners, regulators, and people who may be affected by failure. Their interests may conflict. An operator may prefer low manual effort, a purchaser may emphasize initial cost, and a maintenance engineer may require access and modular replacement. Stakeholder analysis makes these perspectives visible before the design becomes committed to one interpretation.

A good problem statement defines the desired outcome without prematurely prescribing a solution. “Provide controlled vertical positioning of a 500 kg load over a specified travel range” is more useful at the concept stage than “design a hydraulic lift,” because it leaves hydraulic, electric, mechanical, and hybrid solutions open for comparison.

Requirements Engineering for Mechanical Design

Requirements engineering is the systematic process of eliciting, documenting, analyzing, prioritizing, allocating, and managing what a system must accomplish. It prevents a common design failure: producing a technically impressive object that does not solve the actual problem.

A requirement should normally be:

• necessary for the intended system;
• unambiguous, using terms with agreed meanings;
• measurable or objectively assessable;
• feasible within available technology and resources;
• traceable to a stakeholder need or governing obligation;
• consistent with other requirements;
• verifiable by analysis, inspection, demonstration, or test.

Requirements are often classified as functional, performance, interface, environmental, physical, safety, regulatory, manufacturing, maintenance, and lifecycle requirements. A functional requirement specifies what the system shall do. A performance requirement specifies how well it shall do it. For example, “the actuator shall position the platform” is functional, whereas “the platform shall reach the commanded position with an error no greater than 0.5 mm under the specified load” is a performance requirement.

A requirements statement should identify the subject, mandatory action, measurable criterion, operating condition, and verification method. A requirements table may contain an identifier, wording, rationale, source, priority, owner, verification method, and status. Identifiers support traceability: a safety requirement can be connected to a hazard, a subsystem, a calculation, a test, and an acceptance record.

Requirements must also be prioritized. The MoSCoW scheme—must, should, could, and will-not-for-this-release—can support stakeholder discussion, although safety and legal obligations cannot be traded away merely because they are inconvenient. Conflicting requirements require explicit negotiation. Weight, stiffness, cost, noise, and service life are frequently coupled; the design team should record the trade-off rather than hide it in informal decisions.

Requirements, Constraints, Assumptions, and Risks

These terms are related but not interchangeable. A requirement states what must be achieved. A constraint limits the available choices, such as a maximum envelope or mandated material. An assumption is a provisional belief used in analysis, such as a presumed load spectrum. A risk is the effect of uncertainty on objectives, often expressed through likelihood and consequence. An assumption should be reviewed because an invalid assumption can undermine an apparently rigorous calculation.

From Functions to Concepts

Functional decomposition breaks a system-level purpose into smaller functions that can be assigned, assessed, and realized. The decomposition should describe transformations of energy, material, information, or motion before naming a specific component. For a powered clamping system, the top-level function may be “secure workpiece.” Subfunctions could include receive command, generate force, transmit force, locate workpiece, detect clamp state, prevent release, and provide safe manual override.

This approach separates the question “What must happen?” from “What device will do it?” It encourages alternative concepts and reduces premature commitment. Each function has inputs, outputs, flows, and interfaces. A function structure can reveal missing provisions: a concept that generates clamping force but does not indicate force confirmation or failure containment is incomplete.

Once functions are established, physical principles and components can be mapped to them. Morphological charts are useful for displaying alternative means for each subfunction. For example, force generation might use a screw, pneumatic cylinder, hydraulic cylinder, or electric linear actuator. Combining alternatives produces concepts that can be screened against requirements, risks, cost, manufacturing capability, maintainability, and environmental conditions.

Interfaces deserve special attention. Mechanical interfaces transmit forces and moments; thermal interfaces transfer heat; electrical interfaces provide power and signals; human interfaces shape operation and error likelihood. Many system failures occur not within a component but at an interface—for example, inadequate alignment, incompatible tolerances, poor sealing, or an ambiguous control signal.

Constraints, Trade-offs, and Design Decisions

Design constraints may be physical, economic, temporal, regulatory, organizational, environmental, or technological. Some are hard constraints, such as a statutory safety requirement or maximum installation envelope. Others are objectives to be optimized, such as minimizing mass or lifecycle cost. Confusing objectives with constraints can lead to inappropriate decisions. A lightweight design is not acceptable if it fails a mandatory fatigue-life requirement.

Design variables are quantities the designer can select or adjust: diameter, thickness, material, geometry, gear ratio, tolerance, control law, or process route. State variables describe the condition of the system, such as temperature, displacement, stress, or speed. Parameters are treated as fixed during a particular analysis but may be changed at a higher design level.

Trade-off studies should use explicit criteria. A weighted decision matrix can compare concepts, but numerical scores are not objective facts; they reflect chosen criteria and stakeholder judgments. Sensitivity analysis is valuable: if a small change in a criterion reverses the preferred concept, the decision is fragile and deserves further investigation. Multi-objective optimization may produce a Pareto frontier, where improvement in one objective requires sacrifice in another. The final selection remains an engineering and organizational decision, not merely a mathematical result.

Standards, Codes, and Professional Responsibility

Standards provide agreed terminology, design rules, test methods, dimensions, tolerances, and procedures. Codes and regulations may impose legally enforceable requirements. Company standards may define approved materials, documentation, inspection, and configuration-control practices. Standards improve interoperability and reduce avoidable uncertainty, but compliance with a standard does not automatically prove that a design is safe or suitable for every application.

The designer must identify the applicable jurisdiction, edition, scope, and hierarchy of requirements. A standard may be advisory in one context and mandatory through a contract or regulation in another. Design records should state which documents were used and how deviations were addressed. Blindly copying a familiar coefficient or dimension is dangerous when the loading, failure mode, material condition, or operating environment differs from the standard’s assumptions.

Professional responsibility includes protection of public safety, honest communication of uncertainty, competence within one’s technical authority, and escalation of unresolved hazards. A designer must not conceal a failed test by changing acceptance criteria after the result is known. Configuration control is also an ethical issue: releasing an unreviewed drawing or analysis can expose users and the organization to preventable harm.

Safety Factors and Failure Criteria

A safety factor expresses the margin between a limiting capacity and a design demand. In a simple strength calculation,

N = limiting strength / design stress.

The expression is useful only when the numerator, denominator, failure mode, and conditions are clearly defined. Yield strength, ultimate strength, buckling load, fatigue strength, wear limit, and thermal limit are not interchangeable. A shaft may have a large static strength margin but inadequate fatigue life or excessive torsional deflection.

Safety factors account for variability and modelling limitations, but they should not be used as a substitute for understanding. Sources of uncertainty include material scatter, geometric variation, load estimation, stress concentration, residual stress, environmental degradation, manufacturing defects, and model idealization. A single global factor may be inappropriate when uncertainties differ substantially across failure modes.

The selection of a factor should consider consequence of failure, uncertainty, type of loading, ductility, inspection capability, redundancy, applicable standards, and the maturity of the design. Reliability-based design treats uncertain quantities statistically and seeks a target probability of failure. Limit-state design distinguishes factored loads from factored resistances and can provide a more transparent treatment of variability. In either approach, the factor and its rationale must be documented.

Failure-mode thinking is essential. Typical modes include yielding, fracture, fatigue, buckling, wear, seizure, corrosion, excessive deformation, thermal failure, leakage, loss of stability, and human misuse. A failure mode and effects analysis (FMEA) ranks modes using severity, occurrence, and detectability or equivalent risk measures. FMEA is most effective when it leads to design action, such as eliminating a hazard, adding containment, improving inspection, or providing a clear warning.

Uncertainty Management and Model Credibility

No engineering model is perfectly accurate. Uncertainty may be aleatory, arising from natural variability, or epistemic, arising from limited knowledge. Examples include variable payloads, uncertain friction coefficients, incomplete load histories, and simplified boundary conditions in finite-element models.

A sound analysis begins by identifying influential assumptions. Deterministic sensitivity analysis varies one or more inputs to determine which parameters dominate the result. Probabilistic methods assign distributions where evidence supports them and propagate uncertainty to outputs. Monte Carlo simulation, response surfaces, and reliability methods are useful for complex systems, but sophistication does not compensate for poor input data.

Model verification asks whether the equations, code, mesh, or implementation have been used correctly. Model validation asks whether the model represents the real system adequately for its intended purpose. A finite-element model can be verified through mesh-convergence studies and benchmark solutions yet remain invalid if joints, contact, damping, or boundary conditions are unrealistic. Validation evidence may include component tests, prototype measurements, field data, or comparison with established physical behaviour.

The appropriate model depends on the decision. A hand calculation may be sufficient for concept screening; a detailed nonlinear analysis may be justified for a critical pressure vessel. Model fidelity should increase when consequences, nonlinearities, uncertainty, or novelty increase. Every analysis report should state purpose, assumptions, inputs, methods, limitations, results, and decision relevance.

Verification, Validation, and Acceptance Planning

Verification asks, “Did we build the system right?” Validation asks, “Did we build the right system?” Verification demonstrates conformity to specified requirements. Validation demonstrates fitness for intended use in the relevant operational context. Acceptance is the formal decision that evidence satisfies contractual or organizational criteria.

Verification methods commonly include:

• inspection, such as checking dimensions or material certificates;
• analysis, such as stress, kinematic, thermal, or tolerance calculations;
• demonstration, in which operation is observed under defined conditions;
• test, using measured performance under controlled conditions.

A verification-and-validation matrix links each requirement to its method, procedure, equipment, conditions, acceptance criterion, responsible person, and evidence record. Planning must begin early. If a requirement cannot be tested because no suitable load fixture, sensor, environment, or measurement uncertainty is available, the requirement is not yet well engineered.

Measurement systems must be considered. An acceptance criterion should be meaningfully larger than the uncertainty of measurement, or the uncertainty should be incorporated into the decision rule. Test conditions should represent intended use, including temperature, duty cycle, misalignment, transient loads, operator interaction, and foreseeable misuse where relevant. Tests should be reproducible and configuration-controlled.

Design Reviews and Decision Governance

Design reviews are structured decision points at which an interdisciplinary team evaluates maturity, risks, requirements, interfaces, evidence, and readiness to proceed. A concept review may compare alternatives; a preliminary design review may assess architecture and principal calculations; a critical design review may authorize detailed release; and a production or readiness review may assess manufacturing and test capability.

An effective review is not a ceremonial presentation. It has defined entry criteria, independent preparation, evidence-based discussion, recorded actions, owners, deadlines, and exit criteria. Reviewers should examine assumptions and failure modes, not only polished drawings. Independence is valuable because the person who created a design may unconsciously defend it. Review findings should be classified by severity and closure should require objective evidence.

Configuration management supports governance. Drawings, models, analysis files, software versions, materials, and test articles must be identifiable. Changes should be assessed for effects on requirements, interfaces, safety, manufacturing, and validation. A small geometry change can invalidate a stress analysis or alter a tolerance stack.

Illustrative Case: Redesign of a Powered Workholding Fixture

Background

An illustrative manufacturing company uses a powered fixture to hold aluminium housings during machining. Operators report variable clamping quality and occasional difficulty releasing parts. The original fixture was designed around nominal dimensions and has been modified several times without a complete requirements record.

Situation and Problem

The fixture must hold the workpiece against cutting forces without distortion, release reliably after machining, and permit rapid loading. The existing design uses a pneumatic cylinder and a toggle mechanism. It lacks direct confirmation that the clamp has reached the required position, and the maintenance team has observed wear at a pivot pin.

Analysis

The team first identifies stakeholders: operators, production engineering, maintenance, quality assurance, and safety personnel. Requirements are rewritten in measurable form: the fixture shall resist the specified cutting-force envelope with a defined margin; shall not deform the workpiece beyond the permitted tolerance; shall indicate a confirmed clamped state; shall release within the target time; and shall remain safe after loss of air pressure.

Functional decomposition identifies locating, supporting, force generation, force transmission, state detection, release, and energy isolation. A hazard review identifies ejection, unexpected release, pinch points, and incorrect seating. Analysis of the pivot reveals combined shear, bending, bearing stress, and fatigue rather than simple static shear alone. A tolerance study shows that accumulated variation can prevent the toggle from reaching a reliable over-centre position.

Approach and Solution

The team compares three concepts: retaining the toggle with improved sensing, replacing it with a wedge mechanism, and using a mechanically locking electric actuator. The first concept has the lowest change cost, while the second offers better passive retention but requires more precise surfaces. The selected design retains the pneumatic actuator but adds a positive mechanical lock, a clamp-position sensor, a pressure-loss response, replaceable hardened pivot bushings, and an improved tolerance scheme.

Verification is planned through dimensional inspection, actuator-force analysis, a fixture deflection test, repeated-cycle testing, loss-of-pressure testing, and machining trials using representative workpieces. Validation requires operators to load parts under normal production conditions and quality personnel to confirm that the machining result remains within specification.

Outcome

The redesign is not judged successful merely because the cylinder produces adequate force. It is successful when the integrated fixture holds, detects, protects, releases, and can be maintained under actual use. The case illustrates why system boundaries, interfaces, failure modes, and validation context matter as much as component calculations.

Learning Points

The principal lessons are that requirements should precede detailed geometry, functional decomposition exposes missing functions, fatigue and wear may govern before static strength, and verification must be linked to intended operation. The case also demonstrates the value of configuration control when a previously modified product is being redesigned.

Common Errors and Practical Best Practices

Frequent design errors include accepting vague requirements, assuming nominal loads, selecting a material before understanding the function, applying one safety factor to every failure mode, ignoring interfaces, treating computer output as proof, neglecting maintenance, and testing only idealized conditions. Another error is optimizing a subsystem while degrading total-system performance.

Best practice is to maintain a live requirements-and-verification matrix; record assumptions with owners and review dates; identify critical characteristics; use independent checks for safety-significant work; involve manufacturing and maintenance early; design for inspection and repair; perform sensitivity studies on uncertain inputs; and preserve traceability from need to requirement, function, design feature, analysis, test, and release decision.

Digital engineering tools can strengthen these practices. Product lifecycle management systems connect requirements, CAD, bills of materials, revisions, and nonconformances. Simulation automation can explore design spaces, while digital twins may compare predicted and measured operating behaviour. Machine learning can assist anomaly detection or surrogate modelling, but it does not eliminate the need for physical understanding, representative data, explainability, cybersecurity, and controlled validation. Automated optimization must remain bounded by manufacturability, safety, and applicable standards.

Emerging mechanical systems increasingly combine structures, sensors, actuators, control software, connectivity, and adaptive materials. This cyber-physical character expands the design boundary. Mechanical designers must understand data integrity, software interfaces, human factors, and update control in addition to classical stress and motion. Sustainability is similarly becoming a design requirement: material efficiency, energy use, repairability, remanufacturing, and end-of-life recovery should be considered across the lifecycle rather than after the geometry is finalized.

Chapter Summary

Mechanical design is an iterative process of transforming stakeholder needs into a safe, useful, manufacturable, and maintainable system. Systems thinking broadens attention from isolated components to functions, interfaces, environments, users, and lifecycle consequences. Requirements must be clear, measurable, prioritized, and traceable. Functional decomposition supports concept generation without premature commitment to hardware, while constraints and trade-offs guide selection among alternatives.

Standards and regulations establish important boundaries but do not replace engineering judgment. Safety factors must be tied to specific failure modes and sources of uncertainty. Verification establishes conformity to requirements; validation establishes suitability for intended use. Design reviews, configuration control, risk analysis, and verification planning provide governance and reduce late failures. Digital tools can improve traceability and analysis when their assumptions, data, and outputs are critically managed.

Key Terms

Requirements engineering: The process of eliciting, specifying, allocating, and managing system requirements.

Functional decomposition: Breaking a system purpose into interacting functions and subfunctions.

Constraint: A limitation that restricts permissible design choices.

Design variable: A selectable quantity, such as diameter, thickness, or material.

Stakeholder: A person or organization affected by, interested in, or responsible for a system.

Traceability: The ability to connect needs, requirements, design features, analyses, tests, and decisions.

Interface: A boundary across which forces, energy, information, material, or constraints are exchanged.

Safety factor: A ratio expressing margin between a limiting capacity and a defined demand.

Failure mode: A manner in which a component or system can fail to perform its intended function.

FMEA: A structured analysis of failure modes, effects, causes, and controls.

Uncertainty: Imperfect knowledge or variability affecting an engineering result.

Model verification: Confirmation that a model or implementation has been constructed and used correctly.

Model validation: Confirmation that a model represents the real system adequately for its intended use.

Verification: Demonstration that specified requirements have been met.

Validation: Demonstration that the system satisfies its intended operational purpose.

Design review: A formal, evidence-based evaluation of design maturity and readiness.

Configuration management: Control and identification of product definitions and changes.

Lifecycle: All stages from need identification through operation, maintenance, and retirement.

Pareto frontier: A set of alternatives for which improving one objective requires worsening another.

Critical characteristic: A feature whose variation can significantly affect safety, performance, or compliance.

Review Questions

Short Answer Questions

1. Why is mechanical design considered a systems activity rather than only a component-sizing activity?

2. State four qualities of a well-written engineering requirement.

3. Distinguish a requirement from an assumption and a constraint.

4. What is the difference between verification and validation?

5. Why should safety factors be associated with specific failure modes?

Long Answer Questions

1. Explain the iterative engineering design process from need identification through lifecycle feedback.

2. Describe how functional decomposition and morphological analysis support concept generation.

3. Discuss the principal sources of uncertainty in mechanical design and methods for managing them.

4. Explain the role of standards, regulations, professional responsibility, and configuration management in design governance.

5. Describe how a verification-and-validation matrix should be developed and used.

Analytical / Application Questions

1. A rotating shaft meets its static yield criterion but fails after several months of service. Analyze the likely limitations of the original design approach and propose a revised investigation.

2. Develop a functional decomposition for an automated lifting table, including energy, sensing, safety, and maintenance functions. Identify two important interfaces.

3. A design team proposes reducing a bracket’s mass by 25% using topology optimization. Specify the requirements, constraints, verification activities, and validation evidence needed before release.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes validation from verification in mechanical design?

A. Validation checks whether calculations use correct units, while verification checks customer satisfaction.

B. Validation demonstrates fitness for intended use, while verification demonstrates conformity to specified requirements.

C. Validation is performed only by manufacturers, while verification is performed only by regulators.

D. Validation applies to components, while verification applies only to complete systems.

Correct Answer: B. Validation demonstrates fitness for intended use, while verification demonstrates conformity to specified requirements.

Question 2

A designer states, “The actuator shall provide sufficient force.” What is the principal weakness of this requirement?

A. It is too detailed for a concept-stage requirement.

B. It identifies a verification method but no stakeholder.

C. It is not measurable because the force and operating conditions are unspecified.

D. It is a constraint rather than a requirement.

Correct Answer: C. It is not measurable because the force and operating conditions are unspecified.

Question 3

What is the main purpose of functional decomposition?

A. To select a material before defining system objectives.

B. To break a system purpose into functions without prematurely fixing physical solutions.

C. To replace all physical testing with mathematical modelling.

D. To maximize the number of components in an assembly.

Correct Answer: B. To break a system purpose into functions without prematurely fixing physical solutions.

Question 4

Which situation most clearly represents an interface-related design risk?

A. A material has a known elastic modulus.

B. A shaft has a calculated nominal diameter.

C. A sensor signal is interpreted differently by the controller and the safety system.

D. A drawing contains a properly identified revision number.

Correct Answer: C. A sensor signal is interpreted differently by the controller and the safety system.

Question 5

Why is applying one large global safety factor to every failure mode often inappropriate?

A. Safety factors are relevant only to electrical systems.

B. Different failure modes have different uncertainties, consequences, and limiting criteria.

C. A global factor always produces an under-designed component.

D. Standards prohibit the use of safety factors.

Correct Answer: B. Different failure modes have different uncertainties, consequences, and limiting criteria.

Question 6

Which activity primarily addresses model verification?

A. Comparing predicted vibration with field measurements from the intended machine.

B. Checking a finite-element implementation against a benchmark solution and performing mesh studies.

C. Interviewing operators about ease of use.

D. Confirming that a purchaser accepts the product.

Correct Answer: B. Checking a finite-element implementation against a benchmark solution and performing mesh studies.

Question 7

A design review is most effective when it:

A. focuses on polished presentations and avoids unresolved assumptions.

B. is held only after production has begun.

C. uses defined entry and exit criteria, evidence, recorded actions, and accountable owners.

D. allows acceptance criteria to be changed after an unsuccessful test.

Correct Answer: C. uses defined entry and exit criteria, evidence, recorded actions, and accountable owners.

Question 8

Which is the best example of a constraint rather than a performance objective?

A. Minimize lifecycle energy consumption.

B. Reduce assembly time by 15 percent.

C. Fit within the existing installation envelope.

D. Increase fatigue life beyond the target value.

Correct Answer: C. Fit within the existing installation envelope.

Question 9

In the illustrative workholding-fixture case, why was direct clamp-state detection valuable?

A. It eliminated the need for any mechanical strength analysis.

B. It addressed an interface and safety risk by confirming that the intended clamped condition had been reached.

C. It guaranteed that the workpiece could never be distorted.

D. It allowed the fixture to operate without an energy source.

Correct Answer: B. It addressed an interface and safety risk by confirming that the intended clamped condition had been reached.

Question 10

Which statement reflects sound uncertainty management?

A. Use a more sophisticated model regardless of data quality.

B. Ignore uncertainty when the nominal result satisfies the requirement.

C. Identify influential assumptions, perform sensitivity analysis, and increase model fidelity when consequences justify it.

D. Replace all tests with probabilistic simulation.

Correct Answer: C. Identify influential assumptions, perform sensitivity analysis, and increase model fidelity when consequences justify it.