AI Wisdom
🪷Proof Tale V

The Agreement Between Merchants

A Panchatantra fable about Contract Testing

📖
Story · +20 XP
8 min read · 6 sutras
🎭 The Cast
  • GrahiThe consumer merchant — receives goods and specifies exactly what form they must arrive in
  • PurakThe provider merchant — supplies the goods and must honour every consumer's specification
  • SandhaThe contract keeper — holds the binding agreement between consumer and provider
  • MadhyasthaThe broker — the neutral party who verifies both sides honour the contract
6 sutras~8 minWith reflectionMaps to RAG concepts
Begin the tale
Sutra Pratham
1
Scene 1 of 6

The Broken Shipment

Grahi the consumer merchant placed a standing order with Purak: deliver grain every week in twelve-kilogram sacks, with the weight stamped on the outside. For three years this worked. Then Purak's warehouse adopted a new measuring system — metric for internal efficiency. The twelve-kilogram stamp became a "12.0 kg" stamp with a decimal. Grahi's receiving machine, which read the stamp to sort the sacks, broke on the decimal. Both merchants had done nothing wrong. Purak had improved efficiency. Grahi had not changed anything. But the implicit agreement between them had been violated without either of them realising it, because there was no explicit, binding, tested agreement. Only habit.

⚜ The Moral ⚜
An implicit agreement is broken silently. A contract is broken loudly, before the shipment leaves the warehouse.
Sutra Dwitiya
2
Scene 2 of 6

The Consumer Writes the Contract

Sandha the contract keeper proposed a new system. Grahi would write down precisely what she needed from each shipment: the weight field must be an integer, not a decimal; the sack must carry a "quality" field with one of three values; the timestamp must be in the market's local calendar format. This document was the contract — not a wish, but a verifiable specification of what Grahi needed to function. Sandha would publish the contract to the broker. Purak would be given the contract and asked to verify that his warehouse could honour it before any shipment was prepared. If Purak's new metric system violated the integer rule, Sandha would know this before the sacks were loaded — not after they arrived at Grahi's machine.

⚜ The Moral ⚜
In consumer-driven contract testing, the consumer defines what it needs. The provider verifies it can honour those needs.
Sutra Tritiya
3
Scene 3 of 6

The Broker's Verification

Madhyastha the broker held copies of every contract from every consumer who ordered from Purak. There were nine consumers, each with their own contract. Some required integer weights. Some required decimal weights. Some required a provenance field that others did not need. Before Purak changed anything in his warehouse — a new format, a new field name, a removed field — Madhyastha ran each contract against the proposed change. If all nine contracts were satisfied, the change was approved. If even one contract was violated, Madhyastha returned the change to Purak for correction. Purak never deployed a change that broke a consumer. Not because Pukar was careful — but because the broker made it impossible to succeed without satisfying the contracts.

⚜ The Moral ⚜
The broker (Pact Broker) verifies provider changes against all consumer contracts. Breaking changes are caught at the provider, not discovered by consumers.
Sutra Chaturtha
4
Scene 4 of 6

The Contract That Tested Nothing Extra

An apprentice asked why the contracts were so narrow. Grahi's contract required only three fields, but Purak's warehouse produced twelve. Why not test all twelve? Sandha explained: "Grahi depends only on three fields. If Purak adds a thirteenth field, Grahi is unaffected — and should not block the addition. If Purak renames a field Grahi does not use, Grahi is unaffected. The contract covers only what the consumer uses. A contract that covers everything Pukar produces makes every change to the provider a contract violation. That is not a safety net — it is a cage." The narrow contract was intentional. It gave Purak freedom to evolve anything the consumers did not depend on.

⚜ The Moral ⚜
A contract tests only what the consumer uses. Over-specifying freezes the provider and defeats the purpose of the contract.
Sutra Pancham
5
Scene 5 of 6

The New Consumer

A tenth consumer, Nava, wished to order from Purak. Nava needed a freshness field that no existing consumer had requested. Before Purak built the new field, Nava wrote her contract — including the freshness field — and submitted it to Madhyastha. Madhyastha ran all ten contracts against Pukar's current warehouse. Nine passed. Nava's failed, because the freshness field did not yet exist. This was the signal for Purak to add the field. Once added, all ten contracts passed. Nava received her first correct shipment the next morning. The development of the new feature was driven not by a prose requirement but by a failing contract: a precise, testable claim that a real consumer would make.

⚜ The Moral ⚜
A new consumer contract drives provider development. The failing contract is the requirement.
Sutra Antim
6
Final scene

The Freedom of the Verified Contract

After two years under the contract system, Purak's warehouse underwent a major reorganisation — a complete rewrite of the internal routing system, a new measurement system, and a new storage format. In the old days, this reorganisation would have required months of coordination meetings with all nine consumers, manual verification of every integration, and a weeks-long freeze while the change was tested. Under the contract system, Purak reorganised the warehouse, ran Madhyastha's verification, and — because all ten contracts passed — released the reorganisation without a single consumer being consulted. The contracts were the coordination. The broker was the meeting. The release was the outcome.

⚜ The Moral ⚜
Verified contracts enable independent deployment. Both consumer and provider can evolve as long as the contract remains honoured.
💡

🪔 Deepak — the lamp of meaning · what this fable means in code

Contract testing verifies that a consumer and provider can communicate correctly — without requiring both to be running simultaneously. In Pact, the consumer writes interaction tests: "when I send this request, I expect this response shape." Pact records these as a contract (a JSON pact file). The provider runs the pact against its real implementation using a Pact Verifier. The Pact Broker stores and serves contracts, enabling can-i-deploy checks: "can provider version 2.3.0 be deployed knowing that consumer version 1.4.0 is in production?" Consumer-driven contracts prevent the over-specification problem: only the fields the consumer actually uses appear in the contract, leaving the provider free to evolve everything else. Pact supports synchronous (HTTP) and asynchronous (message) contracts. The workflow integrates into CI: consumers publish updated contracts on merge; providers run verification on every change; can-i-deploy gates the release.