Case study · INSY 674
ML in Production
From notebook to deployed API
The question
What does it take to get a model out of a notebook and into a live, validated, monitored API?
End-to-end ML predicting whether job candidates are likely to look for a new job: research notebooks → production package → FastAPI with Pydantic validation → Docker → live on Render. My part of the team build: strict input validation, model-health metadata and the data-drift monitoring endpoint.
My part
A team project. My merged pull requests: strict input validation (unknown fields and out-of-range values rejected), a clean 503 when the model artifact is missing, model metadata on the health endpoint for traceability, and the data-drift monitoring endpoint with its training baselines.
How it works
- 01
Research notebooks → a versioned Python package with central config and reusable training and prediction modules.
- 02
FastAPI endpoints for health and batch prediction, with Pydantic validation schemas and Loguru logging.
- 03
A drift endpoint that compares each incoming batch with the training baseline using PSI — warn at 0.1, alert at 0.25.
- 04
Docker image, Render blueprint deployment and a GitHub Actions CI pipeline.
Results
5
phases, research to production
4
API endpoints, incl. drift monitoring
0.1 / 0.25
PSI drift warn / alert thresholds
Known limits
- —It runs on Render's free tier, which sleeps when idle — the first request can take 30–60 seconds.