Model engineering that catches the problem before a person does
Prediction, scoring and vision trained on your own data. TankAware reads sensor and inspection data across petroleum sites and flags a tank before it fails.
- 4.8 on Clutch across 22 reviews
- PremiumAudit.io: audit cycle cut 75%, calculation errors cut 95%
- In production for SmartREI, Tankaware, ZyloBase, KiwiWrite
What to know first
4 things that decide this
- 01Model engineering trains a machine learning model on your own operational data to predict an outcome, score a risk, or read an image, rather than calling a general-purpose API that has never seen your business.
- 02Accuracy on a test set is not the number that matters. What matters is the cost of the mistake the model makes most often, and which way you would rather it err.
- 03A model decays on its own. Equipment ages and behaviour drifts, so the same code gets quietly worse every month unless somebody is scoring it.
- 04Hashlogics built the predictive maintenance model inside TankAware, where Sutherland Excavating Ltd. reported 40% fewer manual errors after launch.
The pilot that scored 94% and helped nobody
Most failed machine learning projects were never inaccurate. They were accurate about something no one had to decide.
A defect model reaches 94% and lands in a report the line supervisor never opens. A risk score arrives a day after the credit call has been made. Maths held up fine. Both models simply sat outside the moment where somebody chooses.
A second failure runs quieter and costs more. Nothing errors. Confident answers keep arriving while the sensors drift and the product mix changes. Readings it was trained on stop describing the plant it now runs in. You find out when a customer tells you.
Three shapes of model, and what each one is for
Prediction
The model watches patterns in your data and calls what happens next: a pump about to fail, a job that will overrun, an account about to go quiet. TankAware does this with sensor and inspection data across petroleum sites, and raises the alert while the tank is still fine.
Scoring and ranking
Several messy signals go in and one comparable number comes out, so a queue can be ordered. Greenlight scores a company's ESG performance across more than 50 topics, weighting AI judgement at 66% against hard data at 33%, with 10 to 15 independent sources behind each topic.
Vision
A camera feed becomes a decision: this part is scratched, that gauge reads 40, nobody is wearing a harness on the east platform. Vision is where the accuracy question gets sharpest, because a miss and a false alarm cost completely different amounts.
Computer vision →
What we have shipped
Counted, not estimated
22
systems in production
40%
fewer manual errors reported by TankAware's operator
50+
ESG topics Greenlight scores per company
5
permission tiers behind TankAware's data
- DecisionWho acts, and when.
- Data auditWhat you hold. What it is missing.
- BaselineThe simple rule to beat.
- Accuracy gateYour threshold, set before we train.
- ShipInto the workflow. Not a sandbox.
- ScorePredictions against outcomes.
The baseline sits third on purpose. Plenty of problems are solved by a threshold and a sort, and finding that out early is a good week, not a wasted one.
When a model has been shown the answer
The most expensive failure in this work looks like a triumph. Near-perfect scores in testing, then collapse in the first week of real use.
Nothing was faked. The test set simply held a clue that will not exist at the moment of the real decision. A churn model that can see the cancellation date. A defect model trained on photos taken after the part was pulled off the line. A risk score built from a field the back office fills in later.
So the test gets built around the moment the decision actually happens, using only what a person would have known then. The score usually drops. What you get back is a model that works.
That check belongs before anything ships, not after. A leak found in review costs a conversation. The same leak found in production costs the trust of everyone who was told the number was good.
- Tests cut off at the moment the decision would be made.
- Late-arriving and corrected fields treated as what they are.
- Every model measured against the simple rule, which sometimes wins.
- Predictions and outcomes stored side by side, so accuracy stays checkable a year later.
Kept accurate, or handed over properly
A model that drifts quietly is worse than no model, because people have already started trusting it.
Every build ships with the scoring loop attached: predictions and real outcomes land in the same place, and the gap between them gets reported. When the gap widens, that is a retrain on a schedule rather than an emergency at 2am.
You choose who runs that loop. We can stay on it under an agreed service level, or hand your team the retraining runbook, the evaluation set and the thresholds. Both are real options. Neither is a handshake.
What we build on
Modelling
- Python
- scikit-learn
- Gradient boosting
- PyTorch
- OpenCV
- Rule-based scoring
Data
- PostgreSQL
- Supabase
- AWS RDS
- AWS S3
- IoT sensor pipelines
Delivery
- FastAPI
- Laravel
- React
- Scheduled jobs
- Webhooks
Run
- AWS
- Docker
- GitHub Actions
- Sentry
Models running unattended in production
“TankAware has revolutionized how we manage petroleum sites. The real-time data and automation have exceeded expectations.”
Blake Sutherland · President, Sutherland Excavating Ltd.
How most model projects run, and how ours do
Both end with a trained model. Only one of them is still right in March.
Where it starts
The usual approach
With the data that happens to exist.
How we build
With the decision it changes, and who makes it.
The bar
The usual approach
Accuracy, quoted as one number.
How we build
The error you can live with, split by which mistake it is.
The comparison
The usual approach
The model against nothing.
How we build
The model against a simple rule, which sometimes wins.
Where it lands
The usual approach
A dashboard, or an API nobody wired up.
How we build
Inside the screen where the work already happens.
Month six
The usual approach
Still running. Nobody has checked it.
How we build
Scored against real outcomes, retrained on a schedule.
01How much data do we need to train a custom model?+
Enough labelled examples of the thing you care about. That is a smaller number than most people fear, and a cleaner one than most people have. A few hundred well-labelled defects beat fifty thousand images nobody checked. So we audit what you hold first, because the honest answer often changes once somebody looks.
02What is model engineering, and how is it different from generative AI?+
Model engineering produces a number, a category or a box on an image: a failure prediction, a risk grade, a defect flag. Generative AI produces new text, code or pictures. The difference that matters commercially is checkability. A prediction can be compared against what actually happened, so you can prove it earns its place.
03Our accuracy target is 99%. Is that realistic?+
Usually the wrong target, and quoting it back is the first thing worth challenging. If one part in a thousand is defective, a model that says "fine" every single time is 99.9% accurate and completely useless. Set two numbers instead: how many misses you can carry, and how many false alarms your team tolerates before they ignore the alerts.
04When is a machine learning model the wrong answer?+
A machine learning model is the wrong answer whenever a plain rule would do the same job, and that is more often than vendors admit. Sorting by age and flagging anything over a threshold is free, explainable, and never fails in a surprising way. A model earns its place in three cases: many signals interact, or the volume makes a small gain worth money. Or the input is an image or a sound, where rules cannot reach.
05What is AI predictive maintenance?+
Predictive maintenance reads sensor and inspection data to flag equipment problems before they turn into failures. We built this inside TankAware for petroleum site management, alongside inspection scheduling and deficiency tracking. Sutherland Excavating Ltd. reported 40% fewer manual errors and 30% less operational overhead after launch.
06Do you fine-tune large language models?+
Our model engineering work is applied machine learning: prediction, scoring and vision trained on client data. Fine-tuning a language model answers a different question, and it is worth a direct conversation about which one your problem actually is. Bring the use case to a scoping call and you will get a straight answer.
07Who owns the model and the training data?+
You do. Weights, training pipeline, evaluation set and code are all yours, handed over as working artefacts rather than a zip file. Your data trains your model.
08How does this work if we already have a data science team?+
Then the gap is usually production, not modelling. Teams with strong notebooks often have no scoring loop, no retraining schedule and no plan for the day the accuracy slips. We build that layer around models your people own. It suits an enterprise team with a backlog, and equally a startup whose one engineer also runs everything else.
09How do we know it still works six months in?+
Because predictions and outcomes are stored together and compared on a schedule. Without that, a model can be badly wrong for a year and look authoritative on a screen the whole time. This is the part most builds skip, and it is the reason so many models get quietly switched off. The first 2 months of support and maintenance are free, with every build.
Related
- Machine learning development →The wider build this sits inside.
- Computer vision →When the input is a camera.
- Model engineering vs generative AI →Which one your problem actually needs.
- MLOps consulting →Keeping a shipped model honest.
- Dataset shift →Why a good model gets quietly worse.
- Label leakage →The 99% score that means nothing.
- TankAware →Predictive alerts across petroleum sites.
