Everything else in this chapter describes what has already happened. The Analytics Lab — Business Intelligence → Analytics Lab — is where you find out what is likely to happen next: how much of a product you will sell, week by week, so purchasing and production can plan instead of guess. It is available to anyone whose role carries the use analytics-lab permission (managers and company admins have it by default).
An experiment is a question posed to your own history. You choose what to forecast — sales quantities, say — how to slice it (by product, by branch), which forecasting method to try, and which patterns it may learn from (last week's value, a rolling average, the time of year). The Lab then does the honest part: before it forecasts anything, it rehearses on your past — pretending, several times over, that it only knew the data up to some earlier week, forecasting the weeks after, and scoring itself against what actually happened. That rehearsal is the backtest, and its score (a percentage error — lower is better) is recorded on the run, permanently.
Starting an experiment: pick the question first. The New experiment page opens on a gallery of questions — Forecast demand for a product, Find products that sell together, Spot customers likely to pay late, Group customers by how they buy, Group donors by how they give, and the rest of what the Lab can answer. Each card names the decision its answer feeds — reordering, promotions, credit follow-up — and shows an example answer, so you choose by the decision you face, not by technique. Picking a card opens its setup in business language: what to forecast and how to slice it, how far ahead, the method in plain words (Seasonal pattern, Steady trend, Sporadic demand) with a line under each saying when it helps, and the patterns it may learn from as plain switches. Beside the setup sits your own series — the actual numbers the experiment will learn from, read from the same governed analytics as your dashboards. If there is no honest series to show (no data yet, or the service is unreachable), the preview says exactly that instead of drawing a plausible-looking line. Questions that are defined by a recorded recipe rather than simple fields — spotting late payers is one — arrive with a starting recipe already filled in, ready to adjust. And whichever way you set an experiment up, the experiment recorded is the same one the technical form would record for the same choices: there is one configuration, presented two ways. As on the run's page, the platform's super-admin keeps the full technical form open, while everyone else finds it inside a Technical details section below the business setup.
The Lab learns from most of the business's record sets: sales, stock movements, goods receipts, purchase invoices, collections, receivables ageing and donations — and also the purchase-order book (what was ordered against what arrived), work orders, timesheets, the daily headcount snapshots, marketplace orders and the general ledger itself. Two gallery questions arrive with that wider reach: Group employees by how they work (hours, billable hours and billable value per employee) and Group marketplace sellers by how they sell. A few record sets stay out of the Lab — the CRM pipeline snapshots and the budget tables carry no date history a series can be built on, and the Lab would rather name that than build on sand.
Crucially, every rehearsal also scores the simplest possible method — "next week will look like the same week last season" — on exactly the same weeks. A clever method that cannot beat that naive guess has earned nothing, and the Lab will tell you so: the run's page shows both scores side by side, with the full detail of what was tried, what data window was used, and any series that had to be skipped, with the reason named. Runs that fail say why. Nothing is hidden and nothing is rounded into a better story.
The run's page opens in plain English, and every run's page opens the same way — one frame, in the same order, so you always know where to look. First comes the verdict band. For a finished run it is the verdict itself: whether the rehearsal earned your trust — the method's score and the simple guess's score side by side as bars, under one sentence that says which won and by how much — Worth planning on when the method beat the guess, and an equally plain sentence when it matched it or lost. Any series that had to be skipped is counted and named on the band itself, not buried in the detail below. A run that failed opens with its band too, naming the failure in the engine's own words. A run that is still going — waiting, or running — shows a band saying exactly that, and that there is no result to judge yet. And every band carries one small line naming what was run and when it stood there, so a page someone left open, or a colleague's screenshot, never floats free of its run. Under the band sits the recipe, restating the whole experiment in one paragraph: the question it answers, which of your numbers it used and how they were sliced, the method in plain words — Seasonal pattern, not the algorithm's name — the patterns it was allowed to learn from, how far ahead it looks, the stretch of your past it rehearsed on, and when it ran. The full record still sits underneath, exactly as recorded — the run's standing, its data window, its scores and its whole technical record. One difference by role: the platform's super-admin keeps that record open on the page in its native form, while everyone else finds it inside a Technical details section — there when support or an analyst needs it, out of the way when they do not. And the Promote to duty action now lives on the run's page as well as the experiment's; before you confirm, it states its consequence in words — the recipe starts running on the schedule you choose and publishes into the governed numbers, and it never posts, approves or changes any document.
Then, the answer itself. Under the verdict and the recipe sits What it predicts — the run's actual output, in the open. For a forecast, each series gets a chart of the predicted values with the run's own recorded ranges shaded around them (the narrower band is the 80% range, the wider the 95%), and a table underneath giving every period's predicted value and both ranges, in the measure the run used — quantities as quantities, money in your currency, never a bare number pretending to be either. The other questions show their answers the same way: the buying patterns found, each with how often it appeared and how strongly; the customer groups, largest first, with the average shape of each; the recommended plan from a best-plan run, with its objective and a check that every declared limit holds; a stress test's service level and the order-up level that would have met its target; and, for a prediction about records, what it predicted for the first fifty beside what actually happened — the full list stands in the technical record. If a series recorded no predictions, or a run recorded no output at all, the card says exactly that instead of drawing an empty chart. When a forecast covers thousands of series at once — a whole catalogue — the card draws the first twenty-five in full and names how many more there are, so the page opens at once; every series, with every point, stands in the technical record below, and the record likewise shows the first hundred series' scores and names the rest. Nothing is dropped — only paged out of the drawing. Nothing on the card is recomputed for display: it is the output the run recorded, word for word and number for number.
Comparing runs is how you choose. Re-run an experiment with a different method or different patterns, then open Compare runs: the two runs' recorded scores stand side by side, exactly as recorded — the Lab never quietly recomputes a score to make the comparison tidier.
Run statuses keep themselves current. Opening the Lab's list or an experiment's page quietly checks every run still in flight and updates its status — and while any run is still in flight, those pages keep checking every few seconds on their own, so a run never sits showing running after it has in fact finished: leave an experiment open and its runs table lands the finished run in front of you by itself. A run's own page does the same: open a run that is still in flight and the page checks every few seconds on its own, so the moment the run finishes its result appears on the page in front of you — no refreshing, no navigating away and back. When nothing is in flight, the pages stop checking and sit quiet. The manual Refresh runs action on an experiment's page, and Refresh from sidecar on the run's page, do the same on demand.
Promoting a winner to a duty. When a configuration has genuinely earned it — its recorded backtest beat the naive baseline — a company admin (this step is deliberately admin-only) can promote it to a duty: the forecast becomes a standing job that re-runs itself in the nightly chain, after the warehouse refresh, and publishes its fresh forecast into the same governed numbers everything else reads — so the forecast shows up in dashboards and Explore (as the Analytics forecast) stamped with the configuration that produced it and the accuracy it earned in its backtest. A configuration that never beat the baseline cannot be promoted: the promote action refuses and names both scores. Forecasts from experiments that were never promoted are never published — the Lab is a laboratory, not a back door into your reports.
When a duty drifts. The world changes, and a forecast that was accurate in June may be poor by October. After every nightly run the Lab compares the duty's recent accuracy with the backtest it was promoted on. If accuracy has worsened materially — by more than a quarter — the duty's publication pauses (the last good forecast stays published), a finding appears on the analytics cockpit, and the duty's page explains what happened. Nothing resumes on its own: an admin either re-promotes the duty from a newer, winning run, or dismisses the pause having seen the numbers.
Beyond forecasting: patterns and predictions. The Lab is not only for forecasts. The Job type on the new-experiment form now also offers:
- Regression — predict a number for each record: the amount a settlement will reach, say, or the days a customer will take to pay.
- Classification — predict a label for each record: will
pay late, likely to dispute. One method (
text_linear) reads the words instead of the numbers — free-text notes and document text — for questions that are about language, not amounts. - Clustering — group records into segments that behave alike: customers who buy alike, products that move alike.
- Association — find buying patterns: customers who buy X often also buy Y, measured with support (how often the pair happens), confidence (how often Y follows X) and lift (how much likelier Y is once X is in the basket).
These four are written as a definition — a block of JSON that names the data to read, the patterns it may use and the method to try. That sounds technical, and it is deliberately so: the definition is the experiment, exactly as recorded, so anyone can see later precisely what was asked. Your implementer can draft definitions for you; the Lab checks every one before it runs and refuses — naming the reason — anything the data cannot support. A pattern experiment needs enough history to be honest: association needs at least 200 invoices with two or more lines, and the prediction types need a few dozen records with enough examples of each outcome. Below that, the Lab says so instead of dressing noise up as insight.
The rehearsal discipline is the same as for forecasts, with the baseline to match: a regression must beat predicting the average every time, a classification must beat always guessing the most common label, on the same held-back records. A clustering earns promotion by finding at least two real segments; an association, by finding at least one rule. Promotion works exactly as for forecasts — company admins only, from the run's page — and a promoted duty of any type re-runs in the nightly chain.
What the patterns do once promoted. Three surfaces consume promoted duties — only promoted ones; experiments alone change nothing outside the Lab.
- Cross-sell prompts. Open a sales order or invoice that contains a product from a promoted buying-pattern rule and an Often bought together section suggests what customers usually add, with the rule's lift and confidence beside it. It is a prompt, never an edit: nothing is added to your document unless you add it. The section appears only for roles carrying the view cross-sell-prompts permission, and only while the document's lines can still be edited — while you are creating the order or invoice, or editing one that is still a draft. It is not shown on a document's read-only view page, nor once the document has been approved or posted.
- Assortment and segment findings. The strongest promoted rules and the largest promoted segments appear as findings on the relevant cockpit, with their recorded figures — so a pattern the Lab proved shows up where the module's team already works.
- Late-payment risk. Promote a classification duty trained on your receipts and aged receivables, and its riskiest predictions appear as findings on the Finance cockpit, naming the customer and the model's recorded accuracy. One useful definition for it (your implementer can paste this into the Definition box of a Classification experiment):
{
"dataset": {
"facts": ["fact_ar_settlements", "fact_ar_aging"],
"measures": ["settled_amount", "outstanding_amount"],
"join": {"fact": "fact_ar_aging", "on": "invoice_id",
"columns": ["due_date_key", "invoice_date_key", "outstanding_amount"]},
"derived": [{"name": "terms_days", "kind": "days_between_keys",
"from_key": "invoice_date_key", "to_key": "due_date_key"}]
},
"grouping": [],
"target": {"derive": {"kind": "date_minus_key", "date_column": "date",
"key_column": "due_date_key", "op": "gt", "value": 0}},
"model": {"family": "logistic", "params": {}},
"backtest": {"origins": 3}
}
It reads each settlement, joins the invoice's due date, and learns from the settled amount, the amount still outstanding and the payment terms whether the payment arrived late.
Beyond prediction: prescription. Two further job types do not predict at all — they decide, under rules you declare:
- Optimization — solve a problem you state as data: the quantities to decide (the variables — for example, how much of each product to allocate to each branch), the goal (the objective — maximise the total allocated, say), and the limits (the constraints — never allocate more than the forecast expects, never more than the stock available). Every number in the problem is either written literally or read from your governed figures — a forecast column, a stock column — never invented. The run returns the solution (the value chosen for every variable), the objective value it achieved, and a report on every constraint: satisfied or violated, and by how much slack. A problem that cannot be solved — the limits contradict each other, or the goal runs away without limit — is refused by name; the Lab never dresses a guess up as a solution.
- Simulation — ask what would happen if: the Lab plays a stocking policy forward hundreds of times over the spread of your published forecasts (each run of the dice seeded, so the same question over the same data gives exactly the same answer — you can check it) and reports the outcomes as percentiles: the service level you would actually hold, the chance of a stockout, the units you would fall short by, and the cash those shortages represent where a unit cost is declared. It also computes, for each product, the order-up-to level that would meet your service target over the lead time. You may declare the policy you run today as a baseline policy in the same definition; it is simulated on the identical draws, so the comparison is a fair fight.
Both are written as definitions, like the pattern types. The promotion law matches their shape: an optimization promotes only when its recorded run solved feasibly — and, where the problem declares the objective value of the policy you run today, only when the solution beat it. A simulation promotes when its recorded service level holds against its declared baseline policy. Two useful starting points (your implementer can paste these into the Definition box):
An allocation over your published forecasts, capped per series by the horizon's expected demand and per product by the largest on-hand figure in the inventory snapshots:
{
"dataset": {"facts": ["fact_analytics_forecast", "fact_inventory_snapshots"]},
"model": {"family": "lp_milp", "params": {}},
"problem": {
"sense": "maximize",
"variables": [{"name": "allocate", "type": "continuous", "lower": 0,
"index": ["product_id", "branch_id"],
"upper": {"column": "point_forecast", "aggregate": "sum"}}],
"objective": {"terms": [{"variable": "allocate", "coefficient": 1}]},
"constraints": [{"name": "supply", "over": ["product_id"],
"terms": [{"variable": "allocate", "coefficient": 1}],
"sense": "<=",
"rhs": {"column": "qty_on_hand",
"fact": "fact_inventory_snapshots",
"aggregate": "max"}}]
}
}
A service-level simulation over the same forecasts, judged against the policy of ordering up to 150:
{
"dataset": {"facts": ["fact_analytics_forecast"]},
"grouping": ["product", "branch"],
"model": {"family": "monte_carlo", "params": {}},
"simulation": {"seed": 7, "trials": 500, "lead_time_steps": 2,
"scenario": {"on_hand": 100, "order_up_to": 260,
"service_target": 0.95,
"baseline_policy": {"order_up_to": 150}}}
}
What prescriptive duties do once promoted. A promoted optimization duty's solution and a promoted simulation duty's below-target series arrive as findings — recommendations — on the owning manager's cockpit (the Inventory cockpit for duties the Inventory Manager owns; the analytics cockpit otherwise): the allocation with its objective and constraint evidence, or the product whose simulated service level trails its target, with the order-up-to level the recorded run computed for that target. They are recommendations in the full sense of this book: nothing is ordered, moved or posted by them. A person reads, decides, and acts through the ordinary screens.
The methods, the scores and the settings — a reference. Everything above describes how the Lab works; this part is for reading a run once it has finished, and for knowing what you are choosing when you pick a method.
The forecasting methods. Every forecast run also scores the baseline, so each method below is always judged against it.
- Seasonal naive — the baseline itself. It predicts that each coming period will match the same period last season (the same week last year, the same month last year). It has no settings, and it is embarrassingly strong on seasonal data — which is exactly why it is the bar.
- ETS (exponential smoothing) — follows the recent level, trend and seasonal shape of a series, weighting recent periods more heavily than old ones. Steady, quick, and often the right first try on a smooth series. Its settings say how the trend and the seasonality combine (add — the seasonal swing is a fixed amount; mul — it grows with the level) and whether the trend is damped (fades out rather than running away).
- ARIMA — a statistical method that learns a series' momentum and its habit of drifting back towards its average. Its order (three numbers) says how many past periods it leans on, how many differences it takes to steady the series, and how much it smooths its own past errors.
- Prophet — built for business calendars: a trend plus yearly and weekly seasonal patterns, tolerant of gaps in the data. Its settings control how eagerly it bends the trend to follow recent changes and how strongly it trusts the seasonal pattern.
- LightGBM — a machine-learning method (a forest of small decision trees) that learns from features built out of the series itself: last period's value, rolling averages, the time of year, and so on. It can find interactions the formula methods cannot ("this product spikes when that one does"), at the price of more settings and a greater appetite for history. Estimators is how many trees it grows (more can fit better, and can also memorise noise); learning rate is how cautiously each tree corrects the last (lower is slower and usually surer, paired with more trees); leaves caps how complicated each tree may become.
- Croston — the specialist for intermittent demand: products that sell in sporadic bursts with quiet periods between (spare parts are the classic case). Instead of forecasting the series directly it forecasts the size of a burst and the gap between bursts separately, then combines them. Alpha is how quickly it adapts to recent bursts; the method choices (croston, sba, tsb) are bias-corrected variants — sba is the usual default. Judging Croston by a range of ordinary, non-intermittent products is unfair to it: run it on the sporadic series it exists for.
The rehearsal settings. The backtest block decides how stern the rehearsal is. Origins is how many times the rehearsal is repeated from different points in the past (4 by default — more origins is a sterner, slower test). Holdout is how many periods each rehearsal forecasts (8 by default). Minimum training periods (26 by default) is the least history a series must have before it may be scored at all — a series observed in fewer periods is skipped and named, never given a pretend score. The horizon is how many periods the real forecast reaches into the future once the rehearsal is done. Published forecasts carry prediction intervals (80% and 95%): the range the actual figure should fall inside that share of the time, if the method is honest — a wide interval is the method saying I am not sure, which is information, not failure.
Forecast scores. All three are computed over the rehearsal, pooled across every origin and every series, for the candidate and the baseline alike. Lower is better for all three.
- sMAPE — the headline score: the average percentage error, in a symmetric form that treats overshooting and undershooting even-handedly. It runs from 0 (perfect) to 200. As a rough feel: under 10 is very good for demand data, 10–30 is a normal working range, and past 50 the method is barely better than guessing. But the reading that matters is relative: the candidate's sMAPE against the baseline's on the same rehearsal. Beating the baseline by a little on strongly seasonal data can be a genuine achievement; beating it hugely on a smooth series may say more about the series.
- MAPE — the plain average percentage error. Easier to say out loud, but it cannot handle periods where the actual figure is zero (a percentage of nothing is meaningless), which is why sMAPE leads and MAPE supports.
- RMSE — the typical size of the error in the units of the thing itself — units of product, pounds of revenue. Big misses count extra. Use it to feel how wrong the forecast is in real terms; do not use it to compare one product against another (a big seller's RMSE dwarfs a small one's for the same quality of forecast) — that comparison is what sMAPE is for.
Prediction scores. A regression run (predicting a number) reports RMSE and MAE (the average absolute error, in the same units — MAE is the typical miss, RMSE punishes the big ones) and R²: the share of the variation the model explains. R² of 1 is perfect; 0 means the model is no better than predicting the average every time — and beating that average-predictor is precisely its baseline test.
A classification run (predicting a yes/no label, such as will pay late) reports: AUC — the chance the model ranks a random true case above a random false one. 0.5 is a coin toss, 1.0 is perfect; 0.6–0.7 is modestly useful, which is a realistic expectation for human behaviour like payment habits. Precision — of the records it flagged, how many truly were the label. Recall — of the records that truly were the label, how many it caught. F1 — the balance of the two in one number. Behind them sit the four counts themselves (right flags, wrong flags, right clears, misses), so you can see the shape of its mistakes, not just their size.
Pattern scores. Association rules carry the three measures already introduced — support (how often the pair occurs at all), confidence (how often the second item follows the first) and lift (how much the first item multiplies the odds of the second, over its ordinary rate — the measure that separates a real association from two merely popular items). The method's minimum settings are simply "do not show me rules weaker than this". Clustering reports a silhouette score for the segments it found: near 1 means the segments are tight and well separated, near 0 means they blur into one another — a high score on a segmentation that found only a tiny outlier group and everyone else is the method telling you the population may not divide the way you hoped. The number of clusters setting is how many segments you ask it to look for; asking for more, or describing each record with different measures, can reveal a middle group (a wholesale cohort, say) that a three-way split folded into the mainstream.
What it costs. Each completed experiment run and each duty run counts once against your plan's monthly AI allowance — the same pool described under the Action Assistant. Failed runs are never charged. If the allowance is exhausted, the Lab refuses the submission up front and names the plan and the limit, rather than starting work it cannot finish.