Combine Rules Without Hidden Conflicts
Two rules both apply to the same trip but disagree.
Read the full lesson and open its transcript below. A narrated video will be added after production.
What you will learn
Two rules both apply to the same trip but disagree.
A practical question
One rule says a rainy rush-hour trip needs review. Another says a familiar short route needs no warning. A trip can match both. Without a conflict policy, rule order inside the software may decide the result by accident.
The useful idea
Choose an explicit priority, a voting rule, or a modeled combination, and document the default when no rule matches. Test examples that match several rules, including disagreements near the warning threshold.
Work through the example
Show staff which conditions fired for one conflicting trip and which rule won. If they cannot predict the outcome from the written policy, revise the rule set before release. Keep conflict cases in regression tests. Two rules may both apply to a rainy rush-hour delivery and recommend different actions. Specify which takes priority, or how their outputs combine, before deployment. Build a small test set that triggers each rule alone and both together. If the combined system silently changes with rule order, document that behavior and have a dispatcher review it. Understandable individual rules do not guarantee an understandable decision when they interact. Now check the idea on a concrete example: Test overlapping rainy-and-rush-hour examples to see which outcome wins. A possible trap is worth naming: Hidden priority rules can produce surprising decisions. The answer follows from that evidence: A rule set needs explicit ordering or conflict resolution when several conditions match. Construct a rainy rush-hour trip that matches both rules and document which warning wins. Then change the rule order in a safe test and see whether the output changes. That visible conflict is easier to fix before it reaches dispatchers. Have a teammate follow the written priority order on several saved examples and compare their decisions with the software output. If they disagree, the rule set is not ready.
Limits and next step
Next, we'll add documented prior knowledge while checking that it was truly available at prediction time.
Worked example
Test overlapping rainy-and-rush-hour examples to see which outcome wins.
Quick check: test your understanding
Try it yourself: Consider this case: Test overlapping rainy-and-rush-hour examples to see which outcome wins. Explain how you would check the result. In your answer, address this limitation: Hidden priority rules can produce surprising decisions.
Check the reasoning
A rule set needs explicit ordering or conflict resolution when several conditions match. Hidden priority rules can produce surprising decisions.
What is the main idea behind combine rules without hidden conflicts?
A rule set needs explicit ordering or conflict resolution when several conditions match.
How is it used in the example?
Test overlapping rainy-and-rush-hour examples to see which outcome wins.
What limitation should be checked?
Hidden priority rules can produce surprising decisions.
Further reading
Machine Learning — Tom M. Mitchell.
Original ToolsInVision teaching examples. Editorial approach · Suggest a correction
Accessible referenceLesson 63 transcript306 words · Narration ready for the upcoming videoOpen transcript
One rule says a rainy rush-hour trip needs review. Another says a familiar short route needs no warning. A trip can match both. Without a conflict policy, rule order inside the software may decide the result by accident.
Choose an explicit priority, a voting rule, or a modeled combination, and document the default when no rule matches. Test examples that match several rules, including disagreements near the warning threshold.
Show staff which conditions fired for one conflicting trip and which rule won. If they cannot predict the outcome from the written policy, revise the rule set before release. Keep conflict cases in regression tests. Two rules may both apply to a rainy rush-hour delivery and recommend different actions. Specify which takes priority, or how their outputs combine, before deployment. Build a small test set that triggers each rule alone and both together. If the combined system silently changes with rule order, document that behavior and have a dispatcher review it. Understandable individual rules do not guarantee an understandable decision when they interact. Now check the idea on a concrete example: Test overlapping rainy-and-rush-hour examples to see which outcome wins. A possible trap is worth naming: Hidden priority rules can produce surprising decisions. The answer follows from that evidence: A rule set needs explicit ordering or conflict resolution when several conditions match. Construct a rainy rush-hour trip that matches both rules and document which warning wins. Then change the rule order in a safe test and see whether the output changes. That visible conflict is easier to fix before it reaches dispatchers. Have a teammate follow the written priority order on several saved examples and compare their decisions with the software output. If they disagree, the rule set is not ready.
Next, we'll add documented prior knowledge while checking that it was truly available at prediction time.