Review & Self Study — A Score Is Not a System Decision

This week moved from model evaluation to architecture.

The key chain is now:

input contract → preprocessing → model → policy → action → evidence → fallback / human authority

Review questions

1. Why can the same model produce different operational outcomes in different systems?
2. What should a data contract specify beyond data type?
3. What new concerns appear when a model is served to an application?
4. What can monitoring reveal that an offline test cannot?
5. Why should failure paths be designed before deployment?
6. What makes human oversight meaningful rather than decorative?

A bounded system statement might read:

When the model service times out beyond the 150 ms budget, the application records the event and enters the defined fallback rather than waiting for a late score. This test demonstrates timeout handling; it does not prove every upstream or downstream failure is contained.

Self study

• Draw a system map around a model from Weeks 1–12.
• Add at least two monitoring signals and one fallback.
• Identify one component whose failure could leave the model apparently healthy.
• Explain how you would test a human override path without relying on a real high-consequence system.