← Dynamic Systems Engineering Foundations · Semester 1, Week 11

Validation, Failure Analysis, and Model Improvement

Theme

A model is only useful if it remains connected to reality. This week teaches students that engineering does not end when a model is created. Models must be tested, challenged, and improved. Failure is not the opposite of engineering success — it is one of the primary sources of engineering knowledge.

Learning Objectives

By the end of this week, students should be able to:

Explain why validation is necessary.
Design tests for system models.
Identify model failures.
Analyze unexpected outcomes.
Improve systems through iterative refinement.
Document knowledge changes using engineering artifacts.

Core Vocabulary

Validation · Verification · Prediction · Experiment · Test · Failure Mode · Error · Deviation · Robustness · Sensitivity Analysis · Stress Testing · Root Cause · Revision

Fundamental Principles

Principle 1 — A model gains value through its ability to produce predictions.
A model that cannot be tested cannot be meaningfully improved. Validation isn't a final step tacked onto engineering — it's what makes the rest of the process worth doing.

Principle 2 — A failed prediction is not merely an error.
It reveals missing variables, incorrect assumptions, incomplete models, or unexpected interactions. Failure drives refinement — the same discipline established back in Week 1's core principles applies here in practice, not just in theory.

Principle 3 — When predictions fail, do not discard the information.
Analyze systematically: Was the observation wrong? Was the model incomplete? Was a variable missing? Was the causal relationship incorrect? Was the system boundary incorrect? Each question points to a different fix — conflating them wastes the failure instead of learning from it.

Principle 4 — A single passing test does not validate a model.
Real confidence comes from convergent evidence across different methods — experiments, historical testing, simulation, backtesting, direct observation. A model that only survives one kind of check hasn't really been tested yet, just asked one question.

Principle 5 — Revision must preserve history, not just overwrite it.
Every model update should keep the previous model, the new evidence that prompted the change, the reason for the revision, and its impact. A model that can't show its own history can't be trusted to have actually improved rather than just changed.

Anchor Example — Thermostat

Prediction: the room will reach the target temperature within a predictable window. Test: measure actual time-to-target across several runs. Failure mode: the room consistently overshoots the target before settling — revealing a missing variable (thermal lag in the walls) the original model didn't account for.

Anchor Example — Human Learning

Prediction: more practice problems will improve assessment scores. Test: compare score changes against practice volume. Failure mode: scores plateau despite increased practice — the real limiting variable turns out to be feedback quality, not practice quantity, which the original model conflated.

Anchor Example — AI Assistant

Prediction: a more detailed prompt will produce a more accurate response. Test: compare response accuracy across prompt specificity levels. Failure mode: accuracy stops improving past a certain detail level, and sometimes drops — revealing that prompt length and prompt clarity aren't the same variable, even though the original model treated them as one.

Anchor Example — Traffic

Prediction: adding a lane will reduce congestion. Test: measure travel times before and after. Failure mode: congestion returns to the same level within months — the model failed to account for induced demand, a feedback loop where added capacity attracts more drivers rather than just serving existing ones.

Anchor Example — Small Business

Prediction: a price cut will increase total revenue. Test: track revenue and volume after the change. Failure mode: volume increases but revenue drops — the model's assumed demand elasticity was wrong, and the failure reveals the real elasticity rather than just an error to dismiss.

AI Laboratory

Choose one anchor example above. Ask AI to design a validation test for its prediction, then ask it to generate three plausible failure modes before you look at the ones given here. Compare: did the AI's failure modes point to genuinely different root causes, or variations on the same one? A good failure-mode analysis should span different possible sources of error, not just restate the same doubt three ways.

Assignment

Select a real-world system and document: a specific, testable prediction the current model makes; how you would measure whether it held; at least three distinct failure modes and which root-cause category each belongs to (wrong observation, incomplete model, missing variable, incorrect causal link, wrong boundary); and how the model should be revised if each failure mode turned out to be real — while preserving what the model got right, not discarding it wholesale.

End-of-Week Competency

Students can design real tests for their models, treat a failed prediction as a specific, diagnosable event rather than a vague setback, and revise a model while keeping an honest record of what changed and why. This is the discipline the capstone in Week 12 depends on directly.

Built from real content already established elsewhere in this curriculum — Core Principles 8 and 9, the Research Methodology's failure-analysis and revision phases, and Week 12's validation phase — rather than generated independently of it, since the original source document for this week was incomplete.

Next: Week 12 — Capstone.