Make agreement mean something

Two implementations agreeing proves they satisfy a prespecified contract. It does not prove either is correct, and it never validates the method or its assumptions. Both can be wrong in the same way — especially when one was written by reading the other. Design the comparison so that agreement is informative and disagreement is legible.

Rule: freeze before you compare; test the comparator before you trust it.

1. State the claim and the reference

Write down: what is being compared, which side is the reference, and what agreement would and would not establish. "Matches the R package" is a conformance claim, not a correctness claim. Say so explicitly, so nobody later reads parity as validation.

2. Freeze the inputs before inspecting anything

Record and fix: data versions or hashes, code and package versions, random seeds or realized sample splits, options and defaults, the outputs to be compared, and the acceptance thresholds. Freezing after a first look invites tolerance drift toward whatever the run produced.

Do not compare defaults across systems as if only the language changed. Map the choices explicitly — a "default" is a substantive modeling decision that usually differs between implementations.

3. Declare tolerance classes, and make them binding