Planning Primitives

New

• New quantiles field returns a full range of outcomes for every forecast period, not just one confidence band. Pass any of [0.1, 0.2, … 0.9] and each period comes back with a quantiles object alongside the usual lower/upper bounds. Use it to draw fan charts, or to order to a chosen service level instead of to the average. One request, one charge — previously the only way to approximate this was to call the same series repeatedly at different confidence levels, which cost more and produced near-identical lines above 0.80.
• New adjustments field applies your own assumptions on top of a forecast — "assume we lose the enterprise deal", "assume the promotion lifts Q4 by 20%". Supports multiplier and level_shift, each optionally scoped to a range of periods, applied in the order you list them. The scenario comes back as a separate adjusted block and is never stored, so exploring what-ifs can't affect the accuracy tracking on your real forecasts.
• New accumulate field sums a forecast into a single total, with optional decay for attrition and an annual discount_rate. The same request answers cumulative demand over a lead time for safety stock, customer lifetime value for a cohort, total cost of ownership, or net present value. Returns a running cumulative per period with its own confidence range, plus the assumptions used to produce it.
• New value_bounds field keeps forecasts inside the limits your data actually has: {"min": 0, "max": 100}, with either side optional. Neither the forecast nor its confidence range can land on an impossible value — no more a 140% utilisation projection or a churn rate band reaching below zero. Rates, percentages, utilisation and occupancy are forecast on a transformed scale rather than being trimmed back afterwards, so the confidence range still covers at the level it claims, and on our benchmark series it came out 14–16% better on the models that had been spending width on outcomes that could never happen.
• All four of the above work on POST /v2/batch/forecast as well, so you no longer have to choose between batching and getting a forecast that respects its own limits. Each one can be set once for the whole request and overridden on any individual series — which matters most for value_bounds, since one batch can legitimately mix a 0–100 percentage, a 0–1 rate and an unbounded revenue series. Bounds are checked against each series' own history and adjustment periods against each series' own horizon, so a scenario that runs past the end of a shorter series is rejected rather than quietly ignored. In a batch the adjusted and accumulated blocks appear inside each series' own result, not beside it.

Improved

• The confidence range on an accumulated total is now based on a correlation assumption measured against our benchmark data, rather than assuming each period's error is independent. Independence is the textbook approach and it is substantially too optimistic on real forecasts — a level error tends to persist across a horizon rather than cancelling out. The assumption in force is returned with the result, and one you supply yourself is always reported as yours.
• Asking for more detail no longer changes the forecast itself on advanced-quantized. Requesting quantiles, or lowering confidence_level below 0.80, previously fed into how the underlying model was chosen, and could move the headline number by around 10% — on one benchmark series the same request returned 1862.57 without a fan and 2057.01 with one. The model is now always fitted the same way, so what you ask to have returned can no longer change the number you get back. One-off consequence: advanced-quantized and ensemble forecasts may shift slightly against previous runs. We measured this across our benchmark suite: forecast accuracy itself is unchanged, while confidence ranges came out around 2% wider on average. We took that as a fair price for a number that no longer moves depending on what you ask for.
• New Patterns & Segmentation documentation covering how to forecast per segment or cohort with tenant_context, break a total into its components, forecast rates and percentages, and build fan charts — including where each approach has limits.
• Documented tenant_context as a general-purpose second key, not just a multi-tenancy field. It has always worked for any dimension you want to forecast along — plan, region, store, channel, cohort — but nothing said so.
• The batch endpoints now also accept confidence_level, the name the single-forecast endpoint uses, alongside the confidence they have always used — the two endpoints had different names for the same field. The lowest accepted value on batch also drops from 0.5 to 0.10, matching single forecasts. Existing requests are unaffected.

Fixed

• Corrected the date format used throughout our documentation examples. Several showed dates as "2024-01", which the API rejects — copying one of those examples produced a validation error rather than a forecast. All examples now use the YYYY-MM-DD format the API accepts.
• Removed the include_history field from the batch endpoints. It was accepted but never had any effect on the response.
• Fixed batch processing performing far more database work than necessary on larger batches, which could surface as slow processing or intermittent errors on batches with many series.
• Uploaded batch files now validate periods per series the same way an inline batch request does — it had to be between 1 and 365 there, but anything at all was accepted in an uploaded file, where an out-of-range value could stall the rest of the batch it was in.