When is a value correctly serialized, given that the reader reconstructs a new value rather than receiving the original?

## Correctness is a round trip, not a copy A decoder never hands back the original value. It builds a **new** value, in a different address space, at a different location, with the reader's own layout. So "did the serialization work?" cannot be answered by comparing memory. It is answered by a round trip: > Encode a value, decode the bytes, and the result must be indistinguishable from the original **by every observation the application makes of it**. That phrase does the work. "Indistinguishable" is relative to what the application looks at: the declared fields, compared under whatever notion of equality the type itself defines. Everything else — where it sits in memory, which padding bytes surround it, how much space it occupies — is not part of the value and is not part of the test. ## Two round trips, regularly confused There are two different claims, and they are not the same promise: 1. **Value round trip:** `decode(encode(v))` compares equal to `v`. This is the ordinary correctness bar, and it is what almost everyone means by "it round-trips". 2. **Byte round trip:** `encode(decode(b))` reproduces `b` exactly. This is a claim about the *bytes*, and it is the one you need before a payload can be hashed, signed, deduplicated or compared for equality without decoding. An encoding can satisfy the first and not the second. If two byte sequences decode to the same value — because a field could be written in either of two ways, or an absent field and a defaulted field decode alike — then re-encoding will pick one of them and the other will not come back. Whether an encoding promises a single byte form for a given value is a property of that encoding's design, and it is a design question in its own right; the point here is simply that assuming claim 2 because you have tested claim 1 is unfounded. ## The self-consistency trap The standard round-trip test runs the encoder and the decoder from **the same implementation**. What it can prove: - the implementation does not lose the values it was given; - the two directions are inverses *of each other*. What it cannot prove: - that the wire form is specified well enough for an independently written reader to agree; - that a reader built from a different description of the shape will reconstruct the same value; - that a value outside the tested range survives at all. A pair that is wrong in matching ways passes every such test. This is why an unreadable-by-anyone-else format usually ships with a green test suite: symmetry was verified, agreement was not. The stronger check is a **cross round trip** — one side encodes, an independently built side decodes, and the comparison is made on the declared fields. ## What is excluded from the check by design Not everything in a live value is supposed to survive. Anything that refers to a live resource of the writing process has no meaning on the other side and is deliberately outside the equality: - open handles and connections; - anything holding an exclusive claim on a resource; - entries that only make sense while a specific counterpart is alive. The round-trip check is therefore stated over the **declared** fields — the ones the wire contract says travel — and the excluded ones are re-established by the reader rather than compared. Stating that boundary explicitly is part of a good answer; silently comparing everything and then loosening the test when it fails is how the boundary ends up undefined. ## Where the equality itself goes wrong Two further ways a round-trip assertion lies: - **The wrong equality.** If the comparison uses identity rather than field-by-field equality, a correct decode fails; if it uses a loose equality that ignores a field, an incorrect decode passes. The test is only as strong as the notion of equality behind it. - **The unexercised range.** Round-tripping one well-formed example says nothing about empty collections, the extremes of a numeric range, absent optional fields, or text outside the common cases. Correctness claims live or die on the edges, and a round-trip test only covers the values you actually fed it. ## What an interviewer is checking The short answer they want is *round-trip equality over declared fields, not image identity*. The follow-up they are really waiting for is whether you know the test's limits: that same-implementation symmetry is not agreement, and that byte-identical re-encoding is a separate promise you must ask for rather than assume.