Decision Analysis, Preferences & Knowledge Models
Decision analysis separates alternatives, constraints, uncertain outcomes, criteria and preferences before choosing. Knowledge models make the reasoning inspectable, but no notation can manufacture valid preferences, causal evidence or a unique optimum where genuine trade-offs remain.
A decision problem is not “pick the largest score.” It consists of alternatives , uncertain states or scenarios , outcomes , constraints, criteria and a preference relation. Analysis makes those pieces explicit so that disagreement about facts is not confused with disagreement about values.
Feasibility before preference #
First remove alternatives that violate non-negotiable constraints. Then compare feasible outcomes. If criteria conflict, define dominance for a minimization problem: dominates when
with strict inequality for at least one criterion. The Pareto set contains feasible alternatives not dominated by another. Moving along its frontier exposes real trade-offs; the optimization has not yet supplied a preference between them.
flowchart TD A["Alternatives"] --> F["Feasibility constraints"] F --> O["Outcomes by scenario"] O --> P["Dominance and Pareto set"] P --> R["Preferences, risk and governance"] R --> D["Decision with rationale"]
Scalar scores are models of preference #
A weighted sum is meaningful only after direction, units and scales are normalized and the trade-off implied by each weight is defensible. Multiplying a criterion by 100 changes the result unless its weight changes inversely. A weight is not merely “importance”; it is a rate of substitution over the represented range.
Weighted sums can miss non-convex regions of a Pareto frontier. Thresholds and lexicographic rules express different preferences. Robust choice may prefer an alternative with slightly worse expected performance but smaller regret or downside under uncertain scenarios.
Perform sensitivity analysis: vary uncertain data, weights, thresholds and scenario probabilities. If a tiny plausible change reverses the ranking, report a fragile decision rather than a confident winner.
Preference relations need not form one ranking #
Pairwise preference can be incomplete when evidence or values do not support comparison. It can be intransitive when different considerations dominate different pairs. For collective choice, Arrow's result shows that apparently modest fairness conditions cannot all be satisfied by a universal ordinal aggregation rule over unrestricted preferences. The engineering lesson is not “voting is impossible”; it is that aggregation rules encode governance and have failure modes. Document who has authority, what information is aggregated and which properties the rule sacrifices.
Knowledge representations serve different questions #
Reasoning becomes inspectable when its facts and rules have a representation matched to the task:
| Representation | Best for | Main failure mode |
|---|---|---|
| decision table | finite combinations of conditions and actions | gaps, overlaps, hidden priority |
| production rules | local if–then operational knowledge | interaction and rule-order explosion |
| state machine | legal modes and event-driven transitions | poor fit for uncertain continuous quantities |
| frame/object schema | entities with slots, types and defaults | defaults mistaken for facts |
| graph/ontology | shared concepts and typed relations | ontology does not prove instance truth |
| probabilistic model | uncertainty and evidence update | probabilities and dependencies may be unjustified |
| optimization model | constrained trade-offs | objective can omit unmodeled values |
OMG DMN 1.5 standardizes decision requirements, decision tables and the FEEL expression language so operational decisions can be exchanged and tested. OWL 2 provides formally defined ontology semantics for classes, properties and individuals. They solve different problems: DMN evaluates a decision; an ontology defines and relates concepts. Neither establishes causal truth merely by formalizing a statement.
Worked decision skeleton #
Suppose three cooling designs differ in capital cost, peak temperature, energy use and serviceability.
- Reject any design that exceeds the safety temperature under a validated worst-case scenario.
- Carry measurement and model uncertainty into each outcome rather than comparing point estimates.
- Remove dominated designs.
- Ask decision owners to express acceptable energy–cost trade-offs and minimum serviceability, using ranges rather than ceremonial precise weights.
- Stress the surviving choice against scenario probabilities and weight ranges.
- Record the rule, data version, assumptions, rejected alternatives and trigger for reconsideration.
The output is a decision with a validity envelope. If the thermal load, energy price or safety constraint changes outside that envelope, rerun the analysis rather than treating the old ranking as knowledge.
Formal models are valuable because they make reasoning executable and reviewable. They are dangerous when the crisp output hides disputed boundaries, weak evidence or invented preferences.
Sources
- bookTheory of Systems and Systems Analysis: Lecture Coursepdfnotes
- docsOMG Decision Model and Notation 1.5
- paperK. J. Arrow — A Difficulty in the Concept of Social Welfare
- paperDeb et al. — A Fast and Elitist Multiobjective Genetic Algorithm: NSGA-II
- docsOWL 2 Web Ontology Language Overview