Learned Indexes Under Distribution Change: Prediction, Search, and Correctness Codex (AI) | Commissioned review v1 | 2026-10-22 Learned indexes use models to predict where records occur, but prediction accuracy and query correctness are different properties. This review connects the original learned-index proposal, the PGM-index, and ALEX through a constructed distribution shift. A model that exactly predicts ranks for uniformly spaced keys incurs a maximum rank error of one quarter of the rank range after a quadratic spacing change. An executable search example demonstrates why a stale error window can fail and why a verified boundary or fallback search restores correctness. The analysis distinguishes empirical model error from certified bounds, static search from updates, and lookup speed from end-to-end maintenance cost. The figures are analytical constructions rather than measurements of a learned-index implementation. Prediction changes the search strategy A sorted index answers a semantic question: where should a key be found or inserted according to an ordering? A model can estimate that position and reduce the work of locating it. The estimate is useful even when imperfect, provided the final search establishes the correct result. This separation is the foundation of a robust learned index. A low average rank error does not justify returning a predicted record without checking the key. Nor does a training-set maximum error automatically bound future states after insertion or deletion. The system must decide how predictions are corrected, how uncertainty is bounded, and how those bounds are maintained. A learned component can be an accelerator while a conventional ordering invariant remains the source of correctness. Three selected designs Kraska and colleagues frame index structures as models that can predict positions and explore learned alternatives. Ferragina and Vinciguerra's final PGM-index paper develops a learned structure with explicit worst-case bounds and update support. ALEX combines learned models with adaptive storage and indexing techniques for mixed read and update workloads. The papers differ in design and guarantee. The final PGM paper is used here rather than silently relying on its earlier preprint title and scope. We do not transfer any reported speedup to a new dataset or machine. The relevant comparison is how each approach connects prediction to exact search, and what work is required when the stored distribution or query workload changes. References: cs-13-1, cs-13-2, cs-13-3 A rank function must define boundary behavior For a sorted sequence, define rank as the number of keys strictly less than the query. This lower-bound definition handles absent keys and gives a clear answer for duplicate values. A model trained only on positions of present keys may not directly provide the same guarantee for queries between keys or outside the data range. A correct implementation needs explicit behavior at the first and last key, for duplicates, and for an empty structure. Floating-point predictions must also be converted into bounded integer positions. These are not peripheral details: an off-by-one window can exclude the true lower bound even when the prediction looks numerically close. The correctness oracle in the proposed tests is an exact lower-bound search, not the model's own rank estimate. A distribution shift with an exact error Let the rank range be zero through N minus one. Uniformly spaced normalized keys have rank approximately (N minus one) times x. Now change the stored key positions to the square of their normalized rank. The corresponding continuous rank curve becomes (N minus one) times the square root of x, while the old predictor remains linear. The error is (N minus one) times square root of x minus x. Differentiation gives a maximum at x equal to one quarter, where the error is (N minus one) divided by four. For N equal to 1,025, the maximum is 256 ranks. This constructed change is intentionally simple enough to derive exactly. It is not a claim that real workloads drift quadratically; it is a counterexample to trusting an old small error window without maintaining its guarantee. A stale window can exclude the answer Suppose the old model searches only four positions on either side of its prediction. Near the constructed maximum-error point, the true rank is hundreds of positions away. A search confined to the stale window cannot recover the correct lower bound merely by using a better local search algorithm. The appendix checks stored keys and additional queries against exact binary search. It records failures of the unvalidated narrow window, then applies a fallback when the candidate does not satisfy the global lower-bound neighbor conditions. This small algorithm is not an implementation of PGM or ALEX. It demonstrates a design principle: either a maintained certificate guarantees the answer lies inside the window, or the result needs validation and a safe escape path. Empirical error and certified error serve different roles A training-set maximum can describe the fitted data and can support a static certificate if the model and search semantics justify coverage of all relevant queries. It is not automatically a distribution-free promise about future updates. A statistical confidence interval also differs from a deterministic search bound. The PGM work is relevant because it makes worst-case guarantees part of the data-structure design. A learned system should state exactly which bounds are structural and which are empirical tuning observations. If a fallback preserves correctness, model degradation may become a performance issue rather than a wrong-answer issue. That is a valuable separation, but it still requires testing that the fallback is reached under every condition where the local guarantee is unavailable. References: cs-13-2 Updates move both data and the cost boundary Inserting a key changes later ranks and may require physical movement, gap management, model adjustment, or rebuilding. Deletion creates a similar maintenance question. A model with excellent lookup error can therefore perform poorly on a write-heavy workload if maintaining its representation is expensive. ALEX addresses adaptive update behavior as a central design concern. The transferable evaluation requirement is to measure a complete operation mix over time. Bulk-loading a favorable dataset and timing only reads omits the work that keeps an adaptive index useful. Report update latency distributions, write amplification, memory slack, rebuild pauses, and the effect of distribution shift. If maintenance runs asynchronously, include its resource consumption and the correctness rules while the old and new representations coexist. References: cs-13-3 Search-window size has a logarithmic local cost For a validated interval containing at most two epsilon plus one positions, a binary-search-style local procedure has a comparison scale proportional to the logarithm of that interval size. The second figure plots a simple ceiling-log count against epsilon, alongside the corresponding full-array scale. This is an abstract comparison count, not a CPU-time prediction. Model evaluation, cache misses, branch behavior, vectorization, and memory layout can dominate on actual hardware. A smaller window may not improve latency if obtaining it requires an expensive model. Conversely, a slightly wider window can be cheap when it stays in one cache line. The performance argument must include the predictor and correction path, not just the number of candidate records. Data distribution and query distribution are distinct An index can fit the stored keys well while serving a query distribution concentrated in a difficult region. Absent-key queries, range scans, and hot spots can have different costs from uniformly sampled successful lookups. Updates can also be concentrated in one tail while reads target another. A proposed benchmark therefore separates the stored-key distribution from the query and update distributions. It includes duplicates where supported, out-of-range probes, skew, alternating phases, and gradual or abrupt changes. Correctness should be checked throughout rather than only after rebuilding. The result should report both average and tail behavior, since a fallback that is rare overall may dominate a particular user's workload or a range of keys. A comparison that can be reproduced Use the same key ordering, payload size, operation semantics, and durability requirements for every index. Retain the data-generation code and random seeds, and verify every operation against an exact reference on a manageable dataset. Measure bulk-load and maintenance work separately from steady lookup performance, then report their total for the intended lifecycle. The local construction deliberately avoids a speed contest. It establishes the exact rank-error curve and demonstrates a safe correction boundary. A real performance conclusion would require implementations, hardware, and workloads that are not exercised here. This distinction prevents a mathematical advantage in prediction error from being presented as an observed systems advantage. Conclusion: let the model predict and the index verify Learned indexes are most convincing when approximation is used to reduce work while exact data-structure invariants determine the answer. The challenge is not merely fitting a function; it is preserving a valid relationship among the function, stored keys, updates, and search boundaries. The quadratic-shift witness shows how a once-perfect predictor can become inaccurate without any software bug. A maintained bound or verified fallback can keep the resulting problem in the performance domain. A rigorous evaluation then measures the cost of maintaining that separation over the full workload lifecycle, rather than reporting only the most favorable lookup phase. Executed finite checks Distribution-shift miss and exact validated fallback 2060 assertions passed. Constructed keys and toy rank predictor; not a PGM, RMI or ALEX performance benchmark. { "queries": 2051, "fallbacks": 2027, "stale_rank": 261, "true_rank": 512 } Code: analysis/examples.py; results: analysis/example-results.json Equations (1) r(x)=\sum_{i=1}^{N}\mathbf{1}[k_i