Several record schemas in a registry reference one shared type by name and version. What does changing that shared type require?

Shared types are how a registry stops being a pile of unrelated documents and starts being a model — and they are where most of its surprising behaviour lives. ## What a reference is A referencing schema does not embed the shared definition. It records a **dependency edge**: this local field has the type defined by *name X at version N*. Resolution happens at registration and at read time by following that edge to the stored document. The critical property is that the edge is **pinned**. It names a version, not 'whatever is current'. If it named the current version instead, every referencing contract would change silently whenever the shared type's owner shipped anything — which is precisely the outcome the registry exists to prevent. ## What editing the shared type actually does 1. The edit is submitted under the **shared type's own name** and checked against **that name's** history, under **that name's** mode. 2. On acceptance, a new version of the shared type exists. Nothing else has changed. 3. Each referencing schema still resolves its pinned version and behaves exactly as before. 4. A dependant adopts the change only when its owner re-registers the referencing schema with the edge moved to the new version — and that submission is checked against the **referencing name's** history. Step 4 is the one candidates miss. The shared type's green verdict is about the shared type alone. ## Why the shared type's own check is not enough The registry compares documents under one name. When the edge moves, the *effective* shape of the referencing record changes, and only the referencing name's own check can say whether that shape still relates correctly to its predecessors. An edit can be perfectly acceptable within the shared lineage and still break a dependant, because the two names may carry different modes, and because what counts as a safe edit depends on the surrounding record, not only on the fragment. | Action | Checked against | Tells you | |---|---|---| | Register a new version of the shared type | The shared name's history | Whether the shared type evolved acceptably | | Move one dependant's edge to it | That dependant's history | Whether that record still relates to its own past | | Nothing | — | Whether the other dependants are fine (they are unchanged, and unmigrated) | ## Fan-out and ownership A type used by forty schemas has forty owners who each decide when to move. That is a feature — it is staged migration rather than a flag day — but it has costs a lead should say out loud: - The shared name has **more dependants than any single stream**, so its effective blast radius is larger than its traffic suggests. It deserves stricter rules and a named owner, not the loosest settings in the registry. - The estate lives at **mixed versions indefinitely**. Any tool reasoning across records must cope with several versions of the same shared type being live at once. - 'Just add a field to the shared type' is a **cheap edit with expensive follow-through**: N reviews, N deploys, N rollouts, spread over whoever gets to it. ## Deletion and dangling edges Removing a version that something still pins breaks resolution for that dependant — the edge points at nothing, and a reader or a re-registration fails. Two disciplines follow: a version may not be removed while any edge references it, and the registry must be able to answer 'what references this?' before anyone tries. A registry that cannot answer that question has shared types in name only. ## The interview summary A reference is a pinned edge. Editing the shared type creates a version; **adopting** it is a separate, separately-checked act per dependant; deleting a pinned version is the one destructive operation in the model.