elasticsearch

Follow the triage ladder: confirm the document exists with GET /{index}/_doc/{id}, validate the query with _validate/query?explain=true, run _analyze on the field and query text, then use _explain on a document that should have matched. Most cases are term-on-text mismatches or analyzer asymmetry.

Mappings are append-only, so changing an existing field's type or analyzer requires a new index. Create the destination with the corrected mapping, run _reindex with slices auto, verify counts, then swap the alias atomically with one POST /_aliases call.

A text field is analyzed into tokens at index time, but a term query is not analyzed, so the exact string never matches the stored tokens. Use match on the text field or term on its .keyword sub-field instead.

No. The rrf and linear retrievers plus the Inference API are Enterprise-tier and return HTTP 403 on a basic licence. On basic, fuse a knn clause and a lexical clause inside bool.should, or do reciprocal-rank fusion in the application.

Compute primary shards as max(1, ceil(primary_gb / target_shard_size_gb)) with a 10-50 GB target, never from node count. Budget about 20 shards per GB of heap, with cluster.max_shards_per_node (default 1000) as the hard stop.

Yellow means a replica shard is unassigned, which is degraded redundancy, not data loss; on a single-node cluster it is the expected state. Use _cluster/allocation/explain and read the decider with decision NO to find the actual cause.