Independence pair in MC/DC: meaning and examples

An independence pair for a condition is two test cases that differ only in the value of that condition and produce different decision outcomes. It is the evidence MC/DC demands that the condition matters on its own.

For a condition c in a decision, an independence pair is a pair of admissible assignments identical except in c, one making the decision true and the other false. If such a pair exists, c can affect the outcome; if none exists, c is irrelevant to the decision, usually a bug in the rule. Because the two cases share all other values, the change in outcome is attributable to c alone. The engine searches the truth table for such a pair per input and reports it, or reports that none exists.

The artefact on this page is (member OR invited) AND NOT banned, true on rows 2, 4 and 6. The two assignments the checks report form an independence pair for invited: the tautology counterexample member = FALSE, invited = FALSE, banned = FALSE, where the decision is FALSE, and the satisfiable witness member = FALSE, invited = TRUE, banned = FALSE, where it is TRUE. Only invited changes between them. A pair for banned must keep member OR invited true, and a pair for member must keep invited false, since otherwise the other disjunct masks the change.

Independence pairs are how MC/DC test sets are built and how reviewers find dead conditions: an input with no pair cannot change the result, whatever the rule says in prose. Under assumptions, both cases of a pair must be admissible, which can remove pairs that the unconstrained table would offer. The term is confused with a pair of tests that merely differ in one input (the outcomes must differ too) and with the two outcomes of a decision, which need not come from related cases.

Example

allow := (member OR invited) AND NOT banned · output

Exact checks

Always true (tautology)? No Counterexample: member = F, invited = F, banned = F · Exhaustively checked and solver cross-checked · 1 rows

Always false (contradiction)? No Counterexample: member = F, invited = T, banned = F · Exhaustively checked and solver cross-checked · 3 rows

Can be true? Yes Example assignment: member = F, invited = T, banned = F · Exhaustively checked and solver cross-checked · 3 rows

Truth table (8 rows)

Independence pair in MC/DC: meaning and examples
#	member	invited	banned	allow
0	FALSE	FALSE	FALSE	FALSE
1	FALSE	FALSE	TRUE	FALSE
2	FALSE	TRUE	FALSE	TRUE
3	FALSE	TRUE	TRUE	FALSE
4	TRUE	FALSE	FALSE	TRUE
5	TRUE	FALSE	TRUE	FALSE
6	TRUE	TRUE	FALSE	TRUE
7	TRUE	TRUE	TRUE	FALSE

Plain-language reading

Beginnerallow is true exactly when both of the following hold:
1. at least one of member or invited is true (both may be true)
2. banned is false
In every other case, allow is false.
About the operators:
- AND is true only when all of its parts are true.
- OR is inclusive: it is true when at least one part is true, including when several are.
- NOT reverses a value: true becomes false and false becomes true.

Intermediateallow is true exactly when both of the following hold:
1. at least one of member or invited is true (both may be true)
2. banned is false
In every other case, allow is false.

Advancedallow is true exactly when both of the following hold [conjunction ∧]:
1. at least one of member or invited is true (both may be true) [inclusive disjunction ∨]
2. banned is false [negation ¬]
In every other case, allow is false.
Formal notation: (member ∨ invited) ∧ ¬banned

The common slip

Accepting a pair whose outcomes are the same. Two cases differing only in banned that both give FALSE show nothing; that happens when member and invited are both false, so the first conjunct masks banned. The other conditions must be set so that the one under test can be seen.

Questions

What does it mean if no independence pair exists for an input?

That no admissible change of that input alone ever changes the decision. Either the input is redundant in the rule, or the assumptions exclude the cases where it would matter. The engine reports the status per input so that the cause can be checked.

Glossary

Generated from the Tangibool engine, semantics tangibool-semantics/1, engine 1.0.0, build 2026-11-07. Every table, map, simplification and verdict on these pages was computed by the Tangibool engine when the site was built, and every claim was re-checked by the same exact checker the app uses. Limits are stated where they apply. © 2026 Foreranger LTD.