We build the models that forecast demand, find defects, flag unusual readings and plan maintenance, on your plant and business data in Databricks. Each one is trained on governed tables, tracked in MLflow and watched after go-live. You get a working model, a clear way to judge it, and a team that keeps it right.
Three things go wrong with most data science projects. None of them is about the algorithm. All three are solved by building the model on the same platform as the data, and by treating it as a product that has to keep working.
A data scientist builds a good model on a laptop. Then nobody can run it on live data, on a schedule, with the right access. We build every model on the platform it will run on, so the path from experiment to endpoint is the same platform, not a second project.
A model learns from the past. When machines, suppliers or customers behave differently, its answers slowly get worse, and nobody is told. We watch every model after go-live and retrain it when the numbers say so, not when someone happens to complain.
A customer, an auditor or a regulator asks why a decision was taken. The answer should not be a guess. Every model is registered in Unity Catalog with the data it read, its version, and the person who approved it. For European organizations that is not a nice-to-have. It is what the EU AI Act asks for.
From the first question to the model that is still right a year later. We are a Databricks Partner, and our data engineers, data scientists and cloud architects work as one team, so the data, the platform and the model are designed together.
Which decision will the model improve? Who takes it today, how often, and what does a wrong answer cost? We write this down first, with a success measure your finance team accepts. If a simple rule would do the job, we say so. Larger cases go through the same Decide step as every AI idea at Focaloid.
A feature is a value the model learns from, such as "orders in the last 28 days" or "hours since the last service". We build them once as feature tables in Unity Catalog, so training and live scoring use exactly the same numbers. For real-time use, the same features are served from an online store.
Every training run is logged in MLflow 3: the data it used, the settings, the results. A fast baseline first, often with AutoML, then better models on top. Simple methods where they work well, deep learning on serverless GPUs where images or sensor streams need it. The best model is chosen on evidence, not on a hunch.
A model is tested on data it has never seen, over time and by segment: by plant, by country, by customer group. We look at where it is wrong and whether that is fair. Then a short model card records what it is for, what it must not be used for, and its limits. A named person signs it off.
Some decisions can wait for tonight. Some cannot. We ship models as nightly batch scoring in SQL, as a real-time Model Serving endpoint that answers in milliseconds, or against streaming data. Everything is code, moved through your release pipeline with Databricks Asset Bundles.
Every prediction is stored in inference tables. Data Quality Monitoring (formerly Lakehouse Monitoring) compares live inputs and outputs against what the model learned from, and raises an alert when they drift apart. A retraining job runs, a person approves the new version, and the old one stays available.
Most business problems that a model can help with fall into one of six shapes. Pick one to see the question it answers, the data it needs, how it runs on Databricks and how we judge it. The examples are typical of the European manufacturing and industrial companies we work with.
Demand per product and plant, energy use per site, call volume per hour, cash collection per month. The model learns the pattern in your history, adds what you know about the future (promotions, holidays, weather, orders already placed), and gives a number with a range around it. Planners stop arguing about the number and start deciding what to do with it.
Which service contracts are at risk of not being renewed, which supplier deliveries will arrive late, which service tickets are urgent, which quality complaints need an engineer first. The model gives every row a score between 0 and 1 and the main reasons behind it. Your team works the list from the top instead of guessing where to start.
A pressure reading that is wrong for this time of day, an invoice that does not look like the others from that supplier, an energy reading that does not fit the shift pattern. The model learns what normal looks like, including its daily and seasonal rhythm, and flags what falls outside it, with a note on why. People see a short list, not a wall of alarms.
Vibration, temperature, current and cycle counts from the machine, plus the service history and past failures. The model estimates how much useful life is left and which component is wearing, so the service is planned into a quiet shift instead of interrupting a busy one. Spare parts are ordered before, not after.
Which spare part a dealer will need next, which accessory a customer is likely to add, which of two hundred service jobs a technician should do first. The model ranks the options for this customer, this machine or this moment, from what similar cases did before. Sales teams and web shops stop showing everyone the same list.
Cracks and scratches on a part, a label that does not match the order, a pallet that is short, the number plate at the gate, the reading on an old analogue gauge. A vision model looks at every image the same way, every time, and says what it sees with a confidence you can set a threshold on. People check the doubtful ones, not all of them.
This is the path every model takes with us, on Databricks, from the first conversation to the version that replaces it a year later. Each step names the tool it runs on and the thing you hold in your hands at the end of it.
This is why we build models on Databricks rather than next to it. Every box below lives inside Unity Catalog, so one set of permissions, one lineage and one audit trail cover the data and the models that read it. Nothing is copied out to be modelled somewhere else.
Every training run is logged, so choosing a model is a comparison you can read, not an opinion. Sort the runs by error, by cost or by training time and watch the trade-off. Then see the four checks a model has to pass before it is allowed to make a decision.
The last six months are kept back. The model never sees them during training. Its error on those months is the number we report, not the one from the training data.
We replay the last year month by month, as if the model had been live. A model that is good on average but bad every December does not pass.
Error is checked per plant, per country and per customer group. Where people are involved, we check that no group is treated worse without a reason you would accept.
Before it decides anything, the model runs beside the old process for a few weeks. We compare the two on the business measure agreed in step one. Only then does it go live.
A model is right on the day it goes live. Then prices move, a supplier changes, a new product line starts, and its answers quietly get worse. The chart shows the same model over a year, with and without monitoring. Switch between the two.
Are the live inputs still like the training data? Are the predictions still spread the way they were? And once the real numbers come in, was the model right? All three are compared every day in Data Quality Monitoring.
Each model has limits set with you before go-live: how much drift is acceptable, how much error is too much. Crossing one sends an alert to a named person and can start a retraining job automatically.
The retrained model becomes a challenger. It has to pass the same four checks as the first one. Then someone moves the @champion alias, and the old version stays available in case you need to go back.
Models on Databricks are registered in Unity Catalog next to the tables they read. That gives them the same four things the data already has. For European organizations this matters twice: for your own auditors, and for the rules that now apply to AI.
Who may train on which tables, who may call which model, who may move the champion alias. One permission model for the data and the models that read it.
From the source table to the feature, the model version, the job that scored, and the app that read the result. In both directions, so a change upstream shows which models it touches.
Every approval, every scoring run, every access request, kept in system tables you can query. An auditor's question becomes a SQL query, not a week of reconstruction.
A model card for every model: what it is for, what it must not be used for, how it was tested, its known limits, who signed it off. Written while the model is built, not reconstructed later.
Your data stays in your cloud account, in the region you chose, including EU regions. Training and scoring happen inside your workspace. Nothing is copied out to us. Our own practice is certified to ISO/IEC 27001:2022.
The EU AI Act asks for logging, documentation, human oversight and monitoring for higher-risk uses. Which category applies is a decision for your legal team. What we can promise is that the evidence they will need is produced as a by-product of how the model is built, not as a project afterwards.
Not every problem needs a model, and we would rather tell you that in the first call than in month three. Answer the three questions for a decision you have in mind and see what we would most likely recommend.
There is no trick here. The three answers are the first three things we ask in a discovery call, and they decide most cases before any data is opened.
Talk it through with us →This is our shape for a first model on Databricks. Twelve weeks is our target, not a promise: the first two weeks tell us whether the data supports it, and if it does not, we say so and stop there.
We agree the decision, the success measure and who owns the result. Then we open the data with your team and answer one question honestly: is there enough history, of good enough quality, to learn from?
Feature tables in Unity Catalog, a baseline model in the first week, then better ones logged in MLflow. Your data scientists work alongside ours, in your workspace, from day one.
The four checks. The model card. Deployment as batch or endpoint through your CI pipeline. Then a few weeks beside the old process, compared on the measure from week one.
Monitoring with agreed thresholds, alerts to named people, a retraining job, and a runbook. Your team owns the model from here. We stay on call if you want us to, and taper off when you do not.
A model is only as good as the data behind it. For thirteen years we have built and run the applications and data platforms that European plants work on every day. Three of those engagements, described rather than named. Each has its own case study.
Test-order planning across plants, production-line configuration for process engineers, supplier risk across four divisions, and the daily reporting the plants run on. The kind of operational data a forecasting or quality model is trained on.
Sensor thresholds tracked against equipment wear, so the limit a plant runs to reflects the state the equipment is actually in. Sensor history against wear is exactly the data an anomaly or maintenance model needs.
Master data across plants and product lines, and engineering drawings that used to be keyed in by hand now digitized, structured and searchable. Clean master data is what makes a model's features trustworthy.
We build models in two places on this site. The difference is not the mathematics. It is where the model lives and what it inherits.
For teams whose data lives on a cloud warehouse, a mix of systems, or their own MLOps tooling. We design the governance, monitoring and serving per project, with the tools you already have.
For teams on Databricks, or moving there. The model inherits the platform's governance instead of getting its own: Unity Catalog for access and lineage, MLflow for experiments, Model Serving and monitoring built in.
"We have Databricks and good dashboards. We have no models yet."
The foundation is there. The first model is the smallest step you can take that changes a decision rather than a report.
"Our data scientists' models never reach production."
Usually the missing piece is the path, not the people. We build the path once and your team uses it for every model after.
"We forecast in spreadsheets, and everyone has their own."
One forecast, with a range, from the same governed data every week. Planners argue about what to do, not about the number.
"We find quality problems after the parts have shipped."
Vision on the line and anomaly detection on the process data find them before the parts leave, and show you where they come from.
"A model from three years ago is still running. Nobody knows if it is right."
We put it under monitoring, measure it against reality, and either retrain it or retire it. Both are better than not knowing.
"Our AI plans depend on predictions we do not have yet."
Agents that plan, allocate or recommend need models underneath them. Build the models first, on the same platform, and the agents get them for free.
The questions we hear most often in a first call, answered the way we answer them in the room.
No, but you need governed data somewhere. If you are on Databricks, we start with one domain of your Gold tables. If you are not, our Data Engineering practice builds one governed domain first, in your cloud account, and the first model follows on top of it. A model on messy data is a slower way of finding out the data is messy.
Nowhere. It stays in your own cloud account, on AWS, Azure or Google Cloud, in the region you chose, including EU regions. Training, scoring and monitoring all run inside your Databricks workspace. We work in your workspace under your access rules. Nothing is copied out to us. Our practice is certified to ISO/IEC 27001:2022, and we sign your data processing agreement before we see any data.
Same people, same methods, different home. AI Studio builds models for any stack and designs the governance and monitoring per project. This page is for teams on Databricks: the model lives in Unity Catalog with the data, and it inherits the platform's access control, lineage, serving and monitoring instead of getting its own. If you are on Databricks, this is the cheaper and safer route.
Our target is twelve weeks from the first workshop to a monitored model in production, and most first models land inside that. The honest caveat is the data: the first two weeks are a gate, and if the history is not there or not good enough, we tell you and stop. You then know exactly what to collect, and for how long, before it is worth trying again.
We do not replace them, and we do not want to. Most teams are good at building models and short of the path that gets a model into production and keeps it there: feature tables, MLflow discipline, serving, monitoring, retraining, the model card. We build that path with your team, on your platform, leave a runbook, and hand over. After the first model, your team runs the next ones on the same rails.
Mostly the first. The models on this page learn from your numbers: forecasts, scores, anomalies, rankings, images. That is classic machine learning, and for these questions it is usually cheaper, faster and easier to explain than a large language model. We use language models where they earn their place, for example to read supplier documents or drawings into features, or through ai_query in SQL. Agents that read, write and act across systems are a different kind of work, on our Agentbricks Development page, and a model from this page often sits inside one.
It depends on how often the model answers and how fast. A nightly batch job that scores a table in SQL costs a few minutes of serverless compute a day. A real-time endpoint costs more because something has to be ready to answer at any moment. We design for the cheapest way that meets the need, and we tag every model so its spend shows up per model in the Databricks system tables. You will know what each one costs, every month.
Every model is wrong sometimes. The work is knowing how often, on which cases, and what happens then. Before go-live we write down the model's limits and agree thresholds. For decisions with real consequences, the model recommends and a person decides. After go-live, monitoring tells us when the error grows, and the model is retrained or, if the world has changed too much, retired. That is written into the runbook on day one.
You do. The code is in your repository, the models and feature tables are in your Unity Catalog, the experiments are in your workspace, and the runbook is yours. There is nothing of ours you have to keep paying for to keep the model running. We are happy to stay on call, and equally happy to hand over completely.
Bring one decision your team takes every week and would like to take with better information: what to order, which machine to service first, which parts to check. We will tell you in the first call whether a model is the answer, what data it needs, and what the first twelve weeks would look like.
Thirty minutes, no slides. We ask the three questions from this page, look at what data you have, and give you a straight view: rule, model, agent, or not yet. If it is a model, you leave with the shape of a twelve-week first build and what it would cost.
Four fields. A person who has read your note replies within one working day with a time for the call.
Someone who has read your note will reply within one working day with a time for the call. If you know which tables or systems the data lives in, have the names ready. That is where the conversation starts.