You're responsible for governance across eight teams sharing a microfrontend platform, including a shared design-tokens package and a set of custom event contracts. What governance mechanisms would you put in place to stop a shared contract or token change from silently breaking someone else's microfrontend, and what does that governance cost you in return?

## Why scale changes the problem qualitatively Governance at multi-team microfrontend scale exists to solve a problem that gets qualitatively worse, not just linearly worse, as team count grows: with two teams, an informal Slack message about a contract change is a survivable process; with eight teams, each independently deploying, the number of pairwise dependencies that can silently break grows combinatorially, and no individual team has visibility into the full graph of who depends on what. The governance mechanisms below aren't about adding bureaucracy for its own sake — each one directly targets a specific way silent breakage happens at this scale, several of which were named as separate failure modes earlier (payload drift, ownerless shared code, unknown consumers). ## The four mechanisms 1. **The first and most foundational mechanism is a contract registry:** a single, queryable source of truth listing every published contract (event schemas, prop shapes, token package versions) alongside which team owns the producer and which teams are known consumers. Without this, "who depends on this event" is tribal knowledge scattered across Slack history and individual engineers' memory — the exact condition that let the "unknown consumer" gap in contract testing go unnoticed for six months in the earlier scenario. The registry doesn't have to be exotic tooling; even a well-maintained schema package with required metadata fields, enforced by CI, can serve this purpose at eight-team scale, though larger platforms often invest in a dedicated service (a Pact broker or internal equivalent). 2. **The second mechanism** is making consumer-driven contract testing *mandatory* rather than best-effort, specifically gated at two points: before a producer deploys a change (verify against all registered consumer contracts, as discussed earlier), and before a new consumer's first deploy (they must publish a contract and register in the system before they're allowed to depend on someone else's fragment). This second gate is what closes the "unknown consumer" gap structurally instead of relying on every team remembering to announce themselves — onboarding becomes the enforcement point rather than an optional courtesy. 3. **The third mechanism** is an enforced (not merely documented) versioning and deprecation policy — the semver-style additive/breaking distinction and dual-emit/telemetry-gated-retirement pattern discussed earlier, but with teeth: CI can mechanically check whether a proposed change to a published schema is additive or breaking (schema diffing tools can do this automatically for many cases) and require a recorded deprecation plan — reviewed by the platform team — before a breaking change is allowed to merge, rather than trusting each team to remember and follow the policy voluntarily. 4. **The fourth mechanism** is explicit ownership of genuinely cross-cutting shared artifacts — the design-tokens package, any shared component library, cross-fragment auth/session contracts — assigned to a platform or design-system team rather than left as "everyone's repo," which was named earlier as a distinct failure mode (shared ownership erodes quality and accountability). This team's job includes reviewing proposed changes to shared tokens/contracts for cross-team impact, running the versioning policy on the platform's behalf, and being the accountable party when something shared breaks. ## What the governance costs The cost side of this is where governance conversations often go wrong by only counting the benefit (prevented incidents) and undercounting the cost, so it's worth being concrete. - **Process latency on every shared change.** Every shared change now carries process latency that a single-team change doesn't: registering a new contract, waiting for contract-test verification, potentially planning and executing a deprecation window instead of just shipping — this is a genuine velocity cost for the producing team, not a hypothetical one, and teams will feel it as friction, especially teams used to the "just ship it" speed the architecture originally promised them. - **Heavier onboarding.** Onboarding a ninth team means they inherit mandatory registry participation and contract-test setup before their first deploy, which is real ramp-up overhead compared to a lighter-weight, ungoverned setup. - **A standing organizational cost.** And the platform/governance team itself is a standing organizational cost — dedicated engineers whose primary output is infrastructure and review rather than customer-facing features, whose value shows up as incidents that *didn't* happen, which is inherently harder to justify in a roadmap review than a shipped feature. Under-invest and you get the silent-breakage failure modes across all eight teams' worth of pairwise dependencies; over-invest and you recreate exactly the coordinated-release-train friction microfrontends were adopted to escape, just relocated into a mandatory review-and-registry process instead of a release calendar. ## Calibrating strictness to blast radius Getting the balance right in practice usually means calibrating governance strictness to blast radius: a shared design-token color value affecting all eight teams' visual consistency warrants mandatory review and a platform-team gate; a narrow, two-team event contract between adjacent fragments can reasonably be lighter-weight (contract tests, but no platform-team sign-off requirement) since the blast radius of getting it wrong is smaller and the two teams can coordinate directly. Platforms operating at this scale in practice (large e-commerce, media, and travel companies running many independently-owned frontend teams) generally converge on exactly this tiered model — heavier governance for wide-blast-radius shared contracts, lighter governance for narrow point-to-point ones — rather than applying uniform maximum rigor everywhere, precisely because uniform maximum rigor reintroduces the coordination tax the architecture exists to eliminate.