Your `orders-api` has three consumers owned by other teams: a mobile app, a web front end and a billing service. Pact is in place: consumers publish pacts to a broker and your build runs provider verification. Last month a field removal still reached production and broke the mobile app. Explain what provider verification actually checks, what provider states cost, how the break could get through, and how you would make the broker the thing that stops a deploy.

A pact is not a recorded response to match byte for byte. For each interaction it records the request and, for each field the consumer reads, a matching rule (this field is present and is a number, this one is a string). Provider verification replays each request against your real, running provider and checks the real response against those rules, so fields no consumer reads can change freely and removing a field breaks exactly the consumers who read it. Provider states (@State("order 42 exists")) are code on your side that puts the provider into the situation the interaction assumes; the pact never says how. A break can reach production when the check is not what gates the deploy: verification ran against the wrong consumer versions, failed on a branch nobody blocked on, or the release was never compared against what is live. can-i-deploy closes that: before deploying version X, ask the broker whether X has been verified against every consumer version currently deployed, and block if not.