A Re-Anchor Fallback Ladder for Edits That Moved

Order the steps by marginal cost, not by accuracy. Similarity scoring runs in your own process on strings you already hold. A model call costs input tokens and latency. A reviewer costs minutes of a person's attention and, eventually, your credibility if you waste it.

The ladder:

Step 1: Score every window in the current file against the stored snippet. Normalize both sides first (collapse whitespace, trim trailing punctuation, optionally lowercase), then compute a similarity ratio. Levenshtein-family edit distance is the usual workhorse; n-gram and Bitap variants trade exactness for speed on short patterns a survey of fuzzy matching algorithms. Accept the best match if it clears your threshold, which the short answer sets at 0.85. Stop.

Step 2: Ask the model once. Send the old snippet, the full current file (or the relevant section), and two or three lines of context from before and after the original location. Ask for a revised snippet and an offset. Accept only if the returned snippet appears in the file at the claimed offset, character for character. One attempt, no retries. A loop of model calls on a single finding is how a modest repair job becomes a budget line.

Step 3: Route to a reviewer. The reviewer gets three things: the old snippet, the top candidate window with its score, and the finding's original claim. Their job is a yes/no on the candidate or a manual placement, not a research task.

The reason similarity comes first is a property of text, not of your system. Neil Fraser's analysis of pattern repetition found that in English prose a fifteen-character pattern has less than a 2% chance of occurring twice in the same chapter, while in the Linux kernel source the same length pattern is likely to occur about 250 times in the same file, mostly because of decorative ASCII separator lines Fuzzy Patch. That single number tells you how the ladder should be tuned: prose anchors are safe to auto-accept at a moderate threshold because ambiguity is rare, but code anchors need a higher threshold and a uniqueness check, because duplicate windows are common.

The comparison below follows the fixture described in the brief: 50 findings whose anchors no longer exist, run through a three-step ladder. The numbers are worked examples you can reproduce on your own fixture, not measurements from a published study, and the cost column assumes a model that bills input and output tokens separately. The estimates assume a mid-sized file (about 1,500 lines, roughly 12,000 tokens) and a short answer (about 60 tokens).

A worked example on the 50-finding fixture, using plausible per-step resolution rates:

• Step 1 (similarity at 0.85 or above) resolves 31 findings. Token cost: zero.
• Step 2 (one model re-ask) runs on the remaining 19. It returns an exact-match offset for 11 of them. Token cost: 19 calls at roughly 12,000 input tokens, call it 228,000 input tokens, plus about 660 output tokens.
• Step 3 sends the last 8 to a reviewer. At three minutes each, that is 24 minutes of review.

Sixty-two percent of the drift was repaired for no tokens at all, and the model handled most of what remained. If you flipped the order and asked the model first, you would spend 50 calls (about 600,000 input tokens) to resolve 42 findings, and similarity would still be the cheaper way to validate the answer. Skip the validation and you inherit the model's false matches.

For teams running this at scale, where the file text is stable across many re-anchor attempts on the same revision, prompt caching changes the arithmetic: cached prefix reads are billed at a fraction of the normal input rate, with reported reductions of up to 90% on input cost for repeated context prompt caching for AI agents. That makes Step 2 cheaper, not unnecessary, because the exact-match check is what protects you, not the price.

The similarity step is where most implementations go wrong, and almost never because the scoring function is bad. It goes wrong in the windowing and the normalization.

Normalize before you compare. Collapse runs of whitespace to a single space, strip trailing whitespace per line, and decide once whether case matters. In code, case usually matters (identifiers), in prose it usually does not.

Window the current file, not the stored snippet. Slide a window the length of the normalized snippet across the current text, one character or one line at a time, and score each position. Scoring the snippet against the whole file as one string gives you a number that means nothing.

Check uniqueness. Keep the top two non-overlapping scores. If the best score is 0.91 and the runner-up is 0.88, you have a coin flip dressed as a match. A useful rule: accept automatically only when the best clears 0.85 and beats the runner-up by at least 0.10. Everything else drops to Step 2.

Cap the work. A character-by-character slide over a large file with an edit-distance calculation at every position is O(n·m) per position and gets slow fast. Slide by line instead, score line-chunks with a token ratio, then refine character positions only inside the winning chunk. Bitap-style approximate substring search exists precisely to avoid scoring every position independently fuzzy matching algorithms.

A minimal implementation of the accept rule:

from difflib import SequenceMatcher

def normalize(s):
    return " ".join(s.split())

def best_windows(snippet, text, top_k=2):
    snip, text = normalize(snippet), normalize(text)
    n = len(snip)
    scored = []
    for i in range(0, max(len(text) - n, 0) + 1, 40):
        window = text[i:i + n]
        scored.append((SequenceMatcher(None, snip, window).ratio(), i))
    scored.sort(reverse=True)
    return scored[:top_k]

def reanchor(stored, current, accept=0.85, margin=0.10):
    top = best_windows(stored, current)
    best = top[0] if top else (0.0, 0)
    runner_up = top[1][0] if len(top) > 1 else 0.0
    if best[0] >= accept and (best[0] - runner_up) >= margin:
        return {"status": "accepted", "score": best[0], "offset": best[1]}
    return {"status": "escalate", "score": best[0]}

The step size of 40 in the loop is a deliberate speed/sensitivity tradeoff: smaller steps find more matches and cost more time. Tune it against your own drift fixture, not by feel.

If Step 1 escalates, the model's job is narrow: find where this text went. Narrow jobs are what prompt structuring is for. Clear delimiters, an explicit output format and a stated role are the structural basics that make responses parseable LaunchDarkly's prompt engineering guide. Being specific about the desired output beats being clever: ask for the exact shape you intend to parse, and nothing else the Prompt Engineering Guide.

A workable template, with labeled sections:

<role>You locate a previously stored code snippet inside a current file.</role>
<task>Return the snippet as it now appears, or the string NOT_FOUND.</task>
<instructions>
1. Read the old snippet and the surrounding context.
2. Find the corresponding text in the current file, which may be edited.
3. Return JSON: {"snippet": "...", "offset": <int>} or {"snippet": "NOT_FOUND"}.
4. The snippet must be copied verbatim from the current file. Do not paraphrase.
</instructions>
<old_snippet>...</old_snippet>
<context_before>...</context_before>
<context_after>...</context_after>
<current_file>...</current_file>

Then verify mechanically. Look up current_file[offset:offset+len(snippet)] and reject if it does not equal snippet. This check is what makes the model step safe, and it is the same discipline behind structured outputs generally: enforce a schema, then validate the parsed result before it touches your data a guide to structured outputs. If you rely on JSON mode from a provider, keep the validation anyway, because JSON mode guarantees syntax, not truth structured output and JSON mode.

Two prompt details pay for themselves. First, put the static instructions and the file text early so that repeated calls on the same revision share a cacheable prefix; prefix matching is how caching works, so variable content goes last prompt caching for AI agents. Second, ask for NOT_FOUND explicitly so the model has an honest exit. Remove that option and you get a fabricated location instead.

When the team running this pipeline is not the team that owns the model, a single API across text, image, video, audio and embedding models simplifies the plumbing: Quanta Inference is OpenAI-compatible, prepaid and priced in dollars.

Set thresholds from data, and set budgets from volume. The decision table below is the version to hand a reviewer or paste into a runbook.

Short anchors deserve their own row. A six-word snippet is not distinctive, and Fraser's pattern analysis explains why: brief patterns repeat often, so a short stored anchor produces multiple candidate windows and the runner-up margin rule will escalate nearly everything anyway. Send short anchors straight to the model, where the surrounding context lines do the disambiguating work.

Budget the ladder per batch rather than per finding. If your batch is 500 findings and your similarity step resolves 60%, you have 200 model calls and possibly 80 reviews. Put a hard cap on Step 2 calls per run and a queue limit on Step 3. When either cap is hit, stop and report the backlog rather than letting the run quietly degrade to "escalate everything."

A review that takes ten minutes per finding will not survive contact with a busy week. The reviewer should be answering one question on a prepared screen: is this the text the finding was about?

Give them three artifacts side by side, in the side-by-side format reviewers already read fluently in code review tools the IntelliJ diff viewer:

• Left: the old snippet with its original context lines.
• Right: the top candidate window with its score and offset.
• Below: the finding's claim, quoted.

Then two actions: confirm (writes the new anchor) or reject (marks the finding as orphaned, with a reason code). Reason codes matter. After a few dozen rejections you will see a pattern, usually a rename or a file split, and you can add a mechanical rule that handles that pattern before it reaches a person.

Track three numbers per batch: the share resolved by similarity, the share resolved by the model, and the share that a reviewer rejects outright. Rising model share with a falling resolution rate is a signal that your stored snippets have aged badly and you should re-capture anchors more often, not tune the thresholds.

Where the reviewer's queue is really a queue of routine, repeatable judgments (re-checking anchors, classifying drift into rename, move or deletion), a specialist that reads your context and hands back finished deliverables removes the per-item setup cost: Quanta Experts is the natural next step for that layer, and Quanta covers the case where the whole pipeline needs a home.

Two integration rules keep the ladder honest.

Never write an anchor you have not verified. Similarity accepts are verified by construction (you have the window text). Model accepts are verified by the offset check. Reviewer accepts are verified by a human. An anchor that skips all three is a guess with a line number attached.

Keep the old snippet. Every accepted re-anchor should retain the pre-edit snippet, the score, the step that resolved it, and a timestamp. When a later edit breaks the new anchor, the ladder restarts from a known-good position rather than from a cascade of guesses. This is the same reason diff tools keep original revisions browsable alongside the latest Review Board documentation.

The ladder also composes with what your diff tooling already computes. If it can tell you a block moved without changing, that is a 1.0 match for free, and the similarity step's job shrinks. If it can say a line was updated in place, that is a candidate for an update rule instead of a move rule the Rich Diff Checker.