@@ -87,42 +87,6 @@ Median aggregation and `return_by_separate_ensembles=True` retain the full matri
 
 For estimators with read-only prediction, `fit(..., persist_prediction_state=False)` lets lazy models be loaded and released without rewriting their files. The default is True, preserving custom estimators whose prediction-time mutations must persist. This choice is independent of streaming aggregation. The standalone `LazyLoadingEstimator` offers the corresponding `dump_on_read` option and also defaults to True. Performance comparisons explicitly disable repeated writes for the tested forests/XGBoost models.
 
-### Bound predictor batches within temporal queries
-
-Streaming ensemble aggregation bounds the parent's reduction arrays. It does not
-bound a worker's temporal-window covariates: a wide prediction window is otherwise
-materialized once in each concurrent worker. For pointwise estimators such as
-XGBoost, Random Forests and their local beta wrappers, opt into bounded batches:
-
-```python
-pred = model.predict_proba(prediction_path, n_jobs=30,
-    temporal_window_prequery=True, streaming=True,
-    prediction_batch_size=100_000)
-```
-
-Each worker still issues one query per temporal window. DuckDB yields Arrow
-record batches and only the current batch becomes a Pandas covariate table;
-stixel geometry, probabilities, overlapping-window means and coverage rules are
-retained. Pandas and Parquet inputs are also supported. No prediction copy of the
-full covariate dataset is saved to scratch. The option is independent of the
-training backend, lazy loading and total number of ensembles.
-
-The row limit is per worker, not a total RAM cap. DuckDB caches, fitted models,
-ensemble results, indexes and parent output arrays still consume memory. Smaller
-batches reduce input memory but can increase model loads and prediction calls;
-compare 25,000, 50,000 and 100,000 on the target workload. Keep `None` (the default)
-for custom batch-dependent or prediction-stateful estimators, because splitting
-their prediction calls can change their behavior. Custom ensemble prediction
-overrides, including SphereAdaSTEM, reject this option explicitly rather than
-silently ignoring it. Median and separate-ensemble returns still require their
-full result matrix even when input batches are bounded.
-
-An isolated, repeatable comparison is available with
-`python scripts/00_benchmarks/compare_prediction_batches.py --calibrated`.
-It checks predictions, standard deviations and missing-value masks against the
-whole-window route, reports sampled prediction memory and time, and removes its
-temporary databases, model files and prediction arrays afterward.
-
 ### Monitor a running workflow
 
 Install the optional monitoring dependency in the environment that runs the model:
 
@@ -4,72 +4,6 @@ This second pass on `codex-rewrite` adds streaming ensemble means and standard d
 
 The measured gains depend on the workload. In three repeated lazy-forest runs, prediction was about 31% faster and complete-job time about 10% lower than the first rewrite. Small XGBoost jobs changed little. Streaming greatly reduces the aggregation buffer, but does not bound estimator workspace or guarantee a comparable reduction in complete-job peak memory.
 
-## Bounded prediction inputs, October 10, 2026
-
-The HPC occurrence log showed successful training and held-out prediction, followed
-by SIGKILL during annual prediction before any ensemble finished. That is consistent
-with a memory-limit kill, although Slurm accounting is needed to confirm its cause.
-The log's repeated 192,909.8 MiB peak belongs to the entire workflow; it is not a
-prediction-stage peak. Summed process RSS also counts shared pages repeatedly.
-
-The previous streaming reducer already avoided an N-by-ensemble matrix in the
-parent. Each worker still materialized a full, wide temporal window as Pandas data.
-The new opt-in `prediction_batch_size` bounds that conversion while retaining
-`temporal_window_prequery=True`: one query per window yields successive Arrow
-batches, each passed through the same rotation, half-open stixels and base models.
-Workers remain parallel. Missing models are skipped before constructing their
-stixel covariate copies. No full prediction-input copy is written to scratch.
-DuckDB documents the [Arrow batch reader](https://duckdb.org/docs/lts/guides/python/export_arrow);
-the separate parent-side reducer follows the same incremental-output principle
-described in [joblib's generator example](https://joblib.readthedocs.io/en/stable/auto_examples/parallel_generator.html).
-
-A synthetic wide-input comparison used 1,000,000 prediction rows, 116 random
-covariates plus longitude, latitude and DOY, four ensembles, two loky workers,
-lazy models and local ridge-100 beta calibration around XGBoost. Models had
-10 trees per calibration fold and were fitted once on 10,000 rows; identical
-model files were reused for every prediction variant. This measures execution
-equivalence and prediction costs, not whether the calibration is scientifically
-optimal. Each variant ran three times in fresh processes, alternating order.
-
-| Temporal-query batch | Median prediction time | Median peak process-tree physical footprint | Median peak summed RSS |
-| --- | ---: | ---: | ---: |
-| Full window | 7.73 s | 3.29 GiB | 5.76 GiB |
-| 100,000 rows | 9.03 s | 1.85 GiB | 4.51 GiB |
-| 50,000 rows | 10.35 s | 1.69 GiB | 3.99 GiB |
-
-The 100,000-row choice reduced the median sampled footprint by **43.8%** at a
-**16.8%** time cost. The 50,000-row choice saved 48.8% but took 33.9% longer.
-All probabilities and standard deviations agreed within 5.56e-17; missing masks
-and coverage were identical. These are Apple Silicon measurements (Python
-3.13.15, NumPy 2.5.1, Pandas 3.0.5, DuckDB 1.5.5, scikit-learn 1.9.0, XGBoost
-3.3.0), sampled every 50 ms. Mac physical footprint and Linux PSS/Slurm charges
-are different measurements. Shared filesystem model loading and larger stixels
-can change the speed trade-off on HPC, so these percentages are not a server
-memory guarantee. Model workspace, DuckDB caches and ensemble output buffers
-remain additional allocations; the row limit is not a total job RAM cap.
-
-The package defaults to `prediction_batch_size=None` for compatibility with
-custom batch-dependent and stateful prediction methods. The project occurrence
-runner defaults to 100,000 for its pointwise XGBoost/beta models; `--prediction-batch-size 0`
-restores whole windows. Smaller batches can repeat lazy-model loads, which
-explains part of the time cost. Custom ensemble overrides reject batching
-explicitly; separate-ensemble/median returns retain their full result matrix.
-
-Raw results: [calibrated.json](../data/00_benchmarks/prediction_batches/calibrated.json).
-The comparison removes temporary databases, models and prediction arrays.
-Validation passed 76 checks on Python 3.13 covering batching, streaming, calibration
-and both project runners, plus six focused Python 3.14 checks. The batch reader
-tests cover the older DuckDB API fallback, early reader cleanup, one query per
-window, private estimator row workspaces, nonconsecutive/reversed observation IDs,
-overlapping windows, intentional dummy predictions and matching missing coverage.
-
-```bash
-python scripts/00_benchmarks/compare_prediction_batches.py \
-    --rows 1000000 --features 116 --ensembles 4 --jobs 2 \
-    --calibrated --batches 0 50000 100000 --repeat 3 \
-    --output data/00_benchmarks/prediction_batches/calibrated.json
-```
-
 ## Public choices
 
 Continue passing `base_model` to `AdaSTEMClassifier` or `AdaSTEMRegressor`. Tuning and calibration are independent: