<!-- llms-explorer concept facts · https://llms-explorer.com/tree/ranked-and-scored-input-pipeline-eligibility/ · pack 2026-10-23 · ~1459 tokens -->

# Ranked and scored input pipeline eligibility

> Source-anchored research for Ranked and scored input pipeline eligibility. Run status: COMPLETED.

Parent: [Atlas Hybrid Fusion and BM25 Diagnostics](https://llms-explorer.com/tree/mongodb-atlas-hybrid-fusion-bm25-frontier-20261001/) · 4 facets · 13 facts · page: https://llms-explorer.com/tree/ranked-and-scored-input-pipeline-eligibility/

## How it works

- A $scoreFusion input must supply score metadata. The documentation lists initial $search, $vectorSearch or legacy $match with text search as implicit scoring cases, and requires an explicit $score when a pipeline does not inherently return a score. An explicit $sort alone therefore does not establish score eligibility. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/scoreFusion.md)
- Place diagnostic $project, $addFields or $set operations after the fusion stage. Reshaping an input arm violates document preservation even when it merely exposes a search score; both fusion operators document projecting scoreDetails metadata in a subsequent stage. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankFusion.md)
- SERVER-117661 describes feature-gated extension validation: a selection extension such as $matchTopN is allowed, a transforming $addFieldsMatch is rejected, and $nativeVectorSearch is rejected when its expansion includes a non-selection $setMetadata tail. The ticket lists fix version 9.0.0-rc1; these cases must not be assumed available on every Atlas deployment. (low confidence) (verified as of 2026-09-29) — [source](https://jira.mongodb.org/browse/SERVER-117661)
- Meeting the ranked-input contract does not guarantee that rank fusion retains all useful retrieval evidence: the Pinecone-authored fusion study explains that RRF discards score distributions and score gaps when ranks stay fixed. This limits any claim that syntactic eligibility implies an optimal fusion choice. (medium confidence) — [source](https://arxiv.org/html/2210.11934v2)

## Problems, failure modes and limitations

- Both operators require input branches on the same collection, with at least one uniquely named branch. Branch names cannot be empty, start with $, contain a dot, or contain a null character. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankFusion.md)
- For a custom top-k scoring branch, compute score metadata with $score, sort by that metadata, then apply $limit. The MongoDB worked example uses this sequence for distance and rating signals; merely storing a number in an ordinary field is not the demonstrated scoring contract. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/scoreFusion.md)

## Comparisons and alternatives

- RRF consumes positions in ranked result lists rather than the magnitudes of the original retrieval scores. OpenSearch documents the same algorithmic distinction, and Bruch, Gai, and Ingber define RRF in terms of lexical and semantic ranks. This corroborates why ranked evidence differs from numeric scores; it does not transfer OpenSearch validation rules to MongoDB. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankFusion.md)

## Facts and statements

- Every MongoDB fusion input branch must preserve the retrieved documents: $rankFusion requires a selection pipeline plus a ranked pipeline; $scoreFusion requires a selection pipeline plus a scoring pipeline. An ordered branch and a scored branch are distinct eligibility categories. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankFusion.md)
- A $rankFusion input must be both a selection pipeline and a ranked pipeline. The documented ranking criterion is either an initial $search, $vectorSearch or $geoNear stage, or an explicit $sort. A $match-only or $sample-only arm does not satisfy that ranking criterion. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankFusion.md)
- A $geoNear branch can provide rank directly to $rankFusion, but distance is not itself the score required by $scoreFusion: the latter needs an explicit $score. Avoid distanceField and location-output options that alter documents inside selection branches. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankFusion.md)
- SERVER-101701 records a historical validation hole: a preceding $match followed by $rankFusion with a custom $sort branch was accepted even though $rankFusion was required to be first. The ticket lists fixes in 8.1.0-rc0, 8.2.0-rc0, and 8.0.14; old acceptance is not proof that such placement is supported. (low confidence) (verified as of 2026-09-29) — [source](https://jira.mongodb.org/browse/SERVER-101701)
- Both $rankFusion and $scoreFusion require at least one uniquely named input pipeline, all operating on the same collection. Their selection-pipeline requirement preserves retrieved document contents; matching, ordering and pagination can select documents without reshaping them. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankFusion.md)
- $score computes numeric score metadata while preserving the input document fields. It is the documented way to supply a score for a $scoreFusion arm that lacks one; adding an ordinary document field named score is not the same metadata operation. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/scoreFusion.md)
