One live picture of everything you run.
AnantState keeps a continuously updated model of your operation. Each store, account, machine or case in it has a current position and a direction of travel. Everything you see (the rankings, the prices, the alerts, the what-if) comes from that one model, which your data keeps correcting.
In plain termsThink of a flight tracker for your business: not just where each thing is now, but where it is heading and what it will cost if you do nothing.
At a glance
Where things stand and where they are heading
Each store, account or machine has a current position and a direction, so you see trouble before a limit is crossed.
Tested against the simplest guess
We check our forecasts against “nothing will change”, at the distance ahead you choose, and publish where we lose.
Controls built in
Separation between groups, a record of every action, and a check that can refuse an unproven model are enforced by the software.
Beside your systems
It mostly reads. Anything it changes is a named, recorded action.
What is actually running
Five layers, in dependency order. Each one is a page below.
Domain definition: your world, as data
You describe an area of your business: the things in it, what is measured about each, how they normally behave, which actions exist and what they cost, and how far ahead you need to be right. It is a description, not software, which is why one product can cover a payments business and a patient pathway. See ontology.
Baseline dynamics: the part that works on day one
The ordinary pattern of the business: seasons, opening hours, wear, the effect of known events. This is why the platform is useful before it has learned anything: the pattern is real knowledge, and the learned part only corrects it. See how the engine works.
Learned correction: the part that gets sharper
A specialized learned component predicts the correction to the baseline, not the state itself. It is not a language model and it generates nothing. Its influence is bounded, weighted and visible. See learning.
Evaluation and promotion: the part that refuses
Every new model is tested at the distance ahead you chose, against the simple guess that nothing changes. It is also checked for broken output and for what it was trained on. A model that fails is refused, and the refusal is recorded. See decision horizon.
Decision surfaces: the part people use
The forward view becomes a ranked list with prices. Each recommendation carries its likely effect and its cost. “Replay” answers what if we had acted; the what-if answers what if we act now.
What is actually running · five layers, in dependency order
- You own it
Domain definition
Your world, as data: entities, state, costs, horizon.
- Works on day one
Baseline dynamics
How state moves when nothing interesting happens.
- Gets sharper
Learned correction
A bounded, weighted, visible correction to the baseline.
- Can refuse
Evaluation and promotion
Every model is judged before it may serve, and can be refused.
- What people use
Decision surfaces
A priced queue, impact, what-if, replay, evidence, governance.
Three design decisions worth arguing about
This is where technical credibility is won or lost, so we state them plainly.
We model state, not events. An event stream tells you what happened. It does not tell you where a thing is. Modeling state gives you a position, a direction and an error bar, which is what a decision actually needs.
We evaluate against naive persistence, not against our own previous model. Beating your own last version is easy and meaningless. The honest question is whether you are better than assuming nothing changes. If we cannot beat that, we are adding cost and no information, and the platform says so.
We put governance inside the engine. A promotion gate that lives in a wiki is not a control. Ours is code, and so is tenant isolation, which is enforced in the database rather than in application logic. Controls that a bug can bypass are not controls.
How it lands in your estate
- Read-mostly by default. The platform consumes your events and reference data. It does not need write access to production systems to be useful.
- Actions are explicit. When you want the platform to act, an action is an audited call with a named actor and a recorded outcome. There is no hidden write path.
- Ingest is streaming or batch. Live streams, REST sources or scheduled pulls. Failed events go to a dead-letter view rather than disappearing.
- Your warehouse stays yours. The platform does not become your system of record.
A demo edition carries a built-in simulator for evaluation. Production editions run on your real sources only. See integrations and cloud native.
The engine does not change. The world does.
A store, a member account, a patient pathway and a turbine all have state.
What differs is the state, the dynamics that move it, and the actions available. Those are data in AnantState, which is why one platform spans six industries.
The platform, as an operator sees it
Every entity in one ranked list, with the money at stake beside it. This is OgMart, our fictional reference world.
Fictional reference world: OgMartJudge the engine on a domain you recognize
Bring one domain, a sample of real events and the decision you wish you could make earlier. We will evaluate it in the session and show you the model record, including the horizons where it does not win.