Take the application from Chapter 5 and finish it properly: a multi-stage Dockerfile, CI running tests and evaluations, deployment within a declared budget, redacted structured request logs, a small dashboard, two alerts you would actually act on, a rollback runbook, a cost table, and a model card. A model card is a one-page note on what the system is for, what it was evaluated on, and what it should not be used for.
Deploy the Chapter 3 model beside it, as an API or a
batch-scoring job. Give it a release manifest (data/query versions, training cutoff, feature schema,
metrics and artifact hash) and a decision log that joins each decision_id to its features,
release and, once mature, its outcome. Add a freshness check that switches to the documented
fallback when inputs are stale. The reference lab's
release manifest is a filled-in, simulated example.
Then break it on purpose and write a short incident report: what you injected, how long detection took, what fired, how you rolled back, and what you would change. Set severity by user impact, such as wrong decisions served versus a late dashboard. Write it blamelessly. Name the conditions and missing safeguards that let the failure through, not a person to blame. The lab's incident rehearsal is a filled-in example. Your own report is worth more than another model in a portfolio, because very few people have one.