Would you publish prebuilt generated stubs from a contract repository, or have each consuming team generate from the IDL at build time?

## What is actually being decided Both models agree that the contract is the source of truth and that stubs are generated from it. What is being decided is **where generation runs and who owns its inputs** — and, through that, whether uniformity or team autonomy is the property the organisation optimises for. It is a genuine judgment call: both models are in wide use and neither is a mistake. ## Central publication of stub artefacts **What it buys** - One generator version and one set of options, so every consumer's generated semantics match. - No toolchain requirement on consumers: a team adds a dependency and is finished. - A single place to see who depends on which contract version, because dependency resolution is the record. - Hand-editing is structurally impossible; consumers never hold the generated source. - One review of the generated diff when the generator is upgraded, rather than N discoveries. **What it costs** - The contract repository must own a build and release pipeline **per ecosystem** it supports, including the packaging conventions of each — real, recurring work. - It becomes a bottleneck: adding an ecosystem, or changing a generation option for one consumer, is a change to a repository several teams share. - Its release cadence couples teams. A consumer that needs a fix waits on the contract repository's release. - The owning team must carry expertise in ecosystems it does not otherwise use. ## Consumer-side generation **What it buys** - The contract repository publishes exactly one thing: the contract. Its scope stays small and its expertise stays narrow. - Each team controls generation options, output layout and the timing of a generator upgrade. - Adding a new ecosystem costs the contract repository nothing. **What it costs** - Generator versions and options diverge, so two consumers can behave differently while claiming the same contract version — the hardest class of inconsistency to diagnose. - Every consuming team needs the toolchain in its build, which is a per-team cost paid repeatedly. - There is no single registry of who is on which contract version; you must ask. - A generator upgrade's consequences are discovered N times independently. ## How to decide | Factor | Leans central publication | Leans consumer-side generation | |---|---|---| | Number of ecosystems | few and stable | many, or changing often | | Required uniformity of semantics | high (money, regulated records) | moderate | | Platform capacity | a team exists to own pipelines | no such team | | Contract change rate | low to moderate | high, with impatient consumers | | Auditability requirement | must answer "who is on what" from records | can answer by asking | | Consumer maturity | uneven across teams | uniformly strong build practice | A defensible answer in an interview names the hybrid, because most organisations land there: **publish for the two or three ecosystems that carry most consumers, and support consumer-side generation for the long tail**, while keeping generation reproducible and the generator version pinned in both paths. The properties worth refusing to trade away are the same in either model — the contract is published as a versioned artefact in its own right, every stub carries the contract and generator versions it was built from, and generation is reproducible from those two inputs alone. ## The failure mode of each, stated plainly Central publication fails as a **queue**: the contract team becomes the constraint, consumers route around it by generating locally anyway, and now you have both models with none of the guarantees of either. Consumer-side generation fails as **divergence**: an incident where one consumer's behaviour differs from another's and the first hour goes to establishing which generator built which service. An interviewer at this level is listening for whether you can state the failure mode of the option you chose, and what you would watch to see it arriving — queue time on contract releases in the first case, a census of generator versions across consumers in the second.