Make a Model Finding Land on the Right Line
A model can identify a real concern and still produce an unusable review comment if the location is wrong. OpenCodeReview therefore treats a finding’s code location as a separate engineering problem. This chapter follows a code_comment from the model’s existing-code snippet through deterministic matching, cross-file relocation, cautious filtering, and platform publication. The reader should be able to tell the difference between a finding that was not discovered, one that was discovered but could not be anchored, and one that was deliberately routed somewhere other than an inline comment.
That distinction continues OCR’s central division of labor. The agent supplies the interpretation: this change may mishandle an error, expose a secret, or break an invariant. OCR’s output pipeline checks whether the interpretation can be tied to code in the reviewed evidence and whether the resulting artifact can be delivered without pretending to know more than it does.
A code excerpt is evidence for a location
The code_comment tool does not ask the model to provide a bare line number as the final authority. A comment includes an existing_code snippet, the text of the concern, and optionally a suggested replacement, category, severity, and path. The snippet is the bridge between the model’s reasoning and the actual diff. If the model says that a newly added validation is wrong, it must identify the relevant code rather than merely naming a line it remembers from the prompt.
OCR first searches the new side of the diff. It looks for a consecutive run made from context and added lines and assigns the matching file line numbers. This is the natural path for a comment about newly introduced code. If that fails, OCR tries the old side using context and deleted lines. A deletion can still be the subject of a historical comment, but it needs the old-file coordinate system rather than the new one.
If neither hunk-side search succeeds, OCR can scan the full post-change file content for the snippet. This fallback is useful when the model selected code near the changed area but the exact excerpt was not represented inside the hunk. Matching is deliberately tolerant of whitespace and diff markers, because indentation or a leading + should not decide whether the evidence is the same. The search is still based on a concrete excerpt, not on a model-invented location.
The order matters. Hunk matching keeps the comment connected to the change under review. Full-file scanning provides more context but creates a wider search space, so it comes later. If a model paraphrases the code instead of returning a useful excerpt, the deterministic path may fail. OCR can then ask a relocation model to help, but that is a fallback after the system has exhausted evidence already present in memory.
Cross-file relocation handles a specific kind of bounded agent behavior. While reviewing one file, the agent may inspect another changed file for context and accidentally describe code from that other file in its comment. OCR can search the other reviewed diffs using the original excerpt. If there is exactly one match, it moves the path and the resolved line range together.