Which changes to a telemetry description break a generated consumer's build, and which regenerate silently?

## The compiler only sees the surface Generation reads the description and emits source **before** compilation; the compiler then checks the consumers against the emitted surface — the member names, their types, their arity, whether they must be supplied. That surface is the entire vocabulary of what a build can detect. Anything the description says that does not land in that surface is, to the build, a comment. This is why generating from a description is worth so much and why it misleads people who expect too much of it. It converts a whole class of change into a compile error, at the exact moment the change lands, in every consumer at once — and it converts another class of change into nothing at all. ## Changes that break the build Each of these alters something a consumer's code names or relies on structurally: - **A renamed member** — every reference to the old name fails, in every regenerated consumer. - **A removed member** — same, plus any exhaustive handling over a set of members. - **A changed type** — an assignment or an argument no longer fits, unless the new type happens to be accepted where the old one was. - **An optional member becoming required** — construction sites that omitted it stop compiling, if the generated constructor reflects requiredness. - **A member added to a closed set the consumer handles exhaustively** — where the emitted surface makes exhaustiveness checkable. The important qualifier: this is loud only for consumers that **reference** the changed member and are **regenerated from the new description**. A rename of a member nobody uses is silent by definition, and a consumer still building against the previous description learns nothing until it regenerates. ## Changes that regenerate silently These leave the surface byte-identical or structurally compatible: - **Units or scale** — a reading described in one unit now described in another, with the same member name and numeric type. - **Meaning** — a member that used to hold the moment a sample was captured now holding the moment it was received. - **A changed default** — the generated construction path supplies a different value and every call site compiles. - **A tightened or loosened documented range** — documentation travels into comments, not into checks, unless the generator emits validation. - **A new optional member** — nothing that compiled stops compiling. - **Which member is authoritative** when two overlap — a pure convention change. | Change to the description | Build reaction | Why | |---|---|---| | Rename a referenced member | Breaks | The emitted name no longer exists | | Remove a member | Breaks | References and exhaustive handling fail | | Optional becomes required | Breaks | Construction sites omit it | | Add an optional member | Silent | Nothing previously valid becomes invalid | | Change units or meaning | Silent | Surface is unchanged | | Change a default | Silent | Call sites compile identically | ## Making a silent change loud on purpose The technique worth being able to name in an interview is to **spend a surface change to buy a signal**: 1. **Rename rather than reinterpret.** If a member's meaning changes, change its name in the description. Every consumer breaks, each author is forced to look at the new meaning, and the fix is a deliberate edit rather than a silent behaviour change. 2. **Introduce, migrate, remove.** Add the new member alongside the old, move consumers over, then remove the old one — which breaks anything left behind, on purpose, at a time you chose. 3. **Make the invariant part of the surface.** If the generator can emit a distinct type for a unit, or a required discriminator, the compiler starts checking what used to be a note. This is the only durable fix, and it costs whatever expressiveness the description has. ## The limits of a build-time signal Be honest about what the break does and does not prove. It proves that every regenerated consumer's code was **adjusted** to the new surface; it does not prove that any of them was adjusted **correctly**, and it says nothing about data already in flight or already stored, which a compiler never sees. It also only reaches consumers that regenerate — which is the strongest practical argument for regeneration being an unavoidable part of every build rather than an occasional chore. So the shape of a good answer is: name the two classes, show that the boundary is the emitted surface rather than anything about intent, and describe how you deliberately move a change from the silent class into the loud one.