Reliable Machine Learning Applying SRE Principles to ML in Production

1. 1Map the ML loop as your org chart test. The source says ML applications "don't start or stop in any one place, either technically or organizationally." List every stage a model passes through (data, training, evaluation, serving, monitoring) and write the team that owns each stage and each handoff. Any stage with no named owner is an alignment gap.
2. 2Audit the three Star Model dimensions the source names for ML adoption: process, rewards, people. For each, write one sentence on how it is configured today. Example: process is how a model gets approved, rewards is what gets someone promoted or praised, people is who holds which skills and where they sit.
3. 3Pick your adoption structure on purpose. The source describes three common organizational adoption structures and says to judge each by its advantages, likely pitfalls, and effect on process, rewards, and people. Find which one your org actually resembles, then score it on those three dimensions rather than on org-chart elegance.
4. 4Build a written pre-launch gate around the two questions the source says must be answered before any model goes live or replaces a running one: validity (will the new model break our system?) and quality (is the new model any good?). Name an accountable owner for each question and the expertise each needs.
5. 5Make the gate collaborative by design. The source says these investigations often need people with different areas of expertise. Specify which roles must sign off, so verification is not left to the model developers who want to ship.
6. 6Align rewards with verification. The source says model development is "1% inspiration and 99% verification." Check whether recognition, goals, and review criteria value verification, safe updates, and reversibility, or only shipping new models. Change whichever signal pays for speed alone.
7. 7Stop treating adoption as seeding. The source compares unstructured integration to irregular gardening: seeds scattered, results left to chance. Replace it with a structure: an owner, a recurring review, and a list of what has taken hold and what has not.
8. 8Re-run the audit whenever you change structure, add a model, or swap a model version, because each of these moves the handoffs.

Take the source's own scenario: yarnit.ai, an online store, has a model that predicts the likelihood a given user will purchase a given product. The model developers say it is ready, or they have an updated version to swap in for the one running. Before the switch, the gate asks two questions: validity (will it break the serving system?) and quality (is it any good?). Answering them takes people from different areas, so the alignment work is deciding who owns each answer and making that ownership visible. Next, check rewards. If the developers are recognized only for shipping better models, nobody is rewarded for the 99% that is verification, and the gate gets skipped under pressure. So you write the gate as a required process step and credit sign-off work in reviews. The result is a launch path where validity and quality have named owners, and process, rewards, and people all point at careful verification. This example is illustrative, applying the source's two questions and the Star Model dimensions to its yarnit.ai scenario, not a reported outcome.

• If a model stage or handoff has no named owner, then assign one before adding any new ML capability, because the lifecycle spans organizational boundaries.
• If you cannot say who answers 'will it break our system?' and 'is it any good?', then do not ship until both have owners with the right expertise.
• If rewards favor new models over verification, then change the reward signal before changing the process, because the process will be bypassed otherwise.
• If you are choosing between adoption structures, then compare them on process, rewards, and people effects, not only on advantages.
• If adoption is happening with no structure or review cadence, then treat that as the 'irregular gardening' pattern and add an owner and a recurring check.

• Treating ML as an algorithm project. The tell: planning covers model accuracy but says nothing about data, serving, monitoring, or who runs them.
• Letting developers self-certify. The tell: the same people who built the model decide it is ready, and validity and quality have no independent reviewer.
• Rewards that pay for novelty. The tell: promotions cite models shipped, and nobody is credited for verification, rollback readiness, or safe updates.
• Scattering seeds. The tell: pockets of ML activity with no common process, and nobody can say what has taken hold.
• Copying a structure without mapping its effects. The tell: you adopt a team layout from another company but never examined how it changes your process, rewards, or people.

• ▸Lifecycle stage: name the stage (data, training, evaluation, serving, monitoring).
• ▸Accountable owner: the single named team or person for this stage.
• ▸Upstream/downstream handoff: who passes work in and who receives it.
• ▸Process: the written step that governs this stage (e.g., the pre-launch gate).
• ▸Validity check owner: who answers 'will this break our system?'
• ▸Quality check owner: who answers 'is this model any good?'
• ▸Rewards: what behavior is recognized here, and does it include verification?
• ▸People: which expertise is present or missing at this stage.
• ▸Gap and action: the misalignment found, the fix, and the review date.

1. 1Start from the premise the source states: bad things happen, 'and they will.' Write it into the team's operating charter so that being prepared is the baseline, not a sign of pessimism. Confidence here means expecting failure and knowing the response, not expecting that nothing breaks.
2. 2Build a scenario list from the failure classes the passages name: disks fail, files get corrupted, machines break, networks go down, API calls return errors, data gets stuck or changes subtly, models that were accurate become less so, and the world changes so rare events become common. Each class gets one line describing what the team would observe.
3. 3For each scenario, write the two things the source says matter: recognizing the situation correctly, then mitigating it. Recognition comes first. A team that can't tell 'data changed subtly' from 'model decayed' can't choose a mitigation, and that gap is where fear comes from.
4. 4Anchor the response in standard incident management. The source says best practices for incidents are common across computer systems, so the team doesn't invent a process from scratch. Add the ML-specific layer (data, model, and world-change scenarios) on top of it.
5. 5Run each scenario as a rehearsal with the people who will be on call. Before the run, have every participant rate 'I know what to do first' on a 1-5 scale. After the run, rate again and note what changed. The gap between the two ratings is your confidence evidence.
6. 6Write post-incident accounts in the format the source's case-study chapter uses: what we faced, how we dealt with it, what we learned, what we'd do differently. Have the practitioners who lived through it write the account in their own words. This turns experience into shared readiness.
7. 7Add adjacent and seemingly unrelated causes to the scenario list. The source notes that something as simple as load testing, or a launched update to an entirely different mobile app, can cause headaches for the people caring for ML models. Ask each launch owner to announce changes to the ML on-call team.
8. 8Bring product teams and business managers into the rehearsals. The source says they are often anchored in traditional software methods and find ML products unfamiliar territory. Confidence that only the engineers have leaves a gap at the point where decisions about the product get made.

The passages give case-study themes but not full incident details, so this example is a constructed illustration built from the failure classes the source names, not a recorded incident. A team runs a rehearsal on the scenario 'data gets stuck or changes subtly.' Before the session, the five on-call engineers rate 'I know what to do first' at 2, 2, 3, 2, and 4. During the drill, they find that nobody can say who confirms whether an input feed has stalled and who confirms whether the model's accuracy has dropped. They write down the recognition step, which is checking the feed first and then the model output, and assign an owner for each. They also add a line to the launch checklist telling the ML team about unrelated app releases, following the source's mobile-app example. Afterward, they write a short account with the four headings: faced, dealt with, learned, would do differently. A re-rating comes back at 4, 4, 4, 3, and 5. The numbers are not proof of readiness, but the rise tracks a concrete change: each person now has a named first action.

• If a failure class named in the source (data corruption, stuck data, model decay, world change, network or API errors) has no written recognition step, then write that step before adding any new tooling.
• If a rehearsal produces low 'I know what to do first' ratings, then repeat that scenario with the same people before moving to a new one.
• If a change comes from outside the ML system, such as a load test or another app's release, then treat it as a candidate cause and notify the ML on-call team before it ships.
• If product or business stakeholders are making launch decisions for an ML feature, then include them in at least one rehearsal so their expectations match how ML systems fail.
• If an incident ends, then require a written account in the practitioners' own words with the four headings before the team considers the incident closed.

• Treating confidence as a mood rather than a skill. The team gets pep talks but no rehearsals. The tell: nobody can state the first action for a named scenario.
• Rehearsing only the dramatic failures such as outages and ignoring subtle ones. The source flags data that 'changes subtly' and models that become 'less so' accurate. The tell: drills cover only things that fail loudly.
• Assuming incident management is solved by generic practice alone. The source says common practices exist, but ML adds data and model failures. The tell: the runbook has no step for deciding whether the data or the model is at fault.
• Ignoring adjacent causes. The tell: post-incident reviews keep ending with 'unrelated change' or 'unexpected load,' and no upstream team ever warned the ML owners.
• Keeping product teams outside the loop. They are anchored in traditional software methods and are in unfamiliar territory with ML. The tell: product asks for a hard guarantee of 'no model degradation,' which contradicts the premise that bad things will happen.

• ▸Scenario: name one failure class (for example, stuck data, subtle data change, model decay, network or API errors, disk or file failure, adjacent-system change).
• ▸Observable signal: what the team would actually see that tells them this is happening.
• ▸Recognition step: the first check that separates this scenario from similar-looking ones.
• ▸Mitigation action: the first containment step and who is authorized to take it.
• ▸Owner: the named person responsible for recognition and the named person responsible for mitigation.
• ▸Pre-drill confidence (1-5): each on-call member's rating of 'I know what to do first.'
• ▸Post-drill confidence (1-5): the same question, asked after the rehearsal.
• ▸Gaps found: what was unclear, missing, or disputed during the drill.
• ▸Written account link: where the faced / dealt with / learned / would do differently account is stored.

1. 1Enumerate the failure classes ML systems actually experience before an incident occurs: disk failures, file corruption, machine breakage, network outages, API calls returning errors, data getting stuck or changing subtly, and models degrading from once-accurate to less-so. Use this list to build detection coverage.
2. 2Distinguish whether the affected system is trained-once-and-deployed or a continuous ML system, because continuous systems receive streaming or periodic-batch data that triggers automated retraining and pushes to serving — meaning a bad data batch can silently propagate a broken model. Raise the bar on automated verification for continuous systems specifically.
3. 3Instrument for the three ML-specific decay signals that ordinary software incident management misses: subtle data changes, model accuracy drift, and world changes where previously rare events become commonplace. Alert on these, not just on hard outages.
4. 4When an incident fires, first recognize the situation correctly — classify it as infrastructure (disk/machine/network/API) versus data (stuck/changed) versus model (accuracy loss) versus environment (distribution shift), since mitigation differs by class.
5. 5Mitigate by exploiting the reversible path to production: because serving is a separate structure that asks the model for predictions, roll back to a known-good model version to stop harm before you diagnose root cause.
6. 6Apply standard incident management practices — declaring an incident, assigning roles, communicating — since best practices are common across many computer systems; layer ML-specific handling on top rather than reinventing.
7. 7Close the loop by learning: write down what you faced, how you dealt with it, what you learned, and what you'd do differently next time, in the practitioners' own words, so the capability compounds across incidents.

Consider a continuous ML system like the yarnit.ai store's purchase-likelihood model, which is retrained on periodic batches and pushed to serving. Suppose an upstream data feed gets 'stuck' — it keeps delivering yesterday's inventory as if it were current. The training system reads this data, imposes its usual consistency checks, and produces a new model version that is technically valid but representing a stale world, so recommendations quietly degrade rather than throwing errors. Detection here does not come from a downed disk or a failed API call; it comes from monitoring model accuracy and watching for subtle data changes. The right first move is to use the reversible path to production and roll serving back to the last known-good model version, halting customer harm. Only then do you trace the incident to the stuck feed, fix ingestion, and add an automated verification gate so a stale batch cannot trigger a push again. Afterward, the team documents the timeline and what they'd do differently, feeding the next round of prevention.

• If the system is continuous (streaming or periodic-batch retraining), then treat automated verification as mandatory before any model reaches serving, because bad data auto-propagates.
• If the symptom is degraded predictions with no infrastructure failure, then suspect data change or model decay first, not a hardware or network fault.
• If a good model has become less accurate over time, then check whether the external world changed — previously rare events becoming common — before assuming a code or data bug.
• If harm is ongoing and root cause is unknown, then roll back to a known-good model version immediately, since the path to production should be reversible.
• If the incident is a generic outage (disk, machine, network, API error), then apply standard cross-system incident management practices rather than inventing ML-specific process.

• Treating training as a one-time event; the tell is a team with no monitoring on model accuracy or data drift because they assume the model, once deployed, stays correct.
• Missing subtle data corruption because alerts only cover hard failures; the tell is 'all systems green' while predictions quietly worsen.
• No reversible path to production; the tell is that when a bad model ships, the only option is a slow forward fix instead of an immediate rollback.
• Ignoring world change as a cause; the tell is repeatedly retraining on the same features while accuracy keeps sliding because the environment shifted, not the pipeline.
• Never writing up incidents; the tell is the same failure recurring because there's no record of what happened, what was learned, and what to do differently.
• Applying only generic software incident management and skipping ML-specific detection; the tell is a mature on-call process that catches outages but never catches model decay.

• ▸Incident class: infrastructure / data / model / environment — pick the primary one
• ▸System type: trained-once vs continuous (streaming or periodic-batch)
• ▸Detection signal: what fired (hard failure, data change, accuracy drop, or world change)
• ▸Immediate mitigation: known-good model version to roll back to, and whether the path is reversible
• ▸Automated verification gap: which check would have caught this before serving
• ▸Root cause: the specific failure (disk, corruption, stuck/changed data, decay, shift)
• ▸What we learned: one sentence in the responder's own words
• ▸What we'd do differently next time: concrete prevention added

1. 1Draw the system as a data processing pipeline, not as a model. List every stage from data source to the processed output (features, human annotations, metadata, training, serving). The passages' premise is that ML systems are pipelines that extract usable, repeatable insights from data, so reliability is owned at the pipeline level.
2. 2Assume the work is a loop with no start or end. Write down who retrains, who changes features, and who adds data when the model falls below your threshold. Name the data scientists, business analysts, and ML engineers involved. A reliability plan that assumes one training run has no owner for the second run.
3. 3Put a numeric threshold on 'works well enough' and record it. The source frames the lifecycle around checking whether the model clears a certain threshold. Without one, nobody can say a failure happened.
4. 4Split every model change into two gates. Gate 1, validity: will this model break our system? Gate 2, quality: is the model any good? Run both for a first launch and for every swap of a new version over a running one. Name an owner for each gate, since the source notes that answering them takes people with different expertise.
5. 5Make the path to production reversible. Before a swap, confirm you can put the previous version back. The preface lists a 'smooth (and reversible) path to production' and 'safety in updating' as part of reliability.
6. 6Build detection for failures that look like success. ML pipelines fail differently from conventional log-processing pipelines, success is hard to measure, and many failures are hard to detect. Add checks on the data entering the feature, annotation, and metadata subsystems, and on the output, rather than relying only on job-succeeded signals.
7. 7Write a pager triage step: when alarms fire, decide first whether the behavior is independent of the model (infrastructure, pipeline, data flow) or tied to model type or quality. The source says system-level behavior is mostly, but not always, independent of the model, so you must determine which case you are in.
8. 8Treat verification as the main work. The source's framing is that model development is 1% inspiration and 99% verification. Schedule review time for gates 1 and 2 before the release, and do not let it shrink under deadline pressure.

The source describes two scenarios that make a usable example. Scenario A: model developers say a model is ready for production, or a new version is ready to replace the running one. Before switching, you ask the validity question: will it break our system? You then ask the quality question: is it any good? Suppose validity passes and quality falls below your threshold, as in the source's thought experiment. Data scientists, business analysts, and ML engineers then work out why. That work might mean changing features in the training pipeline or adding data, which restarts the loop. Scenario B: after a swap, the pager fires. Using the triage rule, you first ask whether this is a system-level failure that would occur with any model or one tied to this model's quality. If you cannot tell, roll back to the previous version, which exists because you kept the path reversible. The passages give no specific numbers or incident details, so the threshold and the metrics are yours to fill in.

• If a new or updated model is about to replace a running one, then require a validity answer ('will it break the system?') before looking at any quality answer ('is it good?').
• If an alarm fires after a change, then first decide whether the failure is independent of the model type and quality, and only then escalate to model developers.
• If you cannot show you can revert to the prior model version, then do not ship the update.
• If the pipeline reports success but the output cannot be checked against a threshold, then treat it as an undetected failure and add an output-level check, because ML failures are hard to detect and success is hard to measure.
• If quality is below threshold, then plan a loop iteration (feature changes, more data, retraining) rather than a one-off fix.

• Tuning the model while ignoring the pipeline. The tell: the team talks about accuracy points but cannot say who owns the feature, annotation, or metadata systems.
• Collapsing validity and quality into one check. The tell: a model with good quality metrics still crashes or degrades the serving system, and no one was assigned to check it.
• Assuming ML is done after one training run. The tell: no named owner or process exists for retraining when the model drops below threshold.
• Relying on conventional pipeline monitoring. The tell: jobs finish green while outputs are wrong, and you learn from users rather than from your own alerts.
• Skipping rollback planning. The tell: after a bad swap, the only option is to debug in production because the old version cannot be restored quickly.

• ▸Change description: one line on what is being swapped, added, or retrained.
• ▸Quality threshold: the stated level at which the model counts as working well enough.
• ▸Validity check (will it break the system?): result and owner.
• ▸Quality check (is it any good?): result against the threshold and owner.
• ▸Data subsystems touched: feature system, human annotation system, metadata system; note which change.
• ▸Rollback path: how the previous version is restored and who triggers it.
• ▸Output-level detection: the check that would reveal a silent failure after release.
• ▸Pager triage note: how to tell a model-independent failure from a model-related one.
• ▸Verification sign-off: names, date, and open issues.

1. 1Start from the product behavior, not the model. Chapter 12 lists data collection practices and governance, data quality, definition of product behavior, UI/UX, and business goals as joint contributors to success. Write one sentence for each describing what the feature must do for the customer and for the business before anyone trains anything.
2. 2Turn 'works well enough' into a written threshold. The Chapter 1 thought experiment asks whether the model clears a certain threshold, and that threshold has to exist in advance. Record it with the metric, the data it is measured on, and the named owner who agreed to it (data scientist, business analyst, or ML engineer).
3. 3Separate the two gate questions from Chapter 5. Validity asks whether the new model will break the system. Quality asks whether it is any good. Run both before every first launch and every model swap, and record the answers where product and business owners can read them.
4. 4Plan for the loop, not a one-time launch. ML applications are never done and don't start or stop in one place. Schedule the recurring work: collect data, retrain, re-evaluate, and re-ship. Assign owners across data science, analysis, and engineering for each pass.
5. 5Make the path to production reversible and safe to update. The preface names a smooth, reversible path and safety in updating as part of reliable ML. Before launch, confirm you can return to the previously running model if the new one hurts the product.
6. 6Track business outcomes next to model metrics. The book says ML pipeline success is hard to measure and many failures are hard to detect. Put at least one product or business signal (for yarnit.ai, whether predicted purchases turn into purchases) on the same view as the model's offline quality.
7. 7Add cost and performance to the value ledger. The preface lists cost, performance, and business goals as whole-system concerns. Write down what the model costs to run and serve, and require the value it adds to justify that on a recurring basis.
8. 8When a failure appears, diagnose it together. Per the Chapter 1 loop, data scientists, business analysts, and ML engineers work out whether the fix is changed features, new data, or a changed product definition. Log the decision so the business can see what was done and why.

The source's running example is the yarnit.ai online store, where the team has just built a model that predicts how likely a given user is to purchase a given product. Treat it as a value problem rather than a modeling one. First, write the product behavior: the store uses the predictions to show users products they are likely to buy, and the business goal is purchases. Second, set the 'good enough' threshold the Chapter 1 thought experiment calls for, on a named metric, and have the data scientist, business analyst, and ML engineer agree to it. Third, run the Chapter 5 gates on the candidate model: validity (will it break serving?) and quality (is it any good?). Fourth, ship it with a path back to the previous model, since the preface stresses reversibility. Fifth, watch a business signal (purchases following predictions) alongside the offline metric, because ML failures are often hard to detect. When the signal slips below the threshold, the same three roles decide whether to change features, add data, or revise the product definition. That is the ML loop applied to value.

• If no one can state the 'works well enough' threshold and its owner, do not launch; the model has no definition of success to be held to.
• If validity is unproven (the model might break the system), stop regardless of quality results; validity precedes quality.
• If a model swap can't be rolled back to the running version, treat the release as unsafe until a reversible path exists.
• If the model metric holds but the product or business signal falls, treat it as a value failure and investigate data, features, and product definition instead of retraining blindly.
• If running cost or serving performance undermines the business goal, count that as a value defect even when quality passes.

• Treating launch as the finish line. The tell: no owner, schedule, or budget for retraining and re-evaluation, even though ML applications are never really done.
• Optimizing the model in isolation. The tell: celebrations over another percentage point of accuracy, with no link to the product behavior or business goal.
• Applying traditional software product methods unchanged. The tell: a product team anchored in them lacks plans for data governance, data quality, or defining ML product behavior.
• Assuming failures will announce themselves. The tell: pipelines that run without errors while no one can show whether the output still helps customers, since ML success is hard to measure and failures hard to detect.
• Skipping verification under schedule pressure. The tell: a model swapped in with no validity and quality check, contrary to the book's '1% inspiration and 99% verification'.

• ▸Product behavior: one sentence on what the ML feature does for the customer.
• ▸Business goal: the outcome the business expects (for example, purchases for yarnit.ai).
• ▸'Good enough' threshold: metric, dataset, and the pass level agreed in advance.
• ▸Threshold owners: named data scientist, business analyst, and ML engineer who signed off.
• ▸Validity check result: will the model break the system? Record the answer and evidence.
• ▸Quality check result: is the model any good against the threshold? Record the evidence.
• ▸Rollback path: how and how fast you return to the previous model.
• ▸Business signal monitored: the product or business metric watched alongside the model metric.
• ▸Cost and performance note: what it costs to train and serve, and why that is justified.
• ▸Review cadence and trigger: when the loop reruns and what below-threshold result forces action.

1. 1Draw the data path as five stages: created, processed, annotated, stored, used to create the model. These are the stages the source names. Write one owner next to each stage. A stage with no owner is where silent failures live.
2. 2Split the infrastructure into the three subsystems the source names: a feature system, a system for human annotations, and a metadata system. For each, write down what it accepts from upstream and what it hands to the training system. If you can't state an interface in a sentence, it isn't managed yet.
3. 3Treat features as characteristics of the input data. Record, for every feature, which raw input it derives from and which pipeline step computes it. A change to the training pipeline (the source's example is changing some features) is then a traceable change, not an unlogged edit.
4. 4Make every run repeatable. For each training run, log which data, which annotations, and which feature definitions went in. The source names repeatability, manageability, and reliability as the three challenges data handling creates, so test repeatability directly: can you rebuild last month's model's inputs?
5. 5Assume the infrastructure and the data will misbehave. The source lists disks failing, corrupted files, broken machines, network outages, API calls returning errors, and data that gets stuck or changes subtly. Add a check at each stage boundary for completeness, corruption, and staleness. Stuck and subtly changed data produces no error, so the checks must compare against an expectation.
6. 6Don't wait for the model's output to reveal data problems. The source warns that ML pipeline success is hard to measure and many failures are hard to detect. Put detection at the data layer, where the cause lives, rather than in model metrics where the symptom arrives late.
7. 7Write down collection practices and governance as part of the product definition. The source lists data collection practices and governance, and data quality, as contributors to product success alongside UI/UX and business goals. Name who may collect what, and who approves changes to it.
8. 8Plan for the loop. When a model falls below threshold, data scientists, business analysts, and ML engineers collaborate on the failures. Give them a shared, versioned view of the data and metadata so the investigation starts from facts rather than from competing memories.

The source gives a thought experiment instead of a numbered case. A team has a model and checks it against a threshold, and it falls short. Data scientists, business analysts, and ML engineers get together to understand the failures, and the fix often means modifying the training pipeline to change features. Apply data management to that moment. With a metadata system, the team can say exactly which data, annotations, and feature definitions produced the failing model. With a feature system, changing a feature is a recorded edit and not a one-off script. Without them, the retrained model can't be compared to the old one, because nobody knows what changed besides the feature. The source also says ML applications 'are never really done', so this scenario recurs. The management work you do once pays off on every later pass through the loop. No figures are given in the source, so the thresholds here are placeholders you must set yourself.

• If a stage of the data path (created, processed, annotated, stored, used) has no named owner, then assign one before improving anything else.
• If you can't reconstruct the exact inputs of a deployed model, then stop changing the pipeline and fix metadata and lineage first, because repeatability is the foundation.
• If a pipeline change touches features, then record it as a versioned feature change and retrain with the new definition logged, instead of patching the training script.
• If a failure would raise no error (stuck data, subtle drift, a changed upstream source), then add an explicit expectation check at the stage boundary, because the source says such failures are hard to detect.
• If model quality drops and the model code is unchanged, then inspect data and the world first: the source says models become less accurate and representative when the world changes.

• Treating the ML pipeline like a conventional log-processing pipeline. Tell: you only monitor job success or failure, yet the source says ML pipelines fail differently and their success is hard to measure.
• No metadata system, so runs can't be reproduced. Tell: nobody can say which data or feature definitions trained the production model.
• Treating annotation as a one-time task outside the system. Tell: labels have no recorded source or version, and the human annotation system is not part of your architecture.
• Assuming infrastructure faults will announce themselves. Tell: corrupted files, stuck data, or subtly changed inputs are found only after model quality complaints.
• Treating the model as done once it ships. Tell: no one owns the loop of investigating failures and updating data, and the model is only revisited in a crisis.

• ▸Stage: created / processed / annotated / stored / used. State which one this row covers.
• ▸Owner: the named person or team accountable for this stage.
• ▸Source and collection practice: where the data comes from and the governance rule for collecting it.
• ▸Subsystem: feature system, annotation system, or metadata system. Say which one holds this data.
• ▸Version and lineage: the identifier for this data and the upstream data or feature definitions it derives from.
• ▸Expected state: what completeness, format, and freshness should look like when healthy.
• ▸Check at boundary: the automated test comparing actual state to the expected state, and where it runs.
• ▸Known fault modes: which of corruption, stuck data, subtle change, or API errors apply here, and the tell for each.
• ▸Used by: which training runs or models consume this data, so you can trace the impact of a change.

1. 1Split the review into two gates before anyone looks at metrics. Gate 1 is model validity: will this model break our system? Gate 2 is model quality: is this model any good? Record each gate's verdict separately. A strong quality result never offsets a validity failure.
2. 2Write the quality threshold down before evaluation starts. The source frames the question as whether the model works well enough 'according to a certain threshold'. Fix that number and the metric it applies to in advance, so the result cannot be rationalized afterward.
3. 3Define the comparison baseline. For an update, the baseline is the currently running production version that the new model replaces. Evaluate both on the same data so the question becomes 'is the new one at least as good as what we run today', not 'is it good in the abstract'.
4. 4Run validity checks against the system, not just the model file. Confirm the new model loads, accepts the inputs the serving path actually sends, and returns outputs the downstream consumers can use. The failure you are guarding against is the model breaking the system, which is separate from the model being inaccurate.
5. 5Evaluate quality on data that reflects real usage, not only the data the model was developed on. The construct's purpose is to catch models that perform poorly on real data. Name the data source you use and the reason it represents production.
6. 6Assign named reviewers across the relevant areas of expertise: data scientists, ML engineers, and business analysts, per the source's description of who collaborates. Each signs off on the part they own, because the source notes these investigations often need people with different expertise.
7. 7Confirm the path back before the path forward. The source stresses a smooth and reversible path to production. Verify you can restore the previous model version, and record who decides to roll back.
8. 8Keep the evaluation as a repeatable, followed process, not an ad hoc review. The source says an organization should develop and follow robust processes so these investigations are carried out carefully every time a model is swapped in.

The source supplies the scenario but no numbers, so this example uses placeholders instead of invented figures. Your developers say an updated model is ready to replace the one now serving your website. Before the switch, you open two checklists. Validity: does the new model load in the serving environment, accept the real input format, and emit outputs the rest of the system can consume? Quality: does it clear the threshold [T] you set in advance on metric [M], and does it do at least as well as the running version on the same real-data sample? Suppose validity passes but the new model lands below [T]. The verdict is 'do not deploy', and the data scientists, business analysts, and ML engineers then work together to understand the failures, as the source describes. They may change features in the training pipeline or add data. The model is re-evaluated against the same threshold. Because the threshold was fixed beforehand, nobody can lower it after seeing the result.

• If a model passes quality but fails any validity check, then block deployment: a model that breaks the system is not deployable however good its metrics are.
• If the model is an update to a running one, then compare it against the currently deployed version on the same data, not only against the abstract threshold.
• If the result falls below the pre-set threshold, then do not adjust the threshold to fit; send it back to the cross-functional group to diagnose failures and improve the pipeline.
• If you cannot name a tested way to revert to the previous model, then treat the deployment as not ready, whatever the evaluation results say.
• If the evaluation data is not demonstrably like real production data, then treat the quality verdict as provisional and say so in the sign-off.

• Collapsing validity and quality into a single 'accuracy looks fine' check. The tell: a model with good metrics fails at serving time, or breaks a downstream consumer, because nobody tested system compatibility.
• Setting the acceptance threshold after seeing results. The tell: the threshold in the record matches the new model's score almost exactly, or has been revised during review.
• Evaluating only on the data used in development. The tell: strong offline numbers, then poor behavior on live traffic, which is the 'performs poorly on real data' failure.
• Leaving evaluation to one specialist. The tell: sign-off from a single role, and questions from other areas (business impact, pipeline, system integration) surface only after launch.
• Treating evaluation as a one-time event instead of a repeatable process. The tell: each model swap is reviewed differently, with no written criteria, and ML applications are never really done, so the gap keeps growing with every update.

• ▸Model and version being evaluated: name the candidate and the production version it replaces (or 'new deployment').
• ▸Validity check results: list each system-compatibility check (loads, accepts real inputs, outputs consumable downstream) and pass/fail.
• ▸Quality metric and threshold: state the metric and the minimum acceptable value, written before evaluation began.
• ▸Evaluation data source: describe the data used and why it represents real production data.
• ▸Baseline comparison: record the running version's score on the same data next to the candidate's score.
• ▸Reviewers and expertise areas: list each named reviewer and the area they signed off on.
• ▸Rollback plan: describe how to restore the previous model, who authorizes it, and when it was last tested.
• ▸Verdict: deploy / do not deploy / re-evaluate, with a one-line reason tied to the validity and quality gates.
• ▸Follow-up actions: list failures to investigate and pipeline changes (features, data) if the model did not pass.

1. 1Scope the job first: you are monitoring a system that does ML, not using ML to monitor systems (AIOps). Write down the pipeline end to end (data in, features, training, model, serving, predictions consumed). Every stage gets a monitoring owner, because the source treats ML systems as data processing pipelines, not as a model plus an endpoint.
2. 2Split signals into two layers. Layer one is conventional failures the source lists: disks fail, files corrupt, machines break, networks go down, API calls return errors. Standard production monitoring covers these. Layer two is ML-specific: data that gets stuck or changes subtly, models that become less accurate or representative, and a world that shifts so rare events become common. Layer two is where you add instrumentation.
3. 3Instrument inputs before outputs. For each feature feeding the model, record what it looked like when the model was trained and what it looks like now. Alert on stuck values (a feature that stops changing) and on subtle change, since the source names both as failure patterns. Input checks fire earlier than quality checks, which need outcomes to arrive.
4. 4Instrument predictions, then prediction quality. Log what the model predicted and what happened afterward, so you can compare them. Accept that the source calls success hard to measure and many failures hard to detect. Define at least one quality proxy you can compute now and one true outcome measure that arrives later, and monitor both.
5. 5Take your baselines from the validity and quality questions you already asked before launch: will the model break the system, and is it any good? Those pre-deployment answers become the reference values production is compared against. Without them, 'drift' has nothing to be measured against.
6. 6Alert on conditions someone can act on, and write down the action. The source frames the goal as knowing which situation you are in 'when the alarms start to go off or the pagers start to fire'. Each alert names the layer (infrastructure, data, model quality), the likely situations, and the first diagnostic step. Route urgent ones into your incident management process.
7. 7If you retrain continuously (new data arrives by stream or periodic batch and triggers a new model pushed to serving), monitor the retraining path as well as the served model. A bad batch can produce a bad model and push it to serving automatically, so put checks on the training data and on the new model before the push.
8. 8Treat the setup as unfinished. The source calls the practice a frontier rather than a well-defined space. Review each incident to find which signal would have caught it earlier, and add it.

Take the source's yarnit.ai online store, where a model predicts the likelihood that a given user will purchase a given product and serving passes those predictions to the rest of the system. This walk-through is illustrative and its details are not from the source. Infrastructure monitoring shows no errors: no failed API calls, no network problems. Yet purchases driven by recommendations quietly fall. This is the failure shape the source warns about, where data 'gets stuck or changes subtly' and failures are hard to detect. Your layer-two instrumentation has two relevant signals. The input check shows a product-popularity feature has stopped updating, a stuck-data failure. The prediction log shows predicted purchase likelihoods diverging from observed purchases. You open an incident, since the source treats urgent ML problems as incidents. The stuck feature is the lead suspect, because the serving infrastructure is healthy and the model itself has not changed. After the upstream feed is fixed, you add a freshness alert on that feature so the next stall pages someone before purchases drop. The sequence shows why you need both layers: the conventional layer reported healthy while the ML layer carried the evidence.

• If infrastructure dashboards are green but the business outcome is moving the wrong way, then check input data (stuck or subtly changed features) and prediction-versus-outcome comparisons before blaming the model.
• If true outcomes arrive late, then alert on input and prediction distributions as early warnings, and use outcome-based quality as the confirming signal.
• If the system retrains continuously and pushes to serving, then gate the push with checks on the new model and its training data, because errors propagate automatically.
• If an alert has no documented first action or owner, then fix or delete it, since alerts exist to tell you which situation you are in.
• If inputs have changed but quality holds, then log it and watch rather than page. If both have changed, treat it as an incident.

• Monitoring only infrastructure health (errors, latency, machines up). The tell: a quality regression is found by users or business metrics, not by your alerts, even though every dashboard was green.
• Not recording outcomes alongside predictions. The tell: when quality is questioned, you cannot say whether the model was wrong, because you never joined predictions to what happened.
• Alerting on every change in the data. The tell: pages fire often, on-call stops trusting them, and real stuck-feature or drift events get ignored.
• Treating a deployed model as finished (the 'train once and deploy' mindset). The tell: nobody can say when the model last matched the world, and the world has changed around it.
• No baseline from pre-launch validation. The tell: you see 'drift' on a chart but cannot say whether it is outside what the model was validated against.

• ▸Pipeline stage: input data, feature, training, model, serving, or consumer of predictions.
• ▸Failure type: infrastructure (disk, file, network, API error) or ML-specific (stuck data, subtle change, accuracy decline, world change).
• ▸Signal: the specific measurement that would reveal the failure.
• ▸Baseline: the reference value from pre-launch validity and quality checks, or from training data.
• ▸Outcome join: how and when predictions get compared with real outcomes, including the delay.
• ▸Alert condition: what must be true to page someone, and what only gets logged.
• ▸First diagnostic action: the first step the responder takes, and which situation it distinguishes.
• ▸Owner: the person or team accountable for this signal.
• ▸Review note: what an incident taught you about this signal, and what to add next.

1. 1Write the serving contract first. Serving is 'creating a structure to ensure our system can ask the model to make predictions on new examples, and return those predictions to the people or systems that need them.' Record who asks, what a request contains, what comes back, and who consumes it. For yarnit.ai: the request is a user and a product, and the response is a purchase likelihood.
2. 2Choose the serving architecture on purpose. The source says there is a range of possibilities, each with different architectures and trade-offs, and they differ enough to merit separate consideration. Write down the two or three candidates and what each costs you in reliability and in reversibility. Do not default to whichever one the model developers happened to use.
3. 3List the failure conditions the serving path must survive, using the incident-response list: disks fail, files get corrupted, machines break, networks go down, API calls return errors, data gets stuck or changes subtly. For each one, write the behavior you want. Options include returning a fallback, returning an error, or serving the prior model.
4. 4Treat every model update as a swap, not a one-off deploy. A new version replaces a currently running version. Keep the running version available and identifiable so the swap can be undone. The book's stated goal is a 'smooth (and reversible) path to production' and 'safety in updating.'
5. 5Gate the switch with verification. Before 'flipping the switch' on a new model in a critical setting, answer the validity and quality questions from the evaluation chapter. If your system trains continuously and pushes new versions to serving, automate the check, because continuous ML 'raises the stakes for automated verification.'
6. 6Separate system-level alarms from model-level ones. Serving robustness is largely independent of model quality, but not always. When a page fires, first decide which situation you are in: infrastructure failure (machines, network, API errors) or model degradation (a once-accurate model becoming less so, or the world changing around it).
7. 7Rehearse the reversal. For each model version, confirm that you can restore the previous version to serving. Confirm too that the failure behaviors from step 3 actually occur. Do this before an incident forces it.

yarnit.ai has just built a model that predicts the likelihood that a given user will purchase a given product, and the rest of the store system needs those predictions. The team first writes the contract: the store sends a user and a product, and the model returns a likelihood. Next they compare serving architectures and note the trade-offs of each, since the source stresses these differ meaningfully. They then walk the incident list against that path. If a machine breaks or the network goes down, the store must still render a page. If an API call returns an error, the store must know what to do instead of waiting. A new model version is built. Before it replaces the running one, the team answers the validity-and-quality questions. The swap keeps the old version in place and restorable. If the new version looks wrong after the swap, they restore the old one first and investigate afterward. If the model has simply become less accurate because the world changed, that is a model problem, and re-serving the old version will not fix it.

• If a new model version is replacing a running one, then keep the running version restorable and complete the validity and quality checks before the swap.
• If your system trains continuously and pushes new versions to serving, then automate verification, because manual review will not keep pace with the update cadence.
• If an alarm fires, then first classify it as infrastructure failure (disk, machine, network, API error) or model degradation (stale or shifted data, a changed world). The responses differ.
• If you cannot state what the system does when a prediction call errors or the network drops, then the serving design is unfinished, whatever the model's quality.
• If you are choosing between serving architectures, then pick the one whose failure and rollback behavior you can describe, not just the one that performs best in the happy path.

• Treating deployment as a one-time event. The tell: no one can say how to return to the previous model version, and the old version is gone once the new one is live.
• Designing only for the happy path. The tell: the team cannot answer what happens when a machine breaks, the network is down, or an API call returns an error.
• Swapping in a new model without answering the validity and quality questions. The tell: the first evidence about the new model's quality comes from production behavior.
• Misdiagnosing a page as an infrastructure fault when the model has degraded, or the reverse. The tell: repeated restarts or rollbacks that do not change prediction quality, or model retraining that does not fix errors.
• Letting continuous retraining push versions to serving with manual-only verification. The tell: versions reach production faster than anyone reviews them, and feedback loops or reactions to external changes surface only after the fact.

• ▸Model and consumer: name the model and every system or user that requests predictions (e.g., yarnit.ai store, purchase-likelihood model).
• ▸Request/response contract: state what a request contains and what the prediction returns.
• ▸Serving architecture chosen and rejected alternatives: record the option picked, the others considered, and the trade-offs.
• ▸Failure behavior table: for each of disk failure, corrupted file, machine failure, network outage, API error, and stuck or subtly changed data, write the intended behavior.
• ▸Pre-swap verification: list the validity and quality checks that must pass before a new version replaces the running one, and whether they are automated.
• ▸Rollback path: identify the previous version, where it is held, and the steps and owner for restoring it.
• ▸Update cadence: state whether the model is trained once or continuously, and how new versions reach serving.
• ▸Alarm triage note: write how on-call decides between an infrastructure fault and model degradation.
• ▸Last rehearsal date: record when rollback and failure behaviors were last exercised and what was found.

1. 1Treat fairness, privacy, and ethics as release requirements, not review comments. The source puts them 'right at the top' of what MLOps practitioners need to know. Add them as a named line in the same launch checklist that holds your validity and quality checks.
2. 2Run the two gate questions before any new or updated model replaces a running one: validity ('will the new model break our system?') and quality ('is the new model any good?'). Define 'good' to include the ethical and fairness criteria you have written down, not accuracy alone. This is a reading of the source, which says only that quality needs deep investigation.
3. 3Name the people who answer each question. The source says these investigations often need collaboration among people with different expertise. Put a person from each relevant area on the sign-off, and record who signed.
4. 4Trace the data before the model. The source says models come from data, and it calls for handling data 'correctly and responsibly'. Document how each training and feature dataset is created, processed, annotated, stored, and used, and flag any step where privacy or legal obligations apply.
5. 5Learn the legal and conceptual vocabulary for your domain. The chapter says it cannot be exhaustive and aims to give you 'concrete language and conceptual categories' to start your own education. Assign someone to map your application to the legal obligations that govern it, and revisit that mapping on a schedule.
6. 6Put ethics failures into incident management. The source says bad things happen to systems and that teams already have incident-management practice for them. Define a fairness or privacy problem in production as an incident type, with an owner, a response path, and a way to roll back.
7. 7Keep the path to production reversible. The source stresses 'a smooth (and reversible) path to production' and safety in updating. Check that you can swap back to the prior model quickly if a fairness or privacy problem surfaces after launch.
8. 8Re-verify after launch. The source says models that were once accurate and representative become less so, and the world changes around them. Schedule recurring re-checks of the same ethical criteria instead of treating the launch review as final.

The source offers no numeric fairness case study, so this applies its model-swap scenario. A team has an updated model to replace the one in production. The source frames the pre-launch check as two questions: validity ('will the new model break our system?') and quality ('is the new model any good?'). The team adds its written fairness and privacy criteria to the quality question, and it does not accept accuracy alone as the answer. It records who from each area of expertise reviewed the data lineage and the criteria. Because the source says 'model development is 1% inspiration and 99% verification', the team treats the review as the main work and does not shorten it. It confirms the old model can be restored before it flips the switch. Later, a complaint arrives about the new model's behavior. The team handles it as an incident, rolls back if needed, and records what it learned. Before the next update, it adds that lesson to the checklist.

• If a new model is about to replace a running one in a critical setting, then it does not ship until validity and quality are both answered in writing, with fairness and privacy criteria inside the quality answer.
• If you cannot trace how the training data was created, annotated, and stored, then treat privacy and fairness as unverified and block launch until the lineage is documented.
• If you cannot name the legal obligations that apply to your application, then assign someone to find them before launch. Do not assume the chapter's overview covers you, because it says it is not exhaustive.
• If a fairness or privacy problem appears in production, then run it through incident management and use the reversible path to restore the prior model while you investigate.
• If the world or the data has shifted since the last review, then repeat the ethical checks. A model that was once representative can stop being so.

• Fairness is reviewed once, at launch. The tell: no recurring review exists, and nobody can say when the criteria were last checked, even though the source warns that models become less accurate and representative over time.
• Quality is defined as accuracy only. The tell: the launch checklist has metric thresholds but no fairness, privacy, or legal line item.
• Ethics is left to one person or one team. The tell: sign-off shows a single name, though the source says these investigations often need collaboration among people with different expertise.
• Data handling is treated as a pipeline chore. The tell: no one can describe how data was annotated or stored in terms of privacy or responsible use, despite the source's emphasis on handling data 'correctly and responsibly'.
• There is no rollback path when an ethical problem appears. The tell: a complaint arrives and the only options are to keep the model running or to improvise a fix, because the swap cannot be reversed quickly.

• ▸Model and version: name the new model and the running model it replaces.
• ▸Validity answer: state in writing whether it will break the system, and cite the evidence.
• ▸Quality answer: state whether the model is good, including the written fairness and privacy criteria used.
• ▸Data lineage: describe how training and feature data was created, processed, annotated, stored, and used, and flag privacy-sensitive steps.
• ▸Applicable legal obligations: list the laws or obligations that apply to this use and the person who identified them.
• ▸Reviewers and expertise: list each reviewer, their area of expertise, and sign-off date.
• ▸Rollback path: describe how to restore the prior model and how long it takes.
• ▸Incident owner and response: name who owns a fairness or privacy incident and the escalation route.
• ▸Next re-verification date: set when the same criteria are checked again after launch.