Models trained on your data, running where it matters.

How much data do we need?

It depends on the problem, but as a rough guide: a few thousand labelled examples for tabular classification, considerably more for anything with images or rare events. Week two exists to answer this specifically rather than in the abstract.

What if our data is messy?

All data is messy. What matters is whether the labels are trustworthy and whether the features available at prediction time match those in your history. Messy but honest beats clean but leaky every time.

What is leakage and why do you keep mentioning it?

Training on information that would not exist when the prediction is actually made. It produces spectacular test scores and a model that fails in production, and it is the single most common reason ML projects disappoint.

Can you use data we cannot move?

Yes. Training can run inside your VPC or on your on-premise infrastructure, with nothing leaving your environment.

What if the answer is that we do not have enough data?

Then we say so in week two and recommend instrumentation instead. That is a cheap finding at that stage and an expensive one at month four.

Why start with a naive baseline?

Because a meaningful proportion of prediction problems are solved almost as well by a simple rule. Knowing the gap is the only way to judge whether the model is worth its maintenance cost.

Which algorithm do you use?

For tabular data, gradient boosting wins most of the time and we start there. Deep learning where the data is images, audio or sequences. We choose on measured performance, not novelty.

Can you explain individual predictions?

Yes, with feature attributions per prediction. For regulated decisions we can also constrain the model class to something inherently interpretable, trading a little accuracy for defensibility.

How do you handle bias?

Performance is measured across the groups your regulator or ethics review cares about, not just in aggregate, and disparities are reported rather than averaged away.

How often does it need retraining?

Driven by drift rather than the calendar. We set thresholds during the build and the pipeline retrains automatically when they are crossed, with validation before anything is promoted.

How is this priced?

Fixed fee for feasibility and for the production build, monthly for model operations. No licence and no charge per prediction.

What do we own?

Training code, model weights, feature pipelines, evaluation notebooks and the serving infrastructure, in your repositories and your cloud accounts.

Can our team maintain it?

That is the intent. We use standard tooling for exactly this reason, and handover includes the retraining runbook and pairing with whoever will own it.

Do we need a data scientist on staff?

Not to keep it running, if the retraining pipeline and monitoring are in place. You do need someone who can act when an alert fires, which is usually an engineer rather than a specialist.

What if the model stops performing?

Monitoring catches it before your users do, and the retained format covers diagnosis and retraining. If a model can no longer beat its baseline, the right answer is to retire it and we will say so.