Function index_admissible_for_resolved_time_range 

pub fn index_admissible_for_resolved_time_range(
    index: &Index,
    resolved_time_ranges: &[ResolvedTimeRange],
) -> bool

Whether index may serve a query whose equality clauses on resolved_time_ranges were produced by resolve_time_range_bucket_clause.

A time-range index does not store the source field’s raw values: under its grid-qualified first level it stores bucket starts, and one document is stored once per bucket that contains its timestamp. So a bucketed index, a raw index and another grid’s bucketed index are never interchangeable, and every mismatch is silent — a validly-proven wrong answer rather than an error:

• A raw query (resolved_time_ranges empty) that landed on a bucketed index would compare a real timestamp against bucket starts and see nothing (or, for range/IN shapes, walk overlapping buckets and count the same document up to overlap_factor times).
• A resolved query that landed on a raw index would compare a bucket start against real timestamps and see nothing.
• A resolved query that landed on a different grid’s index would compare one grid’s bucket start against another grid’s — every 6-hour start is also a 3-hour start, so this can silently return the wrong window.

Hence the rule: with no resolution only non-bucketed indexes are admissible, and with one resolution only an index bucketing exactly that field with exactly that grid is. Two resolutions can never be served by a single index — a transform’s source must be its index’s first property, so one index buckets exactly one field — and are rejected by the caller.