Tomorrow’s prep, next week’s purchase and next month’s revenue require different horizons, update frequencies and error tolerances.
Openfluid Platform
A forecasting system should explain how a number becomes a decision.
Openfluid separates data preparation, forecasting, business rules and human approval. That structure makes it possible to test the model independently from the operational policy, and to see which part needs correction when the recommendation is wrong.
Backtested time seriesRules outside the modelHuman overrides recorded
01Observed dataSales, orders, items, stock, waste
02Forecast serviceBaselines, candidate models, intervals
03Operating rulesBuffers, lead times, batch sizes
04Decision recordAccept, override, reason, outcome
Data shape
The sample product already separates several forecasting grains.
History730 daysOutlets3Menu items10Ingredients10
The attached sample includes consolidated and outlet revenue, order counts, outlet-item demand, ingredient usage, closing inventory and recorded waste. A production implementation must preserve those grains instead of flattening everything into one daily total.
| Series family | Planning grain | Decision supported |
|---|---|---|
| Revenue and orders | Outlet × day | Targets, staffing context and performance outlook |
| Menu demand | Outlet × item × day | Preparation quantity and availability |
| Ingredient usage | Outlet × ingredient × day | Requirement and purchasing review |
| Closing inventory | Outlet × ingredient × day | Stock gap and transfer opportunity |
| Waste | Outlet × item × day | Over-preparation investigation and buffer review |
Forecast discipline
Evaluation comes before automation.
Train only on information that would have been available at the prediction date. Random train-test splits can leak future patterns into the past.
A complex model must outperform the previous week, same weekday and rolling average on the metric that matters to the decision.
Under-forecast and over-forecast errors may have different consequences. Stockout risk, holding life and preparation cost belong in the decision layer.
Architecture principle
Forecasts and policies are different systems.
What is likely to happen?
Produces expected demand, uncertainty and model metadata from historical and known-future inputs.
What should the team do?
Applies batch size, service buffer, supplier lead time, shelf life, minimum order quantity and risk appetite.
Why this matters: changing a kitchen buffer should not require retraining the demand model. Likewise, a better demand model should be testable without silently changing purchasing policy.
Operational foundations
Production readiness is broader than model accuracy.
⌁
Entity mapping
Stable outlet, menu-item and ingredient identifiers across every source and effective date.
✓
Data-quality gates
Freshness, duplicate, null, unit and conservation checks before a forecast is published.
⌂
Access control
Users see only permitted outlets, measures and actions; exports follow the same scope.
↺
Version and lineage
Every forecast records model version, data cutoff, generated time and applied rules.
!
Exception handling
Late files, missing inventory and unusual events are visible instead of silently imputed.
◎
Outcome capture
Accepted plans, overrides and actual outcomes create the evidence needed for improvement.
FAQ
Platform questions.
Is Openfluid one universal forecasting model?
No. The platform can share evaluation, orchestration and workflow components, but different series may require different models and business rules.
Does Openfluid require TimesFM?
No. The sample workbook is structured for time-series experimentation, and TimesFM can be one candidate. Production selection should be based on backtesting against appropriate baselines.
Can forecasts be recomputed without an LLM?
Yes. Numerical forecasting, aggregation and business rules should be callable independently. Conversational access is an interface, not the numerical system of record.
How are overrides handled?
An override should record the original recommendation, revised value, user, timestamp and reason. That preserves accountability and creates a dataset for later analysis.
Start with one recurring decision.
The strongest pilot chooses a single planning question, defines the data cutoff and compares recommendations against the current process.