GUIDE / CONTRACT
Make cross-boundary behaviour explicit.
A BOUND contract is broader than a type signature. It captures the assumptions that independent implementations must share.
Minimum contract questions
- Who provides and who consumes the behaviour?
- What inputs and outputs exist?
- What are the types, nullability, ranges, and units?
- Which errors are observable?
- What are retry and timeout rules?
- What ordering and concurrency guarantees exist?
- How is data serialized?
- Who owns persistent state?
- How is compatibility versioned?
- What is explicitly not guaranteed?
Contract artifact
name: version: provider: consumers: inputs: outputs: errors: timeouts: retries: ordering: concurrency: ownership: compatibility: migration: verification:
Contract evolution
Changing a contract should be a controlled engineering event. Identify the owner, boundary, contract impact, observable acceptance evidence, and migration or recovery path.