What does a runtime's built-in object-graph serializer put on the wire that a hand-written field-mapped encoding does not?

## Two ways a value becomes bytes When a value has to leave memory — into a cache, a queue, a file, a socket — something must turn the live graph of objects into a flat sequence of bytes. There are two families of answer. The first is a **field-mapped encoding**: you decide which fields travel, under which names, in which representation. That decision lives somewhere explicit — hand-written mapping code, or a schema that generates it. The encoder knows nothing about your types; it knows about the fields you handed it. The second is a **native object-graph snapshot**: you hand the runtime's built-in serializer a root object and it walks everything reachable from that root, writing each object it meets. You write no mapping and declare no schema. The type declarations in your source code *are* the schema, implicitly. ## What the snapshot stream actually carries - **Type identity, inside the payload.** Each record names the type to rebuild. The name is usually qualified, and such formats commonly pair it with a **shape token** — a hash or a declared number derived from the type's fields — so a reader can tell whether its local declaration matches the one that wrote the bytes. - **Every reachable field, by default.** Public and private alike. Exclusion is opt-out: these serializers generally offer a per-field marker that keeps a value out, but the default is that a field travels because it exists, not because anyone decided it should. - **Derived and cached state.** A memoised total, a cached hash, a lazily built index — these are fields, so they are written, carrying the values they happened to hold at snapshot time. - **The shape of the graph, not only its values.** An object reached twice is written once and referred to afterwards by a back-reference, so sharing survives the round trip and cycles terminate instead of looping forever. - **Nothing about meaning.** There is no field documentation, no declared optionality, no version negotiation, no media type a stranger could look up. A reader is expected to *be* the same code. ## Side by side | | Native object-graph snapshot | Field-mapped encoding | |---|---|---| | What travels | the whole reachable graph, all fields | only the fields you declared | | Type information | embedded in the payload | in the schema or the reading code | | Who can read it | the same types, in the same runtime | any reader that knows the format | | Authoring cost | effectively zero | a schema or mapping code to write | | Change control | implicit — it follows the code | explicit — it is reviewed | | Sharing and cycles | preserved by construction | preserved only if you model them | ## Why the convenience is real It is worth being honest about the appeal, because dismissing it makes the trade-off invisible. A native snapshot costs one call. It cannot drift from the types, because there is nothing to drift: no mapping file that someone forgets to update when a field is added. It captures things a hand-written mapping usually gets wrong — shared substructure, cyclic references, exact collection and numeric representations, state that has no accessor at all. For a checkpoint written and read by the same build inside one process boundary, that is a genuinely good deal. ## What you pay for it 1. **The wire contract becomes the code's shape.** Renaming a type, moving it, or changing its field set changes the format. Nobody reviews that as a format change, because it does not look like one — it looks like a refactor. 2. **Lock-in to one runtime.** Reconstruction semantics — how a type name resolves, what order fields load in, which hooks run during the rebuild — are the writing runtime's private business. Another ecosystem can walk the bytes but cannot honour the rebuild contract, so in practice the payload is unreadable outside its origin. 3. **The decode path constructs whatever the payload names.** Rebuilding is not parsing into a plain record: it resolves the types named in the bytes and runs their reconstruction machinery. That is why this family stays strictly inside a trust boundary — the decision about which types get built has already been handed to whoever wrote the bytes. ## The practical rule Treat a native snapshot as an in-memory value that has briefly taken a byte shape, not as a document. If the bytes will cross a version boundary, a language boundary, or a trust boundary, this family is the wrong one, and an explicit encoding — text or schema-driven — is what the situation is asking for.