All current best practices about creating and using cryptographic keys I've found, refer to creating an encrypted data out of raw data. However, there is (or at least was a few decades ago) a practice where a key is not used to decrypt or authenticate anything, it is used solely locally as a (very week) proof of ownership.
In the pre-internet days, when you bought a software, you got it on a physical media (floppy disk or CD) and there was a "key" physically printed on it, which you had to enter during installation. No internet connection was needed, there was no server which authenticated anything or checked whether the key has already been used. The installer only checked whether the key conformed to some rules which could distinguish valid keys from invalid ones.
Anyone could just copy the key from a legitimate owner and install the software without authorization, there was nothing preventing this practice, but such keys were still used because not everyone was doing it, therefore it prevented at least some part of the userbase from pirating it.
If done today, in a completely offline environment, how should such a key be ideally created? It should not be overly long, so that it can by typed in manually during installation, and there should still be millions of possible combinations. Yet it should be very unlikely that a small random change in a valid key results in another valid key.
A naive approach would be that half the bits of the key are a predetermined secret constant, the other half are random, but they are intermixed according to some logic, and a checksum is intermixed as well. Still workable for the intended purpose, and it was likely widely used. However, are there any modern, better approaches for creating such "offline installation keys"?