Seasonal anomaly baseline
01

Calendar: weekday and holiday

02

Business: campaign and payday

03

Lifecycle: launch and retirement

04

Trend: rising or falling baseline

05

Range: expectation and confidence

An anomaly is a deviation from a comparable baseline

Weekend footfall, pre-holiday demand, and month-end collection can be regular. Fixed thresholds create noisy alerts.

Use historical samples under similar conditions and define fallback when samples are sparse.

Calendar is only the first layer

Separate weekday, public holiday, shifted workday, month, and fiscal period, then add confirmed promotions or paydays.

When external drivers are unavailable, mark the cause unresolved rather than inventing one.

Treat trend and lifecycle explicitly

A growing launch and a retiring item should not share a static historical average. Rolling, segmented, or lifecycle cohort baselines reduce false alerts.

Version the baseline and avoid updating it at the speed of noise.

Combine rules and statistics

Use rules for known red lines, grouped intervals for stable seasonality, and assess multivariate models only with explainable inputs and failure modes.

Show actual, expected, deviation, and completeness together.

Backtest on operating history

Replay holidays, campaigns, launches, missing feeds, and real incidents, then review hit, false alert, miss, and workload with owners.

BI0 can be assessed for anomaly analysis; calendars, events, models, and alert orchestration need confirmation.

Decompose level, trend, season, event, and residual

An anomaly is a residual that comparable recurring structure does not explain, not merely a large movement. Additive behavior fits stable amplitude; multiplicative or log behavior may fit scale-dependent variation. Validate the choice with history.

Plot trends and seasonal subseries before modeling. With fewer than two credible cycles, fall back to rules or peer groups instead of claiming learned seasonality.

Build comparable-condition sample pools

Match weekday, holiday or shifted workday, opening hours, promotion intensity, and lifecycle. Store calendar version and data completeness. Define which attributes are hard matches and which are model inputs.

When data is sparse, back off through declared peer levels and lower confidence. Missing weather or event data must remain an unresolved explanation, not an invented cause.

Combine statistical deviation with business impact

Use robust median and MAD, quantiles, decomposition residuals, or forecast intervals as appropriate. Always show actual, baseline, bounds, deviation, and sample size; ordinary z-scores are fragile on skewed or zero-heavy series.

Prioritize using value, margin, customer impact, and persistence. Deterministic red lines such as negative stock belong in rules rather than a probabilistic detector.

Prevent the baseline from learning an incident

Frequent retraining can normalize a persistent loss. Version baselines, control update cadence, and exclude or downweight confirmed incidents. Treat launches, retirement, and store renovation as lifecycle states.

Check pipeline completeness before business deviation. A missing feed should create a data alert, not a sales-collapse narrative.

Backtest operational workload and verify scope

Replay history using only information available on each date, covering peak, holiday, campaign, launch, missing feed, and real incidents. Review hits, misses, false alerts, lead time, and weekly alert volume with operators.

BI0 may be assessed for anomaly operations, but calendars, event labels, model, routing, and feedback need verification. It should present candidate evidence rather than promise an automatic causal explanation.

Public references

Take the next step with BI0.AI

Talk through a real business scenario and see how governed AI BI can fit your team.

Explore BI0.AI