Skip to content

Decision Table or State Matrix

Artifact — instantiates Conjunctive Path Assurance

Tabulates every combination of the governing conditions against the action it demands, so the dangerous combination and the guard it must trigger are specified, not left implicit.

Search tools find dangerous combinations and tests exercise them; Decision Table or State Matrix is the artifact that specifies what the system must do about every one of them. It is a table whose rows are the governing conditions and whose columns are the combinations of those conditions, with each cell stating the required response — most importantly, which guard, trip, or interlock must fire. Its defining move is completeness by construction: because every combination of conditions gets its own column, an unspecified joint state shows up as a blank cell, and a contradictory one shows up as a clash — so the conjunction nobody thought about becomes visible as a hole in a grid rather than a latent surprise in the field. It is a static specification, not a search or a test.

Example

An infusion pump's safety logic is captured as a state matrix. The conditions are {occlusion detected, air-in-line detected, battery low, dose above soft-limit}. Each column is a combination, and each cell names the required response — e.g. occlusion AND dose-above-soft-limit → stop delivery, high-priority alarm, lock the keypad. Laying out all the combinations surfaces one that the firmware had left to default behaviour: air-in-line AND battery low at the same instant had no explicit rule, so the device would fall back to a low-priority alarm during exactly the moment it should escalate. The matrix turns that gap into a filled-in decision, and then becomes the specification the interlock software is verified against, cell by cell.

How it works

List the conditions and their levels; generate the combinations as columns (rules); for each, specify the demanded outcome and the guard it must trigger; collapse equivalent columns using "don't-care" entries to keep the table readable; then check two properties that are the whole point — completeness (every reachable combination has an explicit rule or an explicit default) and consistency (no combination maps to conflicting actions). What distinguishes it from the search and test mechanisms is that its value is in the specification itself: it makes the unspecified or contradictory joint condition — precisely the conjunctive gap — impossible to leave implicit.

Tuning parameters

  • Condition granularity — how finely each input is sliced (boolean versus multi-level). Finer captures more states but the column count grows combinatorially.
  • Rule reduction (don't-cares) — how aggressively equivalent combinations are merged. Aggressive reduction keeps the table legible but can bury a combination that actually matters inside a don't-care.
  • Completeness policy — whether every combination must carry an explicit rule or an explicit default action. Explicit-everywhere is safest and largest.
  • Action vocabulary — how expressive the response side is (a single trip versus graded, staged responses). Richer actions model reality better but complicate verification.

When it helps, and when it misleads

Its strength is that it makes the unspecified joint condition impossible to overlook — a missing rule is a blank cell — and it hands the guard logic a checkable, cell-by-cell specification. Its failure mode is combinatorial growth that makes large tables unwieldy, and over-aggressive rule reduction that can hide the dangerous combination in a don't-care; and the table is only as good as its condition list — a variable you left out simply has no row. The classic misuse is back-filling defaults to make the table "complete" without actually deciding the right action for the odd combination. The discipline is to derive the condition list from the hazard analysis rather than from convenience, keep reduction conservative around safety-relevant combinations, and review every blank and default cell on purpose.[1]

How it implements the components

  • edge_activation_predicate — each condition row is a predicate on a state variable; a column is the conjunction of those predicates.
  • combinatorial_coverage_plan — the completeness requirement is a coverage plan: every reachable combination must appear as a rule.
  • path_break_or_interlock_requirement — the response side specifies, per combination, exactly which guard or interlock must fire.

It specifies but neither runs nor searches: the empirical end_to_end_activation_oracle is Full-Factorial Joint-State Test's and the automated minimal_activating_conjunction_set is Boolean SAT or SMT Path Search's; and while it names which guard must fire, building that physical interlock belongs to Independent Interlock or Guard.

Notes

The table is a bridge artifact: its condition list should be inherited from the hazard analysis (a fault tree, a HAZOP), and its filled-in cells become the spec the interlock is built and tested against. Its correctness therefore depends on an input it does not produce — the list of conditions that matter.

References

[1] The cause-and-effect matrix is the standard form of this artifact in functional safety (e.g. under IEC 61511), mapping process causes to required protective actions; its discipline of demanding an explicit effect for every credible cause is what turns an unspecified conjunction into a visible blank. ↩