Claim boundary
Structure-aware code comparison evidence
This matrix distinguishes what a current AlignDiff result visibly surfaces from the decisions and conclusions that remain with the reviewer.
Transformation matrix
What the comparison can show
| Change | Observable AlignDiff result | Reviewer still determines |
|---|---|---|
| Function moved | A likely counterpart can remain paired with a moved or moved-and-modified status. | Whether calls, parameters, and behaviour changed appropriately. |
| Function renamed | A structurally similar counterpart can be shown as a possible rename pairing. | Whether it is the intended counterpart. |
| Statements reordered | Detailed rows can stay attached to the selected structure instead of cascading through source order. | Whether execution order matters. |
| Return changed | The paired structure remains visible while its detailed return change is shown. | Whether the new result is correct for relevant inputs. |
| New-only code | An inserted structure can remain one-sided rather than forcing an unrelated match. | Whether the new code is needed and correct. |
Observed product output
One fixture combines several signals
Inspect the worked checkout-refactor example or load the same fixture in the local comparator. The image records an observable result; it is not a claim about an arbitrary repository or pull request.
What the reviewer still decides
Evidence is not automatic approval
- AlignDiff does not prove behavioural equivalence or runtime correctness.
- It does not prove pull-request safety, dependency impact, or test completeness.
- It does not determine developer intent.
- It does not prove every automatic pairing is correct.
Use the visible pairing reasons and detailed changes as review evidence, then apply domain knowledge, tests, and appropriate human review.