DGTLENG 202: Digital Twins in Practice
DGTLENG 202 · Lesson 5 of 5

Building a Decision Framework

From Data to Discipline

Having data is necessary but not sufficient. What transforms data into better engineering decisions is a framework — a repeatable, transparent process that connects evidence to choice.

The Decision Framework

1. Frame the Decision

Before analyzing anything, define:

  • What are we deciding? (Select a material, choose an architecture, approve a design change)
  • What are the alternatives? (At least two, otherwise it's not a decision)
  • What criteria matter? (Performance, cost, risk, schedule, manufacturability)
  • Who decides? (An individual, a review board, consensus)
  • When must we decide? (Deadlines constrain how much analysis is feasible)

2. Identify Data Sources

For each criterion, identify:

  • What data already exists in the model, simulation results, or operational history?
  • What data needs to be generated (new analysis, simulation runs, tests)?
  • What data is unavailable and requires expert judgment?

Be explicit about the mix. A decision that's 80% data-driven and 20% judgment is fine — as long as you know which 20% is judgment.

3. Analyze

Apply the appropriate level of analysis for each criterion:

  • Quantitative: Simulation, calculation, statistical analysis
  • Qualitative: Expert assessment, historical precedent, analogy
  • Risk-based: Probability × consequence, sensitivity analysis, Monte Carlo

Present results in a format that enables comparison across alternatives. Decision matrices, trade study tables, and spider charts all work — the format matters less than clarity.

4. Decide and Document

Make the decision. Then document:

  • What was decided
  • What alternatives were considered
  • What data supported the decision
  • What risks were accepted
  • Who approved it

This documentation isn't bureaucracy — it's the engineering equivalent of showing your work. Future engineers (including future you) will need to understand why this choice was made.

5. Monitor and Revisit

A decision is a prediction: "Given what we know now, this is the best choice." As new data arrives (from testing, operations, or further analysis), revisit the decision:

  • Are the assumptions still valid?
  • Is the system performing as predicted?
  • Have new alternatives emerged?

Decision Anti-Patterns

HiPPO (Highest Paid Person's Opinion)

The most senior person in the room declares the answer. Data exists but isn't consulted. This works when the HiPPO has deep relevant experience. It fails when the situation is novel or when the data contradicts intuition.

Analysis Paralysis

The team keeps analyzing, requesting more data, running more simulations — but never decides. Usually driven by fear of making the wrong choice. The fix: agree on decision criteria before analysis begins, and commit to deciding when those criteria are evaluated.

Confirmation Bias

The team has a preferred option and selects data that supports it while downplaying data that doesn't. Counter this by assigning a "red team" to argue for the non-preferred alternative, or by requiring blind evaluation (scoring alternatives before revealing which is which).

False Precision

Scoring alternatives to two decimal places when the underlying data has 20% uncertainty. The precision of the output should match the precision of the inputs.

Tools That Support Decision Frameworks

In the System Model

  • Parametric diagrams for quantitative criteria
  • Trade study views that compare alternative configurations
  • Requirements satisfaction analysis for compliance criteria

Standalone

  • Decision matrices (Excel, but connected to model data)
  • Bayesian networks for risk-informed decisions
  • Multi-criteria decision analysis (MCDA) tools

AI-Assisted

  • ML models that predict outcomes for alternatives based on historical data
  • Natural language analysis of stakeholder feedback to identify unstated criteria
  • Optimization algorithms that search the alternative space more thoroughly than humans can

Building the Habit

A decision framework isn't a one-time event. It's a practice. The organizations that make consistently good engineering decisions are the ones that:

  1. Apply the framework to every significant decision, not just the big ones
  2. Invest in data infrastructure so the right information is available when decisions need to be made
  3. Review past decisions to learn — not to blame, but to improve the framework itself
  4. Reward transparent reasoning, even when the outcome is imperfect

Assessment

Question 1 of 2Score: 0

What is the primary purpose of documenting engineering decisions?

Write a Python function that takes a list of design alternatives (each a dict with 'name' and criteria scores) and a list of weights, then returns the alternatives ranked by weighted score. Example: rank_alternatives([{'name': 'A', 'scores': [8, 6, 9]}, {'name': 'B', 'scores': [7, 9, 5]}], [0.3, 0.3, 0.4]) should return alternatives sorted by weighted total.

python