How would you run one Pact Broker across many teams without `can-i-deploy` becoming a rubber stamp?

## The failure this is guarding against A contract gate does not usually die by being switched off. It dies by continuing to answer while the facts behind it quietly stop being true. Nobody notices, because the answer is still green, and green is what everyone was hoping for. On a depot fleet running a release train that cannot slip, this is the outcome to design against: a check that everybody runs, nobody trusts, and one team has already learned to route around. The broker is a record of assertions teams make about themselves. It has no independent way to observe a deployment, so its usefulness is exactly the discipline of the records feeding it. ## What is mandatory 1. **Publish on every build, under the artefact's identity.** The application version is the commit sha of the thing that will be deployed, with the branch set. Publishing under a moving label destroys the join key and makes every later answer meaningless while looking fine. 2. **Publish verification results on every verification run, including failures.** A missing result and a failing result are different facts, and only one of them means somebody looked. 3. **Record the deployment from the deployment automation.** Not from a follow-up job someone can skip, not manually, not on Fridays. If the pipeline step that deploys does not also record it, the broker's belief about the environment starts drifting from the first hotfix onwards. 4. **Fail the deploy on the answer.** The exit status gates the job. If the pipeline swallows it, the whole apparatus is a logging framework. ## What teams may reasonably opt out of - **Scope.** Not every application needs contracts. An internal service with one consumer inside the same team gets little from the ceremony. Define scope by the boundary that matters — contracts between teams — rather than mandating every repository. - **Webhook-triggered verification.** Fast feedback is valuable but it spends provider build capacity, and a provider team may prefer verifying on its own pipeline cadence. - **Immediately-blocking new expectations.** A consumer that adds an expectation the provider has not agreed to should not be able to redden the provider's build on day one. Letting a new expectation be recorded and reported without failing that build is what makes onboarding a new consumer politically possible. - **Which environments are gated.** Gating production is non-negotiable; gating a scratch environment usually is not. ## How the gate actually gets bypassed | Bypass | How it looks | What it does to the answer | |---|---|---| | Deployment not recorded | Everything green | The check compares against versions that left production weeks ago | | Version string is not the artefact's | Green, always | The answer is about a version nobody deployed | | Exit status swallowed in the pipeline | Green, always | The gate is a print statement | | Blanket exclusion of an application from the check | Green for that pair | One team has quietly left the scheme | | Everything permanently unverified-but-tolerated | Green | Nothing is ever actually enforced | | Check runs after the deploy | Red, sometimes | Too late to prevent anything | What these share is that they all look like success. That is why a broker rollout that only measures adoption — how many teams publish — measures the wrong thing. ## What to measure instead - **Recorded deployments versus real deployments.** Compare the broker's environment records against the deployment system's history. A persistent gap is the single most damaging drift, because it makes wrong answers confident. - **Rate of unknown answers.** Rising unknowns mean verification is not running or not publishing, and unknowns are what teach people to add retries and then to ignore the gate. - **Age of the counterpart versions the check is comparing against.** If production has apparently been running the same provider version for four months, either it has, or nobody has recorded a deployment since. - **How often the gate actually blocks something.** A gate that has never blocked anything in a year is either superfluous or broken, and it is worth knowing which. ## The organisational stance Two positions are defensible and they trade off differently. **Mandate narrowly and enforce hard**: a small set of cross-team contracts, gated absolutely, with no per-team exemptions — high trust in the answer, slower onboarding, and pressure to grant exceptions that erode it. **Invite broadly and enforce where it is earned**: many participants, gating only pairs where both teams have opted in and are publishing results — better adoption, but you must be able to say precisely which pairs are genuinely gated, or people will assume all of them are. The position that does not work is mandating broadly and enforcing softly, because it produces the appearance of a gate everywhere and the substance of one nowhere. Whichever you choose, the thing to protect is the meaning of a green answer: it should always be worth exactly what a team assumes it is worth, and the moment it is not, that is a defect to fix rather than a warning to add to the runbook.