A decision has ten parts: a trigger, a question, the context it needs, the options available, the constraints that limit them, the objective used to compare them, the evidence behind the choice, the authority that approves it, the action that executes it, and the outcome used to judge it. Decision modeling makes all ten explicit.
The ten parts
| # | Part | Question it answers | Example (maintenance) |
|---|---|---|---|
| 1 | Trigger | What starts the decision? | Vibration on K-301 exceeds 7.1 mm/s |
| 2 | Question | What exactly must be decided? | When and how to service K-301? |
| 3 | Context | What must be known? | Production plan, spares, slowdown calendar, history |
| 4 | Options | What could we do? | Run on / swap bearings in slowdown / shut down now |
| 5 | Constraints | What is not allowed? | Safety limits, contract volumes, crew availability |
| 6 | Objective | How are options compared? | Minimize expected cost incl. lost production and risk |
| 7 | Evidence | Why this option? | Wear signature match 91%, 3 similar failures |
| 8 | Authority | Who may decide? | Reliability engineer approves; ops informed |
| 9 | Action | What happens in systems? | Work order in CMMS, schedule change in MES |
| 10 | Outcome | Did it work? | Unplanned downtime avoided; cost vs forecast |
Why model decisions explicitly?
Undocumented decisions cannot be audited, automated safely, handed over, or improved. The moment you write down the ten parts, gaps become visible: a missing owner, an objective nobody agreed on, context that is never available in time. Gartner’s view is that by 2030 explicitly modeled decisions will be five times more trusted and 80% faster than ungoverned ones.
Types of decisions
Strategic
Rare, high-impact, novel — e.g. building a plant. Human-led; DI supplies scenarios and evidence.
Tactical
Periodic, bounded — e.g. monthly production mix. Augmented with optimization and simulation.
Operational
Frequent, repeatable — e.g. reroute a load, triage a claim. The sweet spot for decision intelligence and automation.
Real-time
Milliseconds to seconds — e.g. robot path, fraud hold. Automated inside strict envelopes with human oversight on the loop.
Notation and standards
Teams often use the OMG Decision Model and Notation (DMN) standard to express decision logic and requirements, alongside causal decision diagrams that link actions to outcomes. The notation matters less than the discipline: every decision should have a readable model that business owners can review and that software can execute.
Decision modeling checklist
- Name the decisionUse a verb and an object: “Allocate supplier volume”, “Route prior-auth request”.
- Name one ownerA role, not a committee. See decision ownership.
- List options, including ‘do nothing’Doing nothing is always an option and needs a cost.
- Write constraints as rulesHard constraints are non-negotiable; soft ones carry a penalty.
- Choose the objectiveMake trade-offs explicit: cost vs service vs risk.
- Define the outcome metric and horizonWhat will you measure, and when?
- Every decision has ten parts; most organizations document two or three.
- Explicit objectives and constraints end ‘expert disagreement’.
- Operational, frequent decisions are the best place to start.