Use Prior Knowledge Carefully
A dispatcher knows that a certain bridge closes every spring.
Read the full lesson and open its transcript below. A narrated video will be added after production.
What you will learn
A dispatcher knows that a certain bridge closes every spring.
A practical question
The dispatcher knows a bridge closes for maintenance each spring. That schedule can be useful prior knowledge if it was published before the affected trips. Add it as a time-specific feature or a documented rule and test whether it improves warnings.
The useful idea
Do not quietly use a later record saying which deliveries actually encountered the closure. That is future information, even if it lives in the same database. Distinguish a planned closure from an unexpected one and keep the source and publication time.
Work through the example
Compare the original model with one that includes the available schedule, using a future held-out period. Inspect both the bridge routes and unrelated routes for errors. A known road closure can be valuable prior knowledge, but only if its schedule was available when the trip was planned. Add it to the training recipe with a clear timestamp, then evaluate later deliveries against the baseline. A feature that looks predictive because it was recorded after a route was delayed is leakage, not foresight. Keep the source of the closure data and test how the model behaves when that feed is missing. Use this case to test your understanding: Add the closure schedule as a feature known before departure, then evaluate its value. Here is the limitation to watch for: Do not encode an assumption that leaks the final arrival outcome. This supports a careful conclusion: Prior knowledge can restrict features or guide rule design when it is documented and testable. Check the bridge-closure feed on a day when the schedule changes unexpectedly. If the feed is absent, decide whether to fall back to the baseline or ask for review. Document that behavior before claiming the new feature improves operations.
Limits and next step
Next, we'll step back and ask how a great training fit can still fail on deliveries we haven't seen.
Worked example
Add the closure schedule as a feature known before departure, then evaluate its value.
Quick check: test your understanding
Try it yourself: Consider this case: Add the closure schedule as a feature known before departure, then evaluate its value. Explain how you would check the result. In your answer, address this limitation: Do not encode an assumption that leaks the final arrival outcome.
Check the reasoning
Prior knowledge can restrict features or guide rule design when it is documented and testable. Do not encode an assumption that leaks the final arrival outcome.
What is the main idea behind use prior knowledge carefully?
Prior knowledge can restrict features or guide rule design when it is documented and testable.
How is it used in the example?
Add the closure schedule as a feature known before departure, then evaluate its value.
What limitation should be checked?
Do not encode an assumption that leaks the final arrival outcome.
Further reading
Machine Learning — Tom M. Mitchell.
Original ToolsInVision teaching examples. Editorial approach · Suggest a correction
Accessible referenceLesson 64 transcript299 words · Narration ready for the upcoming videoOpen transcript
The dispatcher knows a bridge closes for maintenance each spring. That schedule can be useful prior knowledge if it was published before the affected trips. Add it as a time-specific feature or a documented rule and test whether it improves warnings.
Do not quietly use a later record saying which deliveries actually encountered the closure. That is future information, even if it lives in the same database. Distinguish a planned closure from an unexpected one and keep the source and publication time.
Compare the original model with one that includes the available schedule, using a future held-out period. Inspect both the bridge routes and unrelated routes for errors. A known road closure can be valuable prior knowledge, but only if its schedule was available when the trip was planned. Add it to the training recipe with a clear timestamp, then evaluate later deliveries against the baseline. A feature that looks predictive because it was recorded after a route was delayed is leakage, not foresight. Keep the source of the closure data and test how the model behaves when that feed is missing. Use this case to test your understanding: Add the closure schedule as a feature known before departure, then evaluate its value. Here is the limitation to watch for: Do not encode an assumption that leaks the final arrival outcome. This supports a careful conclusion: Prior knowledge can restrict features or guide rule design when it is documented and testable. Check the bridge-closure feed on a day when the schedule changes unexpectedly. If the feed is absent, decide whether to fall back to the baseline or ask for review. Document that behavior before claiming the new feature improves operations.
Next, we'll step back and ask how a great training fit can still fail on deliveries we haven't seen.