How do you govern schema flexibility when many teams write to the same document collections?

## The failure this prevents The pathology is familiar. A collection starts clean. Three teams write to it. Each adds the field it needs, using its own naming convention. Nobody owns the shared core, so nobody objects. Two years later the collection holds four overlapping representations of the same concept, every read path has a fallback chain, the analytics team maintains a private mapping table, and no one can answer "what is guaranteed to be in one of these documents?" without running a query. Nothing in that story was a bad decision in isolation. It is the absence of a governing rule, and the absence is invisible until the cost is already sunk. ## Ownership first Governance without an owner is a document nobody reads. The workable model: - **One team owns each collection.** They define the stable core, approve non-additive changes, and are on the hook when the shape degrades. - **Other teams' access is a contract, not an invitation.** Ideally other teams read through an API or a published, versioned contract rather than querying the store directly. Where direct reads are unavoidable, the owner publishes what is guaranteed — and equally important, what is *not* guaranteed and may change without notice. - **Shared-write collections need an explicit answer.** If several teams genuinely must write, decide which fields each may own, and forbid whole-document replacement so no writer can erase another's fields. ## The rules of change Make the asymmetry explicit, because it is what buys autonomy: - **Additive change is unilateral.** Adding a new optional field, or a new variant of a polymorphic document, needs no permission — provided consumers are tolerant readers. - **Non-additive change is coordinated.** Renames, removals, type changes and changes of meaning affect every consumer and go through the owner. Changes of meaning are the most dangerous: no automated check catches a field that keeps its name and type and starts meaning something else. - **The stable core changes slowly and visibly.** Everything outside the core is free. ## Layered enforcement Put each check where it is cheapest and most informative: **Build time, in each producer.** Types and contract tests in the producing service's pipeline. This is the fastest feedback and the only layer that can fail before anything reaches production. Its weakness is that it only covers code paths that have a pipeline. **Write time, in the database.** A narrow check on the core — required fields, their types, closed value sets. It catches every writer including scripts, imports and manual fixes, which is exactly the population that produces surprises. Keep it narrow, because a collection-wide rule is a commitment to all past and future documents. **Continuously, by observation.** A sampling job that reads a slice of each collection and reports, per field, how often it is present and which types it holds. This is the layer teams most often skip and the one that turns governance from an aspiration into a measurement. It tells you which of your declared rules are actually true. ## Governing the escape hatch Most systems eventually need a place for genuinely open, per-customer or per-integration data. The disciplined version is a single nested sub-object — `attributes`, `extensions` — that is explicitly declared as unstructured. The governing rules for it: it is namespaced by writer so two teams cannot collide, nothing in the core ever depends on it, and if a field inside it becomes something the product queries or reports on, that is the trigger to promote it into the governed core. An escape hatch that quietly becomes load-bearing is worse than no escape hatch, because it carries none of the guarantees people have started to assume. ## Proportionality Not every collection deserves the same machinery. Grade by blast radius: - A collection read by one service and nothing else: types in that service, no ceremony. - A collection read by several services or feeding reporting: owner, published core, write-time check on the core, drift sampling. - A collection whose shape appears in customer-visible exports or partner integrations: all of the above, plus human review of core changes, because your consumers include people you cannot redeploy. Applying the heaviest process everywhere is how governance loses credibility and gets routed around. ## What interviewers listen for At this level nobody is looking for a tool recommendation. They want to hear ownership named as the primitive, the additive-versus-non-additive asymmetry stated as the rule that preserves team autonomy, enforcement described as layers with different coverage rather than one gate, and — the detail that separates experience from theory — a plan to *measure* the real shape of stored data rather than assuming the code is the truth. Mentioning proportionality, so that low-risk collections stay unencumbered, shows the judgment that keeps such a policy alive.