What we do
The science behind the forecast.
We built a forecasting engine that works where conventional AI doesn't — and explains itself when it does. This page is the technical overview: what we do, why it's different, and what it means for the platforms that embed us.
Section 1
The anxiety.
If you've been near forecasting tools in the last decade, you've probably been burned. The dashboard promised demand prediction; the operators on the floor stopped trusting it within a month. The vendor pointed at the accuracy score; the user pointed at the day it confidently called busy and the restaurant was empty.
The trust gap is the real failure mode. Most forecasting tools hand you a number and ask you to take it on faith. When the number is wrong — and it always is, eventually — there is no way to tell why, so there is no way to recover trust. The tool becomes wallpaper.
That is the problem we set out to solve. Not "more accurate forecasts" in the abstract — but forecasts the people who depend on them can actually believe.
Section 2
CauseCasting.
Every TUBR forecast arrives with the causes that produced it.
Tuesday lunch covers: 142
Pending
Baseline (typical Tuesday)
124
Pending
Rain forecast
−18
Pending
School holiday
+12
Pending
Local event (rugby international)
+24
Pending
The operator sees the number and the four forces that built it. If they disagree with the rain effect, they can say so. If the local event was cancelled, they can adjust. If the forecast is wrong on the day, they can look back and see which signal misfired — and so can we.
We call this CauseCasting: forecasts built on causation, not correlation. A pattern-matcher tells you what usually happens. CauseCasting tells you what will happen given the specific forces in play right now, and shows you the forces.
Section 3
The science that makes it possible.
Explainability is not a feature you bolt onto a black-box model. It is a consequence of building a different kind of model from the start.
We start from a different premise. Instead of asking "what patterns are in this data?", we ask "what are the forces that drive this behaviour, and how do they combine?".
Our proprietary Physics-Informed AI approach builds models grounded in the underlying mechanics of demand and behaviour, not just the statistical surface. The model can name the forces because the model is made of the forces. That is why CauseCasting works as an output — not because we have added an explanation layer on top, but because the explanation falls out of the architecture.
Section 4
What it works on.
01
Sparse data.
Roughly 20% of what conventional AI needs. New sites get useful predictions in weeks, not after a year of data collection.
02
New conditions.
Because we model causes rather than correlations, the engine reasons about situations it has never seen.
03
Changing world.
When conditions shift, a pattern-matcher confidently repeats the old pattern. Our engine adapts.
Section 5
Delivery.
The engine is delivered as an API. Most partners embed it inside their existing product so their customers never see TUBR directly. Operations buyers plug it into their own pipelines and use the predictions to drive decisions.
We do not run a dashboard you have to log into. The forecasts go where the decisions get made.
Section 6
Scale.
One engine, many outlets. The architecture supports hundreds of locations from a single integration, each tuned to its own context without bespoke setup. Onboarding a new outlet is a configuration step, not a project.