Experimental protocol
Three protocols are defined in a frozen, version-controlled config (configs/chronological_protocol.yaml). The split policy is never silently changed — any revision creates a new named protocol version.
Protocols
FIXED_ORIGIN (primary)
Fit all preprocessing and models on Batch 1 only. Evaluate, without retraining, on Batches 2–10 in chronological order. This is the primary evaluation protocol — it reflects a deployed model that is never quietly updated as drift accumulates.
EXPANDING_WINDOW (adaptation)
Before evaluating batch k, retrain using all batches strictly before k. Measures how much periodic retraining recovers the accuracy lost to drift, still respecting chronology (never trains on future data).
IID_DIAGNOSTIC (diagnostic only)
A stratified random 80/20 split across all batches pooled together, ignoring chronology. Reported only to quantify how much a random split overstates future-batch performance — never used as a primary result.
Models in scope
Four lightweight, interpretable candidates were selected — not dozens of models chosen to inflate a benchmark table. Configuration: configs/classical_baselines.yaml.
| ID | Model | Rationale |
|---|---|---|
| MODEL-C1 | Logistic Regression | Linear, fully interpretable coefficients |
| MODEL-C2 | Random Forest | Non-linear baseline with native feature importance |
| MODEL-C3 | RBF-SVM | Non-linear margin-based baseline |
| MODEL-C4 | MLP Classifier | Small neural classifier, TinyML-plausible size |
FIXED_ORIGIN trains once on Batch 1 and evaluates Batches 2-10 without retraining; EXPANDING_WINDOW retrains using all batches strictly before the test batch; IID_DIAGNOSTIC is an explicitly diagnostic (not primary) stratified random 80/20 split.
Data flow
See the full stage-by-stage breakdown on the Pipeline page.