A small retrieval-engine project I work on (Vāk-Kaṇaja, Sanskrit + Dravidian classical corpora, fully local on M1) recently passed an inflection point I want to write about because I think it's underdiscussed. The project ships against an explicit research dossier — thirty-some ideas, ranked by expected impact, each with a numeric prediction for ΔnDCG@5 on the project's benchmark. As of this week, eight of the dossier's "Top 10" items are committed, the falsification harness passes by ~13× the gate margin, and one of the predictions is in the "UNDER" category in the calibration table.

That last item — the UNDER — is the most valuable result of the whole quarter, and I think the standard way of writing this up would have buried it. This post argues for the opposite: making UNDER a first-class category turns a "disappointing" result into a precise finding about what the benchmark can and cannot measure.

The setup

The dossier is just a markdown table. Here's the actual top-10 with the numeric predictions:

Cumulative expected: 0.7522 → 0.81–0.84, ambitiously 0.86. The dossier author warns explicitly: "if you exceed 0.88 without a corresponding rise on the null corpus, treat that as a red flag for label leakage rather than a victory."

A few things to notice about how this is written. First, every prediction is a range, not a point. Second, the author predicted some items would be net-zero (item 7) and explicitly flagged what level would be suspicious. Third, item 10 is the falsification harness and the dossier mandates it ship before items 3, 4, 5 — "install before adding novelty."

This is good dossier hygiene. It's the kind of thing alignment / safety / interpretability researchers do well and most ML engineering teams don't.

What happened

Items 1, 2, 4, 6, 8, 10 were already committed when I started. This week I shipped item 3 (which had been written but never wired into the engine — see [previous post]) and item 5 (Poincaré-ball secondary index). I built the falsification harness gate around the bench, I built a corpus.lock.json file to prevent the drift trap, and I ran each new feature through a weight sweep before setting a default.

Then I filled in the calibration column:

Six of the seven measurable items HIT inside the predicted band. One UNDER. The harness passes by an order of magnitude over its gate. Final score: 0.7873.

The UNDER is the finding

Item 5 (Poincaré-ball secondary index) was supposed to be the marquee item — the dossier called it "highest single ΔnDCG, +0.03–0.05." It came in at +0.0067. That's a fifth of the lower bound, an eighth of the upper bound. By naive standards, this is a failure.

It's not a failure. It's a precise statement about what the benchmark cannot measure. Here's the reasoning that turns disappointment into data.

Poincaré-ball embeddings preserve hierarchical distance: if your data is tree-like, two siblings sit far apart at the same depth, while a parent and child sit close at different depths. The mechanism's edge over flat-cosine retrieval shows up when the correct answer is "go deeper into the same subtree" or "pick the right sibling at this level." Examples: distinguishing a specific verse in the Yogasūtra's samādhi-pāda from the rest of the Yogasūtra; picking the correct Upaniṣad when several discuss similar themes.

The 21-query bench used here labels gold at whole-text granularity. A query about consciousness gets relevance=3 if any chunk of the Māṇḍūkya Upaniṣad appears in top-5; it doesn't care which chunk. There's no signal in this bench to reward "you picked the right verse within the right text" — because there's no such gold to begin with.

Cosine retrieval already nails most of these queries because text-level recall is much easier than chunk-level disambiguation. Poincaré can only fire on the small subset of queries where two different traditions share vocabulary about the same topic and the correct text needs to be picked from among them. On this bench, that's about 3 of the 21 queries (puruṣa/prakṛti — Sāṃkhya vs Yoga; tat tvam asi — multiple Upaniṣads; four-states-of-consciousness — Māṇḍūkya vs Bṛhadāraṇyaka). The mechanism delivered a non-zero, unambiguously-positive lift on exactly those queries. Per-text breakdown confirms it.

The dossier prediction wasn't wrong about Poincaré. It was wrong about this bench's ability to measure Poincaré. That's the UNDER finding, and it's the thing that should drive the next quarter's work — either (a) extend the bench to include sub-text-granularity gold and remeasure, or (b) deprioritise Poincaré on this corpus and use it where the substrate is more visibly hierarchical (legal case-law trees, patent classifications, ontology graphs).

The harness PASSes hard

Real nDCG@5 = 0.7873. Three null distributions:

Gate is +0.05; we're at +0.65. Real (0.7873) is well below the 0.88 leakage-suspicion ceiling, so the headline isn't suspect either. The engine genuinely beats label permutation and random retrieval by a lot.

What changed when item 3 (persistent-homology) and item 5 (Poincaré) wire-ins landed? All three null Δ values went up. From the previous run:

Pre-wire-in real:  0.7620   nulls ~ {0.13, 0.11, 0.09}   Δ ~ {+0.63, +0.65, +0.67}
Post-wire-in real: 0.7873   nulls ~ {0.13, 0.12, 0.09}   Δ ~ {+0.65, +0.66, +0.69}

Real moved 0.7620 → 0.7873 while the null means barely shifted. This is what "real signal, not label leakage" looks like in the data: the new features lift real performance but don't lift permuted-label performance. If the new features had been memorising gold labels, the permuted-label score would have moved with the real one.

Why this discipline matters more than the score

The number 0.7873 is interesting. The fact that I can defend it — to a fellowship admissions reviewer, to a frontier-lab safety researcher, to a future-me who's forgotten the context — is more interesting. Every claim in the table above is checkable: there's a corpus.lock.json capturing the exact artifacts the score was measured against, a KANAJA_DISABLE_FEEDBACK=1 env var that prevents the bench from drifting the corpus, and a tests/null_corpus.py that runs the falsification gate on demand.

This kind of discipline is rare in published retrieval / RAG papers, including high-profile ones. It's also exactly the kind of methodology that the major frontier labs' alignment and evaluation teams have moved toward over the last two years (Anthropic's red-teaming and constitutional AI eval work, OpenAI's safety evals after the superalignment shake-up, DeepMind's alignment evals). If you're an independent researcher looking to position into that work, this is the thing that gets attention — not the math, the rigor.

What I'd change if doing it again

A few things I'd do differently if I started this dossier-driven cycle from scratch:

1. Build the harness before any item. I had item 10 in the queue from the start and shipped it relatively early, but a week of items 1, 2, 6 went in without it. Those scores are technically unverified-against-nulls. If I'd shipped 10 first, the whole record would be cleaner.

2. Predictions in expected median and 95% CI, not just a range. A prediction of "+0.02..+0.05" is too easy to retro-fit. A predicted median of +0.035 with a CI of [+0.020, +0.050] forces sharper thinking and produces more interesting UNDER findings.

3. Bench-extension as an explicit dossier item. If the dossier had item 0 = "extend the bench to include sub-text-granularity queries before items 5 and 9," the Poincaré UNDER might have become a HIT. Bench design is a research artifact too; treat it that way.

4. Per-query attribution dashboard. Instead of just per-text, track which queries each new module helps or hurts. Item 3 helped nyāyasūtra queries by +0.087, hurt chandogya queries by -0.080, net +0.0186 mean. That per-query view explains the mechanism cleanly and prevents post-hoc storytelling.

How to copy this for your own project

If you're working on a small ML project — research, side project, indie product — the meta-template that produced this is:

• Write a dossier of 10–30 ideas with numeric predictions and explicit ranges. (LLMs are excellent for this; ask one to write a research dossier for your project, with predicted Δs and references.)
• Build the falsification harness (or its equivalent for your domain) before anything else.
• For each shipped item, fill in measured-vs-predicted in a calibration table that lives in your README.
• Allow UNDER as a first-class category. Document why; don't bury it.
• Lock your corpus / dataset / model checkpoint state with a hash file. Verify in CI.
• Suppress mutating side effects during evaluation (your equivalent of KANAJA_DISABLE_FEEDBACK).

Total infrastructure cost: a few hundred lines of Python. Total epistemic upside: every claim you make becomes precise enough to be wrong, which is the only kind of claim worth making.

Companion posts: the corpus drift trap on cryptographic state locking, and wiring up dead code on finding +1.9% nDCG that's already in your repo. Methodology preprint with full results: [arxiv link]. Code: [github link]. If you'd like to talk shop or want a calibration-discipline audit on your own retrieval / RAG pipeline, sparshsharma219@gmail.com.

This morning I sat down to work on a Sanskrit retrieval engine. The README claimed nDCG@5 = 0.7891. The bench reported 0.7620. The gap is 0.027 — tiny in absolute terms, but the README pinned that number to a specific commit (39f9b7c) and said "verified." Either the README was wrong or something had silently broken. I spent the first hour assuming a code regression. I was wrong. The actual culprit is one of the most underrated bugs in modern ML evaluation, and almost every RAG pipeline I've audited has some flavour of it.

This post is the detective story. It ends with a 200-line tool that I'd put in every retrieval repo I touch from now on.

Setup

Vāk-Kaṇaja is a small retrieval engine over thirteen classical Sanskrit and Dravidian texts — Yogasūtra, Upaniṣads, Pāṇini's grammar, Arthaśāstra, that lineage. About 6,300 text chunks. The bench is twenty-one English queries with whole-text gold labels (relevance ∈ {2, 3}) and an nDCG@5 metric. Nothing exotic.

The codebase has a pleasant rhythm: each commit on the phase1-fractal-upgrades branch lands one item from a research dossier, with a commit message that always includes the resulting nDCG@5. Authors of the previous commits had been fastidious about this — most messages literally say score-neutral nDCG@5=X.YYYY to flag refactors that shouldn't have moved the needle.

So when today's bench reported 0.7620 against a README that said 0.7891, my first instinct was: bisect.

The first wrong hypothesis

The two suspect commits looked like this:

39f9b7c  phase1 step1.5: fractal channel disabled (winner), nDCG=0.7891
e3c2748  phase-A:  pre-Phase-8 hygiene  (10 audit items, score-neutral nDCG@5=0.7620)
8265bf1  phase-B:  verification surface (5 audit items, score-neutral nDCG@5=0.7712)

Look at that gap. Phase-A claims "score-neutral" but lands at 0.7620. The previous baseline was 0.7891. That's a 0.027 drop labelled as zero. Either the author miscounted, or they measured against a different state than I'm measuring against.

I started reading phase-A's diff. Twenty-one files changed. Most of it was hygiene: print() → logger.info(), except Exception: → typed catches, file moves, gitignore additions, requirements lock cleanup. The only retrieval-path file touched was retrieval/kanaja_fsh.py, with 23 line changes. I read every one. They were all print → logger substitutions plus one exception handler that swallowed the same exception either way (just logged it now). Truly inert.

This is when most engineers would assume the README's 0.7891 was wrong. Move on, update the README, ship.

The second wrong hypothesis

I almost did, then noticed something. The corpus database file (corpus/fractal_signatures.db) had a modification time that didn't match either commit. It had been touched ~27 minutes before the phase-A commit landed. The schema, when I dumped it, had a trail of ALTER TABLE columns — h2, asym_f, lacunarity — added across multiple later commits.

In other words: the corpus DB was a moving target. The bench at any commit was reading from whatever state the DB happened to be in, not from a state pinned to that commit.

This shifted the hypothesis: maybe the regression isn't in code at all. Maybe the same code today produces a different score than the same code three weeks ago because the DB it reads has changed.

The clean test: check out 39f9b7c in a git worktree, point it at today's runtime corpus DB, run the bench. If it scores 0.7891 (the README's claim), the regression is in newer code. If it scores something else, the regression is in the corpus.

git worktree add /tmp/vak39f9b7c 39f9b7c
ln -sf .../fractal_signatures.db /tmp/vak39f9b7c/corpus/fractal_signatures.db
ln -sf .../faiss_index.bin       /tmp/vak39f9b7c/corpus/faiss_index.bin
# ... and the rest of the corpus artifacts
cd /tmp/vak39f9b7c && python3 tests/sanskrit_bench.py

The result: 0.7206.

Reading the result honestly

Old code on today's corpus: 0.7206. Today's code on today's corpus: 0.7620. README's claim, on a corpus snapshot that no longer exists: 0.7891.

There is no recoverable regression. Old code on the new corpus is worse, not better — it can't take advantage of the columns added by intervening migrations, and may even be confused by their presence. The 0.7891 number was real at commit time, against an artifact state that no longer exists.

So the chain wasn't 0.7891 → regression → 0.7620. It was three separate states being compared apples-to-oranges:

Commit 39f9b7c, on  corpus_state_A    →  0.7891
Commit 39f9b7c, on  corpus_state_today → 0.7206  (the actual reproducibility)
Commit HEAD, on    corpus_state_today  →  0.7620 (today's measurement)

The "score-neutral" annotation on phase-A wasn't false in spirit — the code change was indeed score-neutral. But the corpus state had drifted in the background, and the author measured against a different DB than 39f9b7c's author did. Neither was wrong. Both were correct. The comparison was wrong.

This is the corpus drift trap. It's invisible in git diff. It's invisible in the test suite. It's invisible in code review. It only manifests when someone asks "wait, where did the 0.027 go?" and tries to bisect.

Why this matters beyond one Sanskrit engine

Every RAG pipeline I've audited has at least one of these mutating artifacts:

• An embedding index rebuilt when chunking strategy changes. Different chunks → different embeddings → different cosine top-k → different downstream scores. Often invisible because the chunking script is in a separate repo.
• A BM25 cache built once and never invalidated when tokenisation rules change.
• A knowledge graph that gets enriched by background jobs. Same query against the same KG returns different neighbours next month.
• Per-document priors — click-through rates, freshness scores, embedding-drift signals — that update on every query and silently change the ranker's behaviour.

In every case, "we ran the bench at commit X and got Y" is a true statement that cannot be reproduced later because Y depends on artifacts that aren't in the commit. When someone three months later cites your nDCG, they're citing a number that was real for an hour.

The fix is small

Two pieces, totalling about 250 lines of Python.

Piece 1 — corpus.lock.json. A tool that walks every binary corpus artifact (.db, .bin, .json, .pkl), captures sha256 + size, alongside the current git commit and the verified bench score, and writes the lot to a JSON file you commit:

{
  "version": 1,
  "generated_at": "2026-05-01T01:37:46Z",
  "git": {"commit": "a5cd404", "branch": "phase1-fractal-upgrades", "dirty": false},
  "artifacts": {
    "corpus/fractal_signatures.db": {"sha256": "04918ed4...", "size_bytes": 90886144},
    "corpus/faiss_index.bin":       {"sha256": "2319f9cb...", "size_bytes":  9690669},
    ...
  },
  "bench": {"nDCG@5": 0.7873}
}

A --verify mode reads the lock and exits non-zero on any sha256 drift, missing artifact, extra artifact, or git-commit drift. Future "score-neutral" claims become checkable: re-emit, diff, see exactly what changed.

Piece 2 — bench-side feedback suppression. The Vāk-Kaṇaja engine has a closed-loop H-update path: when retrieval seems off, it nudges the H values in the signatures DB to drift the next query toward better answers. Production-correct behaviour. But this means each bench run mutates the corpus, and the next bench reads a different state. The lock file would never stay green.

The fix is one env var — KANAJA_DISABLE_FEEDBACK=1 — that short-circuits the feedback path when set. The bench harness sets it via os.environ.setdefault at the top of the bench file. Production deployments leave it unset.

After both pieces landed, two consecutive bench runs left the corpus byte-identical. The lock verified clean. The score was reproducible. (Bonus: the fix also surfaced two latent bugs in the feedback path — a closed-database error firing on every query and a database is locked race — which we patched the same afternoon.)

What this changes about how I read RAG papers

Every retrieval claim has an implicit attached question now: what's the sha256 of the corpus you measured against, and how do I check it? If the answer isn't in the paper, the score is unverifiable. Not wrong, just unverifiable. That's a different category from "wrong" — but it's also a different category from "validated."

It also changes how I read commit messages. "Score-neutral" only means "I changed code that I expect doesn't move the score." It says nothing about whether the corpus the score was measured against has drifted since the previous commit. The two propositions are independent and both need to be checked.

The simplest version you can copy

If you want to steal the pattern for your own RAG repo, the minimal diff is:

1. Write a tiny script that walks your corpus directory, hashes the binary files, dumps corpus.lock.json. ~80 lines.
2. Add a --verify mode. ~40 lines.
3. Find any code path that mutates corpus state during evaluation (feedback loops, click logging, freshness updates) and put it behind an env var that your bench sets. ~10 lines.
4. Commit corpus.lock.json. Run --verify in CI. Reject any PR that drifts the lock without a corresponding intentional re-emit.

Total cost: a couple of hours. Total benefit: every score claim in the repo becomes falsifiable, and you can finally answer "did this PR regress the bench?" without ambiguity.

A reference implementation of the lock protocol — lock_state and verify_state — is in the public falsify-eval library at github.com/spalsh-spec/falsify-eval (Apache 2.0). Adapt freely.

If you've debugged a similar drift in your own pipeline, I'd love to hear about it — sparshsharma219@gmail.com. I'm also taking on a small number of $5k fixed-price RAG audits where I find drift, dead code paths, and uncalibrated claims in production retrieval systems. If you're shipping retrieval and not sure your scores reproduce, [reach out].

A few weeks ago, a previous version of me — same engineer, different mood — committed this with a clean message:

phase1 step3: persistent-homology re-ranker (dossier §2.2 #3)

The commit added a 314-line module, retrieval/topo_rerank.py, with rigorous docstring, ripser/persim dependencies installed cleanly, and a small unit-test suite that passed. The module's design had been sketched in the research dossier, validated in isolation, and merged. By every visible signal — green tests, passing lint, sensible commit message — the feature was shipped.

Today I noticed something. The bench score hadn't moved on that commit. Not by 0.001. The dossier had predicted +0.02–0.03 nDCG@5 from this re-ranker; the reality was zero.

Spoiler: the function existed but was never called from anything except its own tests. Wiring it in took 17 lines. The score went from 0.7686 to 0.7873. One commit, +0.0186 nDCG, ~3% relative lift, recovered with no algorithmic change at all.

This pattern is common enough that I'd bet you have a version of it in your own RAG pipeline right now. Here's how to find it.

The two-minute audit

Pick any feature in your retrieval system that you think is "shipped." Run this:

grep -rn "from .* import <feature_name>\|import .*<feature_name>" \
    --include="*.py" .

Now subtract any matches that come from tests/ or from the module itself. What's left is the set of production-code call sites for that feature. If that set is empty, you're not using it.

For me, the result was:

$ grep -rn "topo_rerank\|from retrieval.topo" --include="*.py" .
./retrieval/topo_rerank.py:1:"""..."""
./retrieval/topo_rerank.py:180:def topo_rerank(...
./tests/unit/test_topo_rerank.py: ... (the only callers)

Three matches in the source file (defining itself), one in the test file. Zero in the engine entry point. That's a feature that exists exclusively for the satisfaction of its tests.

How this happens

It's not negligence. It's a specific dynamic that produces this outcome over and over:

1. Research and integration are scoped separately. The dossier said "ship the formalism + tests first, integrate after." That's a sensible engineering norm. But the integration ticket gets deprioritised by the next exciting research item, and the original integration intent fades from memory.
2. The commit message lies cleanly. "Persistent-homology re-ranker" sounds done. The diff shows the function. The tests pass. Reviewers approve. Nothing in the surface signal indicates the function is dead.
3. Score regression tests don't catch dead code. If you ship a feature wired to weight=0 by default, the bench score doesn't move. If you ship a feature not wired in at all, the bench score also doesn't move. From the bench's perspective, these are indistinguishable.

This last one is critical. The most common way teams catch missing integration is "the score got worse after the wire-in PR" — but that only fires once you actually attempt the wire-in. Dead code that no one tries to wire in stays dead forever.

The systematic fix

For any retrieval pipeline of nontrivial size, I now do this once a quarter and once whenever I'm new to a codebase:

Step 1 — Inventory the rerankers. List every function whose docstring or name implies it modifies the retrieval ranking. Don't trust the directory structure or the commit messages. Read.

Step 2 — Trace each one to a call site outside its own tests. Use the grep above. Anything without a production call site is either dead code or scaffolding awaiting integration.

Step 3 — Distinguish the two cases. If it's scaffolding awaiting integration, wire it in (with a default weight of 0 if you want zero behaviour change), then sweep its weight to find the peak. If it's dead code with no plausible value, delete it — keeping it costs you cognitive load on every future grep.

Step 4 — For each newly wired feature, run the falsification harness. Make sure it's not adding label leakage. (If you don't have a falsification harness, that's a separate post.)

The whole audit took me about 90 minutes per pipeline.

The wire-in itself

In case it helps, here's exactly what the integration looked like for the persistent-homology reranker. The pre-existing function took:

topo_rerank(
    query_embedding: np.ndarray,            # (D,) query vector
    candidate_embeddings: np.ndarray,       # (K, D) top-K from prior stage
    candidate_ids: Iterable,
    *,
    score_mode: str = "image_l2",
    top_k: Optional[int] = None,
) -> list[tuple[object, float, dict]]

Its own docstring warned: "Scores are unitless. To fuse with the existing ranker, normalise (z-score or rank-transform) both scores then combine with a weight." So the wrapper rank-transforms then adds:

def topo_persistence_rerank(
    reranked,
    query_embedding,
    embedding_lookup,
    topo_weight=None,
    top_k=50,
):
    if topo_weight is None:
        topo_weight = CHANNEL_WEIGHTS["topo"]   # read at CALL time, not def time
    if topo_weight == 0.0 or len(reranked) < 3:
        return reranked

    # Pull (K, D) embeddings for the top-K candidates from the engine's FAISS
    head = reranked[:top_k]
    embs, valid_ids = [], []
    for cid, _, _ in head:
        emb = embedding_lookup(cid)
        if emb is not None:
            embs.append(emb); valid_ids.append(cid)
    if len(embs) < 3:
        return reranked

    topo_results = topo_rerank(query_embedding, np.array(embs), valid_ids)

    # Rank-transform to [0, 1] so weight competes on the same scale as RRF.
    raw = {cid: float(s) for cid, s, _ in topo_results}
    sorted_cids = sorted(raw, key=lambda c: raw[c])
    n = max(len(sorted_cids) - 1, 1)
    rank_norm = {cid: i / n for i, cid in enumerate(sorted_cids)}

    out = []
    for cid, score, stats in head:
        boost = topo_weight * rank_norm.get(cid, 0.5)
        out.append((cid, score + boost, {**stats, "topo_rank": rank_norm.get(cid)}))
    out.sort(key=lambda t: t[1], reverse=True)
    return out + reranked[top_k:]

Plus the one-line call site in the engine:

reranked = topo_persistence_rerank(reranked, enc["full_emb"], _embed_lookup)

Total: 50ish lines of wrapper, 1 call site, 1 line for the channel weight default. Zero algorithmic novelty. Module already existed. Tests already passed.

The two traps inside the wire-in

If you do this exercise, watch for these:

Trap 1: closure-capture on the weight default. Tempting to write:

def topo_persistence_rerank(reranked, ..., topo_weight=CHANNEL_WEIGHTS["topo"]): ...

This binds topo_weight to whatever CHANNEL_WEIGHTS["topo"] was at function-definition time. When you later monkey-patch the global to sweep weights, the default doesn't update. Your sweep silently runs at the original weight every time. (I caught this on the first sweep — it produced six identical rows.) Use topo_weight=None and read the global on the first line of the function body.

Trap 2: scale mismatch. Re-ranker scores from different mechanisms have different natural scales. RRF scores in my pipeline live in roughly [0.001, 0.02] — gaps between consecutive ranks are around 0.001. If you blindly add weight × raw_score where raw_score happens to be in [0, 1], even a tiny weight (0.05) produces a perturbation 30× larger than the RRF gap, completely overwriting the existing ranking. The result is unimodal: a sharp peak at one specific small weight, with a knee just past it where the score crashes. My sweep showed:

w        nDCG@5    Δ
0.0000   0.7686    baseline
0.0005   0.7686    +0.0000  (perturbation below RRF gap)
0.0010   0.7873    +0.0186  ← peak
0.0020   0.7853    +0.0166
0.0050   0.7236    -0.0450  (over the knee)
0.0100   0.5712    -0.1974  (chaos)

Always rank-transform or z-score the new feature before combining, and always sweep on a logarithmic ladder that includes weights smaller than your RRF gap.

The meta-lesson

The biggest available wins in a retrieval pipeline are usually not new algorithms. They are dormant features waiting for someone to wire them in correctly. This is true partly because of the integration-vs-research split above, partly because the kind of person who writes a clever rerank module is often not the kind of person who patches the engine to call it, and partly because the bench tells you nothing when integration is missing.

I'm now constitutionally suspicious of any retrieval repo where the rerankers are in a retrieval/ directory and I can't immediately see them being called from the engine entry point. If they're not called, they're either decoration or pending work. Either way, treat them as a TODO.

This was the second of three blog posts on what I learnt rebuilding the verification surface of a small Sanskrit retrieval engine. The first was on corpus drift. The third (forthcoming) is on calibrating predicted-vs-measured Δ on a research dossier so failures become findings, not embarrassments.

If you'd like a fixed-price audit of your retrieval pipeline — dead code, drift, uncalibrated claims, and a written report — I'm taking 2 per month at $5k. Email sparshsharma219@gmail.com.