Accuracy alone can't carry a decision.
A business risk model that outputs "high risk" with no calibrated probability and no reasoning is a black box a manager can't defend. In a business-analytics setting the model's legibility — can you trust its confidence, can you explain its call — matters as much as its raw accuracy.
So this was built as a complete pipeline whose deliverable isn't just a score: it's a calibrated probability and a decision-tree diagram that shows the path to each prediction.
An uncalibrated classifier is confident in exactly the wrong way.
What the workflow had to deliver.
Reproducible end to end.
Preprocessing and modelling saved together as a single pipeline, so the exact transforms travel with the model into
.jobliband.pklartefacts.Honest probabilities.
A calibrated version of the final pipeline, so predicted probabilities can be read as real likelihoods rather than arbitrary model scores.
Explainable to a non-specialist.
A decision-tree visualisation that a stakeholder can follow without a stats background.
Six stages, saved as artefacts.
The notebook moves from data to a shipped model: load and clean, explore, engineer features, train and compare, calibrate the winner, and export the whole pipeline.
Saving the whole pipeline — not just the estimator — means the
preprocessing can never drift out of sync with the model at inference
time. It is the difference between a model that works in the notebook and
one that works when someone loads the .pkl months later.
Calibration changed the usable output.
The model comparison picked a strong classifier on the metrics summary, but the step that made the output usable was calibration. Raw classifier scores clustered in ways that misrepresented real risk; after calibration, a 0.7 could be read as roughly a 70% chance — which is the only form a probability can safely inform a business action.
The decision-tree visualisation then did the explaining, turning the final model from a verdict into a traceable argument.
A diagram beats a coefficient table.
The decision-tree render was chosen deliberately as the explanation artefact: a stakeholder can trace a single prediction down the branches and see exactly which thresholds drove it. That legibility is why a slightly simpler, explainable model can be the right business choice over a marginally more accurate opaque one.
Three things, next time.
Add SHAP alongside the tree.
Per-prediction SHAP values would explain the ensemble models too, not only the single decision tree.
Show a calibration curve.
A reliability plot before and after calibration would make the probability improvement visible instead of asserted.
Version the artefacts cleanly.
Multiple
.jobliband.pklfiles accumulated; a single named, versioned artefact would remove ambiguity about which model is final.