AI · Machine Learning & Predictive Intelligence
A prediction is a claim about the future. It has to be tested against a past it never saw.
Noble builds predictive systems on an organisation’s own operational history: demand and load forecasting, anomaly and exception detection, classification and scoring, recommendation and ranking, and decision intelligence that compares scenarios under real constraints for a person to choose between. Each is evaluated on data it was never trained on before anyone sees it, and each is deployed as advice first, with its record in production deciding whether it may ever be more.
Where the effort actually goes
The model is a small fraction of a predictive system, and choosing it is a small fraction of the work. Most of the effort is in the data: finding the history, joining it across the systems that hold it, establishing what it can and cannot support, and building the features a model can learn from — the lag, the seasonality, the calendar, the event that happened three weeks before every spike. A forecasting project that starts with the algorithm has started at the wrong end.
The second place the effort goes is the question of what "wrong" means. A demand forecast that is wrong by a little every day and a fraud model that is wrong once a year are wrong in different ways, and cost different amounts. Noble frames that before any model is built, so that the evaluation measures the cost the organisation actually bears — and so that the decision to deploy is a decision about that cost, made by the person who bears it.
From a question to a model in production
The two gates are the honest moments: evaluation on held-back data, which decides whether to deploy at all, and the advisory boundary, which decides what the model’s answer is allowed to do once it is there.
- 01FrameWhat wrong costs
- 02Data and featuresMost of the work
- 03TrainSimplest model that answers
- 04EvaluateHeld-back data; deploy or not
- 05AdviseA person decides; recorded
- 06MonitorDrift, and re-evaluation
What the service covers
Forecasting against operational history
Demand, load, consumption, arrivals, revenue by period — forecast from the organisation’s own history with the calendar, the seasonality and the known events built in as features. The forecast is delivered with its uncertainty, not as a single line, because a planner who knows the range plans differently from one who is given a number.
- Demand, load and consumption forecasting by period
- Calendar, seasonality and known events as features
- Forecasts delivered with their uncertainty
- Re-forecast on a rhythm as the history grows
Anomaly and exception detection
The transaction, reading, login or invoice that does not look like the others — surfaced for a person to look at, with the reason it was flagged. Built to the organisation’s tolerance for false alarms, because a detector that flags everything is turned off within a week, and one that flags nothing was never worth building.
- Outliers in transactions, sensor readings and events
- Each flag delivered with the reason
- Alarm threshold set to the organisation’s tolerance
- Feedback from the reviewer returned to the model
Classification and scoring
Which category a request belongs to, which queue a ticket should go to, how likely an account is to churn, which asset is most likely to fail next. Scores are delivered with their confidence and their most important inputs, so the person acting on one can see why — and so the organisation can notice when the model has learnt something it should not have.
- Routing, prioritisation and risk scoring
- Scores delivered with confidence and key inputs
- Bias in the training history examined before deployment
- Thresholds set with the person who acts on the score
Recommendation and ranking
The next product, the likely part, the relevant document, the best-matched engineer — ranked from behaviour and attributes the organisation already records. Built so that the ranking can be explained and so that a business rule can override it, because a recommendation the organisation cannot reason about is one it cannot stand behind.
- Ranking from recorded behaviour and attributes
- Explainable, and overridable by a business rule
- Served into the screen where the choice is made
Decision intelligence
Scenarios compared under real constraints — capacity, cost, lead time, policy — for a person to choose between. Optimisation and simulation where the decision is large enough to deserve them: which plant, which route, which schedule, which mix. The system proposes and shows its working; the person chooses and the choice is recorded.
- Scenario comparison under real constraints
- Optimisation and simulation for large decisions
- The working shown; the choice recorded
Evaluation, and the advisory boundary
Every model is measured on data held back from training — including the periods and cases it is expected to fail on — and the result is a decision about whether to deploy at all, reported as it is. Once deployed, the model advises: its suggestion, its confidence and the person’s decision are recorded, and that record is what eventually justifies letting it act alone on the cases it has proved itself on.
- Held-back evaluation, including expected failures
- Deploy-or-not decided on the result, reported as it is
- Advisory by default; suggestion, confidence and decision recorded
- Drift watched, and re-evaluation on a rhythm
Where this connects
- AI Engineering, MLOps & GovernanceFeature pipelines, serving, versioning, rollback and drift monitoring — the machinery that keeps a model honest after it ships — are that page.
- Computer Vision & Document IntelligenceWhen the history is images or documents rather than rows, the same evaluation discipline applies to a different kind of model.
- SAP Automation, AI & Intelligent EnterpriseOn an SAP estate the operational record is where prediction finds something real to run on, and that page is where the prediction is served into the process.
The services alongside
- Data & AnalyticsThe history a model learns from has to agree with itself first. This is the dependency, not one of several.
- SAPOn an enterprise estate the operational record usually lives in SAP, and the reconciled layer built there is what the models here train on.
- CloudWhere training and serving run, what they cost, and which region the data may be in.
Start with a decision somebody makes repeatedly.
And a record of how it has been made before. That is enough to establish whether there is a model here at all, and it is a cheaper question than most organisations expect.