the tolerance that was wrong in both directions

A protection level was attached to an open position and then read back to confirm it had landed. The read-back compared the level the system had sent against the level the counterparty reported, and demanded that the two be equal. The counterparty stores levels rounded to a fixed number of digits, so the two could not be equal. The confirmation failed on work that had succeeded, and the failure path removed the protection it had just placed.

The repair compared at the precision the counterparty actually publishes, with a deliberately strict fallback wherever that precision is unknown. The obvious lesson is that equality belongs at the interface's resolution rather than at the client's. The less obvious part is that the same comparison had already failed once in the other direction: the tolerance in the neighbouring path was loose enough that a materially wrong level passed as correct. Too tight, and protection was deleted. Too loose, and a wrong level was blessed.

Both paths were replaced by one shared comparison, and the reasoning behind it is the part worth recording. A tolerance is not a safety margin to be tuned until the tests go green. It is a claim about the resolution of the party you are talking to, and it has to be justified from that side of the wire, where the rounding happens.

What it proves: they diagnose the direction of an error before they adjust the number, and they treat exactness as something owed to a contract rather than to a habit.