Predictive machine learning.
A forecast that says how sure it is, and what it beat.
Every prediction is derived data, never a ledger fact. It carries uncertainty, provenance and a baseline — so “is this model actually any good?” is answerable from the stored prediction alone, months later.
Classification, regression, duration and demand.
The methods are ordinary; the discipline around them is not. A prediction is made as of a business time, from data with a stated cut-off, about a named subject, for a named target, over a stated horizon — and every one of those is recorded rather than implied.
- Classification — will this invoice be disputed, is this line likely to be returned, does this ticket belong in that queue.
- Regression and quantities — demand for a line, expected collections, cost at completion.
- Survival and duration — how long until this is paid, how long this job actually takes, which is a different question from the average of the ones that finished.
- Calibrated intervals rather than a bare confidence figure, because a range is usable for a decision and a percentage generally is not.
- Predictive anomaly risk — not just what is unusual now, but what is on course to become a problem.
- Abstention — when the data is insufficient the estimate is null and the reason code says why, rather than a confident number produced out of nothing.
A prediction envelope, and what is on it.
The fields exist to make the prediction auditable long after the moment it was useful.
- Subject and target — what it is about, and the named quantity predicted.
- Prediction as-of, and the data cut-off — two different times. The gap between them is what makes late-arriving facts auditable rather than invisible.
- Point estimate, quantiles and unit — the unit explicit, never inferred, and the estimate nullable when the model abstains.
- Calibration state — whether the number has been calibrated, by what method, and when. Never defaulted from a raw model score.
- Baseline identifier and baseline value, always present — so whether the model beat the obvious alternative is answerable from stored data.
- Reason codes and data-quality warnings, including the abstention reason.
- Model, feature and dataset versions — the reproducibility triple.
- Generated-at and expires-at — a freshness contract enforced when it renders, so a stale prediction does not quietly keep advising you.
- Deployment state — shadow, advisory, active or retired.
Advisory derived data. Never authority.
A prediction never carries permission, ledger, tax or approval authority, and it degrades safely: missing, invalid, expired or unavailable are all handled states rather than crashes or silent zeros. A model in shadow state produces predictions nobody sees, so it can be measured before it is trusted — and a model that stops beating its baseline is demoted rather than defended.
Where a number about the future would change what you do today.
- “When will this actually arrive?” — supplier lead time as a distribution, not a promise date copied from the order.
- “Which customers are about to churn?” — with the interval, so a borderline case is visibly borderline.
- “How much of this will we sell?” — demand by line, feeding safety stock and replenishment.
- “Will this be paid on time?” — expected collections, which is a duration question rather than a yes-or-no one.
- “Is this job going to overrun?” — predictive monitoring on something still in flight.
Frequently asked questions.
Does a prediction ever post to the ledger?
Never. Predictions are derived data. The posting service remains the only thing in Cobalt ERP that writes a journal, and it does not read predictions.
What is the baseline for?
So the question “is this model earning its place?” can be answered from stored predictions rather than from a memory of how the pilot went. Every prediction records what the obvious alternative would have said.
Why intervals rather than a confidence percentage?
Because a range is actionable and a percentage usually is not. “Between eleven and nineteen days” changes what you promise a customer; “87% confident” does not.
What happens when there is not enough data?
It abstains. The estimate is null and a reason code says why, which is more useful than a number invented to fill the field.
Does it learn from my corrections?
Outcomes are captured and models are re-evaluated against them, and any recommendation records that it was shown — so the effect of the system's own advice can be separated out rather than mistaken for skill.
See this engine on your own records.
Join the waitlist and ask it something real. Every answer names the engines it used and the records they read.
Join waitlist