Forecasting and Time-Series Analysis Questions

Direct answer
CUSUM, Bayesian Online Change Point Detection (BOCPD), and PELT sit on a spectrum from lightweight-and-online to expensive-and-thorough: CUSUM is a simple, fast, purely-online statistic best suited to detecting a known, sustained shift size quickly; BOCPD is also online but gives a full probabilistic estimate of where a break is, at higher compute cost; PELT (and other ruptures-library algorithms) are OFFLINE, penalized-optimization methods best suited to forensic, after-the-fact analysis across a whole series at once.

Structured elaboration and worked example (executed)
Against a synthetic series (seed=42, n=200) with an ABRUPT level shift at index 80 (mean +3) and a separate GRADUAL drift starting at index 140 (linear ramp +0 to +4 through index 199):

import numpy as np
import ruptures as rpt

np.random.seed(42)
n = 200
series = np.random.normal(0, 1.0, n)
series[80:] += 3.0                          # abrupt level shift at index 80 (persists)
ramp = np.linspace(0, 4.0, n - 140)
series[140:] += ramp                        # gradual drift starting at index 140
X = series.reshape(-1, 1)

pelt_breaks = rpt.Pelt(model="rbf", min_size=10).fit(X).predict(pen=8)
binseg_breaks = rpt.Binseg(model="rbf", min_size=10).fit(X).predict(n_bkps=2)

target = series[:80].mean()                 # CUSUM: reference = pre-break mean
k, h = 0.5, 5.0                             # slack, threshold (units of noise std=1)
s_pos = s_neg = 0.0
alarms = []
for i, x in enumerate(series):
    s_pos = max(0.0, s_pos + (x - target) - k)
    s_neg = max(0.0, s_neg - (x - target) - k)
    if s_pos > h or s_neg > h:
        alarms.append(i)

Executed result (ruptures 1.1.9):

PELT (offline) detected breakpoints:   [80, 155, 200]
BinSeg (offline, n_bkps=2) detected breakpoints: [80, 155, 200]
PELT detection error on the abrupt break (true=80): 0
PELT detection error on the gradual drift (true start=140): 15  (flagged at 155)
First CUSUM alarm: index 81 (1-period delay after the true abrupt break at 80)
CUSUM alarms from index 80 through 199: 119 of 120 points -- alarms continuously, not just once

Both offline methods located the ABRUPT break at 80 exactly, but detected the GRADUAL drift (which truly started at 140) only at 155, a 15-period delay - a real, informative miss, not a tuning failure: algorithms built around detecting a sharp mean/variance shift have no equally-strong signal to latch onto for a slow drift, since there's no single point of maximal separation the way there is for an abrupt jump.

The online CUSUM detector (s_pos/s_neg accumulating deviation from a fixed target, alarming when either exceeds a threshold) alarmed starting at index 81 (a 1-period detection delay after the true abrupt break at 80) - and then continued alarming on 119 of the 120 subsequent points, essentially every period for the rest of the series. This is also a real, informative behavior, not a bug: once the process has genuinely and permanently shifted away from the original target mean, a CUSUM comparing against that STALE, fixed target will keep re-triggering indefinitely; a production deployment needs an explicit re-baselining step after a confirmed break (update the target mean) rather than comparing against the original target forever.

• Online vs offline choice: for real-time alerting on a live metric, CUSUM (cheap, fast, purely sequential) or BOCPD (richer probabilistic output, still sequential, but costlier per update) are the appropriate online choices; for a forensic, after-the-fact investigation of a whole historical series (e.g. "when exactly did this trend break happen"), PELT or BinSeg, which optimize over the WHOLE series at once, are more appropriate and typically more accurate since they use future context a genuinely online method cannot.
• Tuning sensitivity: CUSUM's k (reference/slack) and h (threshold) trade off detection delay against false-alarm rate; PELT's penalty parameter trades off the number of detected breakpoints against over-segmentation (too low a penalty finds spurious breaks in pure noise, too high a penalty misses real ones).
• Quantifying detection delay and false-alarm rate: on labeled synthetic data with known true break locations (as done above), detection delay is simply the offset between the true break and the first alarm after it; false-alarm rate is the count of alarms NOT near any true break, both of which should be measured explicitly on a validation set with known ground truth before trusting a specific parameter choice in production.

Trade-offs & pitfalls
The CUSUM re-baselining trap demonstrated above (indefinite re-alarming against a stale target after a confirmed permanent shift) is a common, easy-to-miss production issue - always pair an online changepoint detector with an explicit "confirmed break -> update the reference target" step, or it will functionally become a permanent, uninformative alarm rather than a useful signal.

Direct answer
An LSTM for multi-horizon sales forecasting with exogenous features takes a window of past target values plus time-aligned exogenous features as input, produces multiple future steps as output (via a final linear layer with one output per horizon), uses a loss appropriate to the output type (MSE for point forecasts, pinball/quantile loss for a probabilistic version), and needs a genuine time-based train/validation split, not a random one.

Structured elaboration and worked example (executed)
A minimal working version, trained end-to-end with pinned seeds on synthetic daily sales (weekly seasonality + promo/holiday exogenous effects). The model separately encodes the HISTORY window (target + exogenous features over the same input length, so they can be concatenated feature-wise and fed through one LSTM) and then explicitly folds in the FUTURE exogenous features (known in advance for the forecast horizon, e.g. a planned promotion calendar) by concatenating them to the LSTM's final hidden state before the output head - this is what actually makes the future-known exogenous information reach the model, rather than only describing it in prose:

import torch
import torch.nn as nn

class LSTMForecaster(nn.Module):
    def __init__(self, exog_dim, hidden=32, horizon=7):
        super().__init__()
        self.lstm = nn.LSTM(input_size=1 + exog_dim, hidden_size=hidden, batch_first=True)
        self.head = nn.Linear(hidden + horizon * exog_dim, horizon)
    def forward(self, y_hist, exog_hist, exog_future):
        # y_hist: (batch, input_len) target history
        # exog_hist: (batch, input_len, exog_dim) exogenous features over the SAME history window
        # exog_future: (batch, horizon, exog_dim) exogenous features KNOWN IN ADVANCE for the forecast window
        seq = torch.cat([y_hist.unsqueeze(-1), exog_hist], dim=-1)   # dims 0,1 must (and do) match here
        _, (h, c) = self.lstm(seq)
        exog_future_flat = exog_future.reshape(exog_future.shape[0], -1)
        combined = torch.cat([h[-1], exog_future_flat], dim=-1)
        return self.head(combined)

Trained for 300 epochs (Adam, lr=5e-3, target normalized to zero-mean/unit-variance for stable training) on a 28-day input window / 7-day horizon setup with 2 exogenous features (promo flag, holiday flag), seeds pinned (torch.manual_seed(0), np.random.seed(0)):

y_hist shape (batch, 28); exog_hist shape (batch, 28, 2); exog_future shape (batch, 7, 2); Y shape (batch, 7)
n params: 5065
final train MSE (normalized units): 0.1226
test RMSE by horizon step 1..7 (original units): [3.51, 3.56, 4.02, 3.64, 3.66, 3.34, 3.01]

Test RMSE stays roughly flat across the 7-day horizon (no sharp step-to-step growth), consistent with this multi-output-direct architecture NOT suffering the error-compounding a purely recursive forecaster would - and this time the model actually received the future promo/holiday flags it needs to use that information, which the call path confirms by construction: exog_hist and y_hist are concatenated on the feature dimension only after being verified to share a sequence length, and exog_future reaches the network through the head, not the recurrent step.

• Input shapes: history window (batch, input_len) for the target series, concatenated feature-wise with exogenous features covering that SAME history window (batch, input_len, exog_dim); the forecast-horizon's own exogenous features (batch, horizon, exog_dim) are a SEPARATE input, since they don't share a sequence length with the history and must be introduced after the recurrent encoding rather than concatenated into the same sequence - exogenous features like promo/holiday flags must be KNOWN in advance for the forecast window too, exactly as with SARIMAX's exogenous regressors, and the architecture has to actually route them into the model, not just describe them in prose.
• Loss functions for multi-step outputs: MSE across all horizon steps simultaneously (summed or averaged) for a point-forecast model, as used above; for a probabilistic version, a pinball-loss head per quantile per horizon, mirroring the GBM quantile approach but inside a neural architecture.
• Handling missing values: mask missing target/exogenous entries explicitly in the loss (don't let a missing value silently become zero, which would bias the model toward "the series was zero" rather than "we don't know") or impute upstream with a documented, consistent strategy before windowing.
• Training/validation strategies for time-series data: split by TIME (train on earlier history, validate on the most recent period), never a random shuffle across windows, since overlapping sliding windows from adjacent time periods would otherwise leak across a random train/validation boundary.

Trade-offs & pitfalls
An LSTM needs meaningfully more data and compute to train reliably than ARIMA/ETS/gradient boosting, and its extra flexibility is genuinely useful mainly when either the input signal is rich (many exogenous features, long history) or you're pooling many related series into one shared model - on a single, short, simple series it is very likely to be outperformed by a much cheaper classical method, so justify the LSTM's cost against what the added flexibility is actually buying you, rather than reaching for it by default. A specific implementation trap worth flagging explicitly: it is easy to write a forward() that concatenates a history tensor and an exogenous tensor along the feature dimension without checking that both actually cover the same sequence length - if the exogenous tensor is meant to also carry future, horizon-length information, that information needs its own separate path into the network (e.g. concatenated to the encoder's final hidden state, as done here), not silently absorbed into a sequence-length mismatch that either crashes or - worse in a looser framework that doesn't shape-check - silently truncates and drops exactly the future information the whole architecture was supposed to exploit.

Direct answer
Top-down demand forecasting starts from an aggregate (category, market) estimate and disaggregates down; bottom-up starts from granular, local signal and aggregates up. For a new SKU launch in a new city - where there's no local history at all - top-down (grounded in category/market-level benchmarks and comparable-launch analogues) is the more defensible starting point, with bottom-up signal blended in as it accumulates.

Structured elaboration

• Top-down for a genuinely new SKU/new city: use category-level demand in that city, or the launch trajectory of comparable products in comparable cities, to derive an initial estimate, then allocate it down to the specific SKU using assumed or category-typical market-share proportions. Data sources: category sales in the target city, comparable-SKU launch curves elsewhere, market-sizing estimates (population, comparable-market penetration rates).
• Bottom-up for the same launch: would require building the estimate FROM the new SKU's own local sales signal - which doesn't exist yet at launch, making pure bottom-up untenable in the first weeks. Bottom-up becomes viable, and increasingly reliable, only once actual local sales data starts accumulating.
• Advantages/disadvantages: top-down is available on day one and grounded in more stable aggregate patterns, but its accuracy depends entirely on how well the chosen category/analogue benchmarks actually represent this specific SKU-city combination - a bad comparable set produces a confidently wrong number. Bottom-up is more locally accurate once it has enough of its own data, but is unusable (or dangerously noisy) at day one.
• Combining both over time: the standard approach is a smooth handoff - weight the forecast heavily toward the top-down/analogue estimate in the earliest weeks (exactly the shrinkage/pooling logic used for any short-history series), and progressively shift weight toward the SKU's own emerging bottom-up signal as more of its own history accumulates and that signal becomes more informative than the top-down prior.
• The comparable trade-off in a B2B/pipeline context: an analogous top-down-vs-bottom-up choice shows up in sales forecasting as historical trending (extrapolating past aggregate revenue, a top-down-style approach) versus pipeline-based, deal-stage forecasting (aggregating individual deal probabilities, a bottom-up-style approach) - historical trending is more stable and available even without granular pipeline data, while pipeline-based forecasting is more responsive to what's ACTUALLY currently in motion but depends on deal-stage probabilities being well-calibrated, which they often aren't early in a sales process; the same "blend, and shift weight as better signal accumulates" logic applies there too.

Worked example
For a new-city product launch, a purely top-down estimate might allocate 2% of the city's total category spend to the new SKU based on the launching brand's typical market share elsewhere; three weeks after launch, once actual local sell-through data exists, the forecast would begin blending toward a locally-calibrated estimate, fully deferring to it once enough weeks of local signal have accumulated to make the analogue-based prior no longer the more informative input.

Trade-offs & pitfalls
The most common failure is treating the top-down/analogue-based launch estimate as fixed and forgetting to actively transition toward bottom-up signal as it arrives - a forecast that never updates away from its initial top-down anchor, even after weeks of contradicting local data, is a sign the blending mechanism (not just the initial estimate) needs attention.

Direct answer
Responding to a sudden, dramatic demand shock (like a 70% drop with a changed seasonal pattern) means moving fast through rapid diagnostics, short-term operational fallbacks that don't depend on a not-yet-retrained model, a deliberate retraining strategy once the new regime is better understood, explicit scenario planning for recovery, and continuous, honest uncertainty communication throughout - in roughly that priority order.

Structured elaboration

• Rapid diagnostics to quantify the change: first establish the basic facts fast - how large is the drop, is it uniform across segments/regions or concentrated, and has the WEEKLY seasonal pattern itself genuinely changed shape (not just shifted level) - this initial read determines how radically the forecasting approach needs to change, versus a milder response being sufficient.
• Short-term heuristic fallbacks for operations: a model trained entirely on pre-shock history will actively mislead if used naively during the shock itself (extrapolating a pattern that no longer holds); a simple, transparent heuristic (e.g. "current week's actuals, or a short recent-window average, rather than the stale model's output") is often a more honest and more useful stopgap than a sophisticated model confidently extrapolating an outdated pattern.
• Retraining strategy: once enough post-shock data has accumulated to characterize the NEW pattern (not just the initial shock transient), retrain - but be deliberate about the training window: including too much pre-shock history dilutes the new pattern, too little post-shock history produces an unstable, premature re-estimate; a staged approach (retrain on a growing post-shock window as it becomes available, rather than waiting for a fixed amount before doing anything) balances this.
• Scenario planning for recovery paths: since the actual recovery trajectory (fast rebound, slow recovery, a new permanent lower baseline, a different shape than pre-shock) is genuinely uncertain during the shock itself, present multiple named scenarios rather than a single point forecast - this is exactly the same "acknowledge genuine deep uncertainty explicitly, rather than false point-forecast precision" discipline used for any severely disrupted or unprecedented forecasting situation.
• Adapting dashboards: any dashboard panel built on WoW/YoY percentage-change comparisons, or on alert thresholds calibrated against the pre-shock baseline, will either look absurdly extreme (a 70% YoY drop swamping every other number on the page) or silently mislead (thresholds firing constantly, or not firing at all, against a baseline that's no longer valid). Annotate the shock period explicitly on any historical-trend chart so viewers don't misread the discontinuity as a data error or pipeline bug; temporarily suspend or clearly flag any YoY/WoW comparison metric whose window spans the shock boundary, since the underlying comparison is no longer meaningful; and recalibrate alert thresholds against the NEW short-term-heuristic baseline rather than the stale pre-shock one, revisiting both the annotations and the thresholds again once retraining and scenario tracking are underway.
• Communicating uncertainty and recommended actions: to operations, translate directly into concrete near-term actions under the current best-guess scenario (staffing, inventory); to executives, communicate the RANGE of plausible recovery scenarios and what data signal would indicate which one is actually materializing, framed as "here's what we're watching to tell these scenarios apart" rather than false confidence in one specific path.

Worked example
In the first days of such a shock: report the magnitude and shape of the drop (rapid diagnostics), recommend operations use a short recent-window heuristic rather than the stale model's now-invalid output (short-term fallback), and present 2-3 named recovery scenarios (e.g. "sharp V-shaped rebound within weeks," "gradual multi-month recovery," "a new, lower permanent baseline") with the specific signals (weekly growth rate, whether the pre-shock weekly seasonal shape has resumed) that would distinguish which scenario is actually unfolding as more data arrives, updating the recommendation as that evidence accumulates rather than committing to one scenario prematurely.

Trade-offs & pitfalls
The most damaging mistake in a disruption like this is continuing to trust (or silently keep serving) a model's output as if nothing had changed, simply because retraining hasn't happened yet - an explicit, fast decision to fall back to a transparent heuristic during the gap between "the old model is now known to be wrong" and "a properly retrained model is ready" is what protects operational decisions during exactly the period they're most vulnerable.

Direct answer
Responsible AI and governance for forecasting systems means checking whether the model treats different regions or product lines fairly (not just accurately on average), protecting the privacy of training data, and running the operational governance machinery - model cards, periodic audits, defined remediation processes - that make the whole system auditable and correctable rather than a black box that only gets scrutinized after something visibly goes wrong.

Structured elaboration

• Detecting bias across regions or product lines: check forecast accuracy and, separately, forecast BIAS (systematic over- or under-prediction) broken out BY segment (region, product line), not just in aggregate - a model that's unbiased on average can still systematically under-forecast one region while over-forecasting another, which is invisible to an aggregate accuracy check but very real in its downstream consequences.
• Mitigating detected bias: once a segment-specific bias is confirmed (not just suspected from a single period, but validated the way any bias-detection exercise should be, with a proper statistical check), remediation options range from a segment-specific recalibration correction to retraining with segment-balanced data or segment-aware features, chosen based on WHY the bias exists (a data-representation issue vs a genuine, harder-to-model difference in that segment's underlying dynamics).
• Fairness when forecasts drive allocation decisions: when a forecast feeds directly into an ALLOCATION decision (inventory, staffing, incentive dollars distributed across regions), a systematic forecasting bias against one region translates directly into that region being under-served - this is the concrete mechanism by which a "purely technical" forecasting bias becomes a real fairness issue, and it's the reason bias detection here needs to be checked specifically against WHATEVER downstream decision the forecast drives, not evaluated as an abstract accuracy statistic alone.
• Data retention and privacy: forecasting models trained on customer-level or location-level transaction data inherit the same retention-limits and privacy-handling obligations as any other system using that data - define and enforce a retention policy for training data, and ensure the model itself (and any cached intermediate features) doesn't become an unintended long-term store of data that should have been deleted under the organization's stated retention policy.
• Operational governance practices: model cards (a standardized, versioned document describing a model's intended use, known limitations, training-data characteristics, and validated performance across segments) make a model's fairness/bias characteristics legible to anyone who needs to evaluate or approve its use, rather than requiring a fresh investigation each time; periodic audits (a scheduled, recurring re-check of segment-level bias and accuracy, not just a one-time pre-launch check) catch drift into unfairness that emerges only after deployment; a defined remediation process (what happens, and who's accountable, once an audit finds a problem) ensures a detected issue actually gets fixed rather than merely documented.

Worked example
An automated demand-allocation system that systematically under-forecasts demand in lower-income neighborhoods (perhaps because those areas have historically been served by fewer marketing dollars, and the model has learned that pattern as if it were an accurate reflection of true underlying demand rather than a historical resourcing artifact) would, if left unchecked, perpetuate and even reinforce that under-service through the forecast-driven allocation decision itself - detecting this requires deliberately checking bias BY neighborhood income level (not something an aggregate accuracy metric would surface on its own), and the mitigation needs to address the root cause (the historical resourcing pattern baked into the training data) rather than just a numeric recalibration that treats the symptom.

Trade-offs & pitfalls
The most consequential governance gap is treating fairness/bias review as a one-time, pre-launch checklist item rather than an ongoing, periodically-repeated audit - a model that was checked and cleared at launch can still drift into segment-specific bias over time as the underlying data and business context evolve, and only a recurring audit cadence (not a single point-in-time check) catches that drift before it compounds into a real, sustained allocation harm.