Your Pact consumer expectation lists every field the provider returns. Why is that a problem?

## The expectation is the obligation In a Pact consumer test, the expected response body you write is not documentation and not a sample. Every path in it becomes something the provider is checked against during verification: literal paths by equality, matched paths by their matcher. So the question "what should the expected body contain?" is really the question "what do I want to make it impossible for the provider to change?" Pact's body matching is deliberately asymmetric, and the asymmetry is the whole design: - A field **present in the expectation and missing from the response** fails. - A field **present in the response and absent from the expectation** is ignored. Extra data does not fail matching, because the contract records one consumer's needs, not the provider's schema. That second rule is what makes consumer-driven contracts composable: five consumers can hold five different, partly overlapping expectations of the same endpoint, and the provider satisfies all of them by satisfying the union. ## What the two mistakes cost | Field | In the expectation? | Provider changes it | Result | |---|---|---|---| | Client reads it | yes | removed or retyped | verification goes red — correct, this would have broken you | | Client reads it | no | removed | verification stays green, production breaks — a false negative | | Client ignores it | yes | removed or retyped | verification goes red for a change that cannot affect you — a false positive | | Client ignores it | no | anything | provider free to change, nothing to explain | The bottom-right row is the point of the technique. A contract that lists only what is consumed gives the provider a precise, and usually surprisingly large, area of freedom. ## How the wide expectation happens Nobody writes forty fields on purpose. It happens by pasting a real response captured from the running provider into the expectation, because that is the fastest way to get a passing test. In a musical-instrument rental product, a `rental-web` client that needs three fields off `GET /rentals/{id}` — the rental id, the instrument sku and the return date — pastes the whole 41-field payload. Nothing is wrong that day. Two months later the provider team removes two fields nobody consumes, and the 6-minute verification job goes red. Under a regulator's change-record requirement, every red build on a release path has to be investigated and written up, so a change with no consumer impact costs a diagnosis, a cross-team conversation, a consumer-side edit and a record. Do that three times and the contract's credibility is spent: the next genuine red build is assumed to be noise too. ## Deciding what goes in Derive the list from the code, not from the payload: 1. Start from the client's **deserialisation target** and the code paths downstream of it. What does the mapper actually bind, and what does the caller actually read? 2. Keep the fields required for deserialisation to succeed at all — if the mapper fails on a missing non-nullable field, that field is consumed even when no branch reads it. 3. Drop everything else. Not "match it loosely" — drop it. A type matcher on a field you never read is still an obligation to keep sending it. 4. For each surviving field, choose strictness by use: type matching for values you pass through, value or regex matching for values you interpret. 5. Add a field in the **same change** that starts reading it. A pact is a record of current consumption, not a wish list; a field added for next quarter constrains the provider for a quarter in exchange for nothing. ## The judgement, and its limits The discipline is easy to state and awkward in practice, because the pressure runs the wrong way. Adding a field feels safe and costs the consumer team nothing today; the cost lands on another team's release later, as a red build they cannot explain. Reviewing consumer pacts as cross-team-cost changes — a diff to the expectation is a diff to somebody else's freedom to refactor — is what keeps the file honest. It also has a real limit worth saying out loud in an interview. A narrow pact tells the provider which fields at least one consumer needs; it never tells anyone the endpoint is safe to change for a consumer that has no pact at all. The technique's guarantees stop at the set of participating consumers, which is why coverage across consumers matters as much as precision within one.