Two gaps a review found by reading the artifacts rather than the prose. An ambiguity row's origin_keys entries are serialised with ASCII escaping left on, inside a row that is raw UTF-8 -- two encodings in one line. Both rows carried pure-ASCII origins, so that difference was invisible and a reimplementation could get it wrong with nothing going red. Getting it wrong duplicates an origin instead of matching it, and the duplicate appends to both lists so the same-length rule stays satisfied and the row grows without bound. One origin is now non-ASCII, and both encodings appear in one line of real bytes. And a note on inputs, because their key order is not the artifacts' key order: this file is serialised with sorted keys, which normalises away the insertion order the identity file and the ambiguity rows preserve on disk. Re-serialising an input yields alphabetical keys and will not match the artifact. That is the corpus format, not a defect, and the note says which oracle to use for a byte comparison -- the artifact is its own.