Machine learning
Models that hold up after the data moves
You get a model trained on your own operational data and held to an accuracy threshold you set. Then it is monitored for the day reality stops matching what it learned.
The short version
4 things that decide this
- 01Machine learning development means training a model on your own records so it outputs a number or a label: a failure prediction, a risk score, a category.
- 02The threshold a model must clear before it ships is set by you, not by us, because only your team knows what a wrong answer costs.
- 03A model trained once and never re-checked decays quietly, since the behaviour it learned from keeps changing after launch.
- 04Simple models win more often than teams expect, and we will tell you when a rule your operations team already knows beats anything we could train.
The accurate model that changed nothing
The common failure is not an inaccurate model. It is an accurate one that arrives too late, lands in the wrong screen, or tells somebody something they cannot act on.
A churn score is worthless if nobody has budget to make a retention offer. A failure prediction three hours out is worthless if the part takes two days to arrive. The model was right and the project still failed, because nothing downstream of it changed.
So our first question is never about algorithms. It is who acts on this output, in which screen, and what they are allowed to do about it. If the answer is fuzzy, the model is premature and we will say so.
This is not the same service as our generative AI work
Machine learning here means supervised models trained on your data that output a number, a category or a ranking. Generative AI outputs language. Both are AI, and the way you prove either one works is completely different.
A prediction model is checked against outcomes that actually happened, which makes accuracy measurable in the ordinary statistical sense. A language model is checked against answers your experts wrote down, because there is no single correct sentence. Confusing the two is how a project ends up with a dashboard nobody can validate.
One more line worth drawing. Model engineering is our page for prediction, scoring and vision models tuned on operational data. This page covers the same discipline from the buyer's side: what you get, what it costs you in risk, and how we prove it works.
- 01Output is a number or a label: this page, and model engineering next to it.
- 02Output is prose, a draft or a summary: generative AI development.
- 03You want the model to act on its own conclusion: that is an agent, and the safety work changes.
What is running now
Counted, not estimated
22
production systems we have shipped and can name
5
permission tiers in TankAware's multi-tenant build
50+
ESG topics Greenlight's scoring model covers per company
10-15
independent sources behind each Greenlight topic
What we build around the model
The model is a fraction of the delivery. These are the parts that decide whether it survives.
A data audit that tells you whether you have enough history to train on at all, before anybody spends money finding out you do not.
A written accuracy threshold, set by your team, that the model has to clear before release. We do not move the bar to hit a date.
A baseline built from the rule your operations team already uses, so you can see what the model adds over what you have.
The output delivered into the screen where the decision is made, not a separate dashboard someone has to remember to open.
Monitoring that watches accuracy after launch, so drift shows up as an alert rather than as a complaint.
A retraining path, either run by us under an agreed service level or handed over documented to your own team.
What we will tell you not to build
- A model where a simple threshold rule performs nearly as well and is far easier to defend.
- A prediction nobody has the authority or the budget to act on.
- Anything trained on a dataset too small or too clean to resemble what arrives in production.
- Audit the dataDo you have enough history, and is it labelled?
- Set the barYour threshold, written down before training.
- Beat the baselineCompare against the rule you use today.
- Validate honestlyTest on a period the model never saw.
- Ship into the workflowInto the screen where somebody decides.
- Watch for driftAccuracy tracked, retraining planned.
The fourth station is where most projects quietly cheat. A model tested on data drawn from the same window it trained on will look excellent and disappoint you the week it goes live.
A model that learned tomorrow's answer by accident
The most expensive bug in this work is a model that scores brilliantly in testing and poorly in production. It usually means a column in your training data quietly contained the answer.
A field that gets filled in only after the outcome is known. A record updated when the case closes. The model learns to read that field and looks like genius. On the day it runs live the field is empty, and the accuracy collapses with no error message anywhere.
Catching it takes someone who knows your business asking, of every input, when does this value actually get written. That session is unglamorous and it is the single highest-value hour in the project.
- Validation runs on a later time period than training, always.
- Every input is traced to the moment it is written, not the moment it is read.
- The model competes against your current rule, and sometimes loses.
- Where the model scores people or their access to something, we design for explaining the score, because you will be asked.
What we build on
Modelling
Data
Serving
Run
Systems where a score had to be defensible
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The usual machine learning project against ours
Both produce a model. They separate on whether anyone can still trust it a year later.
| Criterion | The usual approach | How we build |
|---|---|---|
| Who sets the accuracy bar | The team building it, after seeing the results. | Your team, in writing, before training starts. |
| What it is compared against | Nothing, or another model. | The rule your operations team uses today. |
| How it is validated | A random split of the same data. | A later time period the model never saw. |
| Where the output lands | A dashboard somebody has to remember. | The screen where the decision already happens. |
| When the world changes | Nobody notices for two quarters. | Accuracy is tracked and drift raises an alert. |
| After launch | The contract ends at go-live. | An agreed service level, or a documented handover to your team. |
01How much data do we need before this is possible?
Enough examples of the thing you want to predict, including enough of the rare outcome, matters more than total volume. A million rows containing eleven failures will not teach a model what failure looks like. We answer this in the data audit rather than guessing, and sometimes the answer is to start collecting properly and revisit in a year.
02How do we know the model is actually good?
You set a threshold before training, and the model either clears it on a time period it never saw or it does not ship. Your current rule gets scored on that same test. A model that barely beats a rule is rarely worth the maintenance. The comparison is the honest measure, not the headline accuracy.
03Can the model explain why it scored something that way?
Yes, and where a score affects a person we treat that as a requirement rather than a feature. Simpler models explain themselves more readily, which is one reason we do not reach for the most complex option first. If your regulator or your customer will ask for a reason, that constraint belongs in the design from day one.
04What happens when the world changes and the forecast stops working?
Accuracy is monitored against real outcomes after launch, so a decline shows up as an alert rather than as a complaint from operations. Then the model is retrained on recent data and re-tested against your threshold. This is the part most projects leave out, and it is why a model that was good in year one is often quietly wrong in year two.
05Is this different from the reporting our BI tool already does?
Reporting tells you what happened, and a model estimates what is likely to happen next. If your question is answerable by a well-built report, that is cheaper and easier to defend, and we will point you there. The line is whether you need a description of the past or an estimate about a specific future case.
06Could a simple rule replace the whole project?
Often enough that we build the rule as a baseline precisely so you can find out. Operations teams often carry a heuristic that is startlingly good, and beating it by a small margin is not always worth the ongoing maintenance. Finding that out in week two is a good outcome, not a failed project.
07Do you fine-tune large language models?
That is a different service and we are direct about where we have shipped. Our machine learning work is applied prediction, scoring and vision on client data rather than foundation-model fine-tuning. Where a language model is the right answer, our generative AI and RAG pages describe what we actually run in production.
08Does this suit a small company or only large data teams?
One narrow prediction with a clear owner is a reasonable first project at any size, and SmartREI's investment analysis is not an enterprise system. What matters is having enough history and one person who can act on the output. Scoping conversations cost nothing, and where we have to go inside an existing codebase to answer honestly, a paid two-week diagnostic comes first.
Related
- Model engineering →The same discipline, described from the engineering side.
- Predictive analytics →Forecasting where the decision is already defined.
- Data engineering →The pipelines a model needs before it can learn anything.
- Computer vision →Models that read images rather than records.
- Why clinical AI models fail in production →Dataset shift, with the published evidence.
