index = auxiliary structure that maps a question to candidate data

where should I look?

read speed  vs  write cost, storage cost, freshness, and complexity
(capacity.md axis 5: every index moves cost from read-time to
write-time + storage; the query pattern must amortize it)

exact:        the entry IS the answer, or points directly to it —
              false positives and false negatives both forbidden
              (primary index, covering secondary)
candidate:    false positives fine, FALSE NEGATIVES CATASTROPHIC —
              answers must be verified against truth; pruning only
              (bloom filters, zone maps, sparse indexes, routing)
approximate:  false negatives permitted and PRICED — recall is a dial
              declared to the caller, not a bug
              (vector ANN: HNSW, IVF/PQ)

Which rung? Is it written down, or assumed by half the callers?
Candidate rung: where is the verification step, and can it be skipped?
Approximate rung: what recall, measured how, declared where?
Exact rung: what maintains exactness, and at what write cost?

point:            hash / B-tree            hot key
range/order:      B-tree, BRIN, sorted     hot range; sort-order mismatch
containment:      inverted index/postings  analyzer ≠ equality; stale ranking stats
set-combination:  bitmaps (Roaring)        cardinality blowup; row-ID remap
similarity:       HNSW / IVF               wrong metric; embedding version drift
spatial:          S2 / geohash / H3 / R-tree  boundary false positives; hot city cells
temporal:         time index               event-time vs ingest-time; late data
label-match:      label -> series IDs      cardinality explosion; churn

What question, precisely, does the index answer — and is the query's
  predicate actually the indexed shape? (prefix ≠ contains; analyzed ≠ exact)
Which pathology does this shape invite, and what bounds it?
Selectivity: does the predicate narrow enough to beat a scan?

rows:            primary lookup, postings lists
blocks/files:    sparse indexes, zone maps, per-SSTable blooms —
                 pruning units, not answers
owners:          routing indexes — key/query -> shard/endpoint

routing index ≠ ownership proof.
a routing entry is ADVISORY placement (scheduler.md axis 4);
treating it as leased/fenced ownership is the split-brain bug.
routing inherits view-vs-reality* — it owns nothing new.

Row, block, or owner? Coarser codomain = cheaper index + mandatory second hop.
Owner codomain: what fences the route? (nothing — so what does, downstream?)
Does the route provably include ALL relevant data, or just the common case?

synchronous:     index updated in the source's transaction —
                 divergence impossible, write latency paid
                 (B-tree in the same txn, LSI)
asynchronous:    divergence is a WHEN, not an if — the lag must be
                 named and observable
                 (GSI, search ingestion pipelines, rollups)
immutable-per-segment: written once with the segment; freshness by
                 generation replacement; merged under GC's
                 publication protocol
                 (Lucene segments, Parquet stats, SSTable blooms)

sync ≈ write-through      async ≈ invalidation/eventual      segment ≈ version-pinned
"deleted doc still visible" = a stale cache entry
"stats not tied to schema version" = key incompleteness (cache.md axis 4)

Is index update atomic with source update? If not — lag SLO, measured where?
Can the index be rebuilt from source truth? (if the index is the only copy,
  it stopped being an index and became the primary — checkpoint_replay.md)
How is drift DETECTED, not just repaired — sampling, checksums, counts?

selectivity:        low-selectivity secondary index costs more than it saves
cardinality:        bitmap and label indexes blow up past their regime
write amplification: every maintained index is a tax on every write
coverage:           covering index ends the lookup; partial index shrinks the tax

What is the hit pattern that amortizes this index — measured or hoped?
What happens at 10× the cardinality? (label churn, term dictionary growth)
Which queries does it NOT cover, and do callers know they're scanning?

a false negative is invisible at query time.
you cannot see what the index didn't return —
the error announces itself never, or in an incident.

incorrect stats drop valid data          route omits relevant shard
bloom false negative (catastrophic)      index points past a missing row
query not covered but caller assumes it  deleted-doc bitset wrong way

one-sided by construction    a Bloom filter CANNOT produce a false
                             negative — the math forbids it; that is why
                             it is the canonical pruning primitive.
                             prefer structures whose dangerous error is
                             impossible, not merely rare (flagship)
conservative pruning         skip only what is PROVABLY impossible —
                             min/max semantics must be sound under nulls,
                             NaN, collation, schema version
mandatory verification       on the candidate rung, verify-against-truth
                             is a protocol step, not an optimization
rebuildability               source truth survives independently;
                             a suspect index can be dropped and rebuilt
drift detection              sample/checksum index against source —
                             hunt the invisible error on a schedule

what the index maps from and to,
which answer contract it honors (named rung),
how it is maintained and how stale it may be,
how candidates are verified against truth,
and how a silent omission would ever be noticed.

extract indexable fields from source
insert/update/delete entries (per axis-4 coupling)
publish index generation/segment (GC's atomic-publish discipline)
lookup predicate in index
return candidate locations/IDs
verify/filter candidates against truth   <- load-bearing on the candidate rung
merge results across shards/segments
repair/rebuild on detected drift

check bloom filter            (candidate: one-sided, no false negatives)
sparse block index -> seek    (candidate: block granularity)
scan block for key            (exact: verification step)
merge newer sources by seqno  (freshness: axis 4)

analyze terms -> term dictionary -> postings
intersect/union postings -> score -> merge top-k across segments
(analyzer mismatch = asking a different question than you indexed)

manifest/segment stats -> evaluate predicate against min/max/null
skip impossible units -> scan remainder -> filter exact rows
(pruning is candidate-rung: stats prune, they never authorize)

key  predicate  candidate set  posting list  bitmap
row ID  doc ID  block  segment  boundary  zone map
false positive  false negative  one-sided  recall
selectivity  cardinality  coverage  covering index
analyzer  term dictionary  grain  rollup
write amplification  maintenance  rebuild  drift
generation  segment publish  pruning  pushdown

candidate            vs  truth                (axis 1: verification is load-bearing)
index freshness      vs  source freshness     (axis 4: an index is a cache)
low-cardinality      vs  high-cardinality     (axis 5: structures have regimes)
routing index        vs  ownership proof      (axis 3: advisory ≠ fenced — scheduler.md)
analyzer             vs  exact equality       (axis 2: you indexed a different question)
approximate search   vs  exact recall         (axis 1: recall is declared, not assumed)
statistics pruning   vs  authoritative filter (axis 1 + bottleneck*: stats prune,
                                               never authorize — and their unsoundness
                                               is the silent kind)