Models that keep working after the first quarter in production.
A churn model scores well in the notebook, ships, and then quietly decays after a pricing change nobody told the data team about. We build models with monitoring and retraining designed in, on the data platform you already run.
Training and evaluationbaselines · gradient-boosted treesModel registryMLflow · Databricks · Snowflake
03 · Serving
Batch or real-time scoringjobs · endpointsDrift monitoringinput drift · accuracy
04 · Decisions
Business applicationCRM · planning · claims queueExplanationstop drivers per prediction
DatabricksSnowflakeMicrosoft Fabricdbt
in short·15-second read
Machine learning models predict outcomes from historical data, such as demand, churn, fraud, claim severity or equipment failure.
Cohash builds and deploys these models on Databricks, Snowflake, Microsoft Fabric or your cloud ML service, with feature pipelines, a model registry, drift monitoring and retraining. We use the simplest model that meets the accuracy target, often gradient-boosted trees, and explain predictions to the people who act on them.
you probably need this if
Forecasts come from spreadsheets that one analyst maintains by hand.
A model went live and nobody's checked its accuracy for drift since.
The people acting on a score cannot see why the model gave it.
terms on this pageDriftdefinitionWhen a live configuration slowly wanders away from what you intended, often through emergency edits nobody tracked.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Machine Learning Models, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · machine learning models3 open
openForecasts come from spreadsheets that one analyst maintains by hand.
recurringA model went live and nobody's checked its accuracy for drift since.
blockedThe people acting on a score cannot see why the model gave it.
exposure
Problem framing and baselinesFeatures and pipelinesHonest evaluationDeployment and registryMonitoring and retrainingExplainability for consequential…
startrehearsehandover
Frame
Baseline
Iterate
Deploy and monitor
we are here
ready to hand over
Each model in serving traces to its data, its code and its evaluation.
We showed adjusters why the model suggested each reserve.
Problem statement and success metric
Evaluation report comparing baseline and final model
chapter 01 · where it hurts
Why teams reach out
Forecasts come from spreadsheets that one analyst maintains by hand.
A model went live and nobody's checked its accuracy for drift since.
The people acting on a score cannot see why the model gave it.
chapter 02 · what we change
How we solve it
Problem framing and baselines
Features and pipelines
Honest evaluation
Deployment and registry
Monitoring and retraining
Explainability for consequential decisions
chapter 03 · how it runs
Our approach
Frame
Baseline
Iterate
Deploy and monitor
chapter 04 · where you end up
What changes
Each model in serving traces to its data, its code and its evaluation.
We showed adjusters why the model suggested each reserve.
Problem statement and success metric
Evaluation report comparing baseline and final model
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Pin down the target and the decision it changes. Find a simple baseline to beat. If a rule of thumb gets close, you'll hear it from us before anything complex gets built.
We write feature logic once, in dbt or Spark, and use it for both training and scoring. That way production and testing agree on what every feature means.
Time-based splits, leakage checks and metrics tied to cost. A fraud model is judged on losses prevented and analyst hours, and AUC comes second.
We do batch scoring into tables or real-time endpoints, and track versions, approvals and lineage in MLflow or Unity Catalog so you can tell which model made which prediction.
We track input drift and prediction drift, plus realized accuracy once outcomes arrive. Thresholds trigger retraining. The calendar doesn't.
We give every prediction an explanation and write model cards. When a model influences credit, insurance, housing or employment, explanation and human review may be legal requirements, for example under Colorado's 2026 ADMT law.
capability 01 / 06in production
Problem framing and baselines
Pin down the target and the decision it changes. Find a simple baseline to beat. If a rule of thumb gets close, you'll hear it from us before anything complex gets built.
We write feature logic once, in dbt or Spark, and use it for both training and scoring. That way production and testing agree on what every feature means.
We do batch scoring into tables or real-time endpoints, and track versions, approvals and lineage in MLflow or Unity Catalog so you can tell which model made which prediction.
We give every prediction an explanation and write model cards. When a model influences credit, insurance, housing or employment, explanation and human review may be legal requirements, for example under Colorado's 2026 ADMT law.
We pieced these together from Machine Learning Models situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Production models in the legacy workspace registry, retrained by hand
composite · not a client story
Beforethe situation
A dozen production models sit in the Databricks workspace model registry with Staging and Production stages. Retraining is a notebook someone runs after complaints, and nobody can say which data version trained the model now serving.
What we dothe work
We moved the models to Unity Catalog, replaced stages with aliases such as champion and challenger, and logged the data version and code commit with each training run. Retraining became a scheduled job with an evaluation gate against the current champion. Drift monitors on key features can trigger an early run.
Afterwhere you end up
Each model in serving traces to its data, its code and its evaluation. A worse-scoring challenger never gets promoted, and you roll back by changing the alias.
case file 02
A claim severity model that adjusters override and regulators question
composite · not a client story
Beforethe situation
A gradient-boosted model sets initial claim reserves. Adjusters override it often, a regulator has asked how it works, and the only documentation is the original notebook.
What we dothe work
We wrote a model card covering purpose, training data, known limits and evaluation by claim type. SHAP values put the top factors for each claim on adjusters' own screens. Overrides are captured with a reason, and we split evaluation by line of business to find weak segments.
Afterwhere you end up
We showed adjusters why the model suggested each reserve. The model card answers the regulator's first questions, and override reasons feed the next retraining.
How a predictive model goes from data to a decision someone acts on
We built feature pipelines that make the same features for training and scoring from governed tables. Registered models score new data, each prediction carries its explanation, and drift monitoring triggers retraining when inputs or accuracy change.
Feature pipelinesdbt · Spark · feature store → Training and evaluation · training set→ Batch or real-time scoring · live features
02 · Model lifecycle
Training and evaluationbaselines · gradient-boosted trees → Model registry · register version
Model registryMLflow · Databricks · Snowflake → Batch or real-time scoring · deploy
03 · Serving
Batch or real-time scoringjobs · endpoints → Business application · predictions→ Explanations · feature attributions
Drift monitoringinput drift · accuracy → Training and evaluation · retrain trigger
04 · Decisions
Business applicationCRM · planning · claims queue
Explanationstop drivers per prediction
Read the diagram as text
Source tables → Feature pipelines: transform
Feature pipelines → Training and evaluation: training set
Training and evaluation → Model registry: register version
Model registry → Batch or real-time scoring: deploy
Feature pipelines → Batch or real-time scoring: live features
Batch or real-time scoring → Business application: predictions
Batch or real-time scoring → Explanations: feature attributions
Drift monitoring → Training and evaluation: retrain trigger
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Frame
Target, decision, success metric and data sources agreed with the business owner.
step 02
Baseline
A simple model and a rules baseline, scored on held-out data.
step 03
Iterate
Features and models improved until the target is met or the evidence says it can't be.
step 04
Deploy and monitor
Registered model, scoring pipeline, monitoring dashboard and a retraining plan.
you keep
What you're left with
We write these for your Machine Learning Models setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
document01
Problem statement and success metric
yours to keep
design02
Evaluation report comparing baseline and final model
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Machine Learning Models work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you split training and test data so the evaluation matches real use?
If time-ordered data gets split at random, the future leaks into training. Split by time or by group and you get an honest number.
Q2
What simple baseline will the model have to beat?
A complex model often barely beats logistic regression or last period's value. When the gain is that small, the simpler model is cheaper to run and easier to explain.
Q3
How is a new version promoted, and how fast can we roll it back?
Promotion should be a recorded step with the evaluation evidence attached. With registry aliases, a rollback is a pointer change, so nobody has to redeploy.
Q4
Which input features are watched for drift, and what happens when one moves?
When labels come months after predictions, accuracy monitoring warns you too late. Input drift shows up first.
Q5
Will this model feed decisions about people, and what does that oblige us to do?
Credit, insurance, hiring and housing uses may be consequential decisions under Colorado's law, which requires notice, explanation and a path to human review.
01How much data do we need?
Enough examples of the outcome you're predicting, across the conditions the model will face. For rare events like fraud, the count of positive cases matters more than total rows. We check this in the first week.
02Should we do ML on Databricks or Snowflake?
Usually the one that already holds your curated data. Both do training, a model registry and scoring close to the data. If you move data between platforms just for ML, you add cost and a second copy to secure.
03Who should be able to access training data and model endpoints?
As few people and workloads as you can manage. Training jobs and endpoints run under their own service principals, with read access only to the tables they need. Scoring endpoints only answer authenticated callers. It's ordinary workload identity, applied to ML.
04How long until we have a first model?
It depends mostly on data access and quality. Once data is accessible, a baseline comes quickly. Getting data access approved is often the longest step.
05Should we move to MLflow 3?
It's worth planning if generative AI work is on your roadmap. MLflow 3 adds a LoggedModel entity, plus tracing and evaluation features aimed at GenAI applications. For classic models the gain is smaller. We test your tracking and registry code against it before switching.
related
Often paired with
Projects on Machine Learning Models usually end up touching one of these, so they're worth a look.
