@CadeRoux select checksum(10.0), checksum(1.0). Oops.

Exactly this caught me in production a few years ago. A data provider put the decimal point in the wrong place. The corrected file wouldn't load because checksum said there were no changes. I re-wrote to use HASHBYTES, IIRC.

@MichaelGreen I have a collision self-test in most places where I use CHECKSUM. And in those places, it's best to use CHECKSUM because I need to be case-insensitive. However, I know I don't have a collision self-test on this column, and I'm not sure where I used it before. It's not in the data mart itself but in the database that contains all the tests and which is used to self-test the data mart.

The big problem is that it's something I can't retroactively change

I mean I can, but then I am testing data that is not exactly the data representing the old build.

I have to present build summary that shows where a rule has changed from historical build to present build, which is a pain when rules have no identifier that is guaranteed to stay the same build to build.

XML blobs are necessary to be able to summarize them into fewer tables, hence the checksums. I see a lot of casting XML to nvarchar(max) and comparing for equality in the near future.

Luckily, the hashes are computed columns, so I could slap new hashbytes ones on the old rule build summary tables and it would not be considered that invasive.

Case changes (like Valve Stenosis -> Valve stenosis) on a rule would then likely be considered changes now. But you can't have everything.