Documentation is an essential start
A field table is valuable. It names required values, types and perhaps examples. Without it, two systems may not even begin to talk. The temptation is to call the table a contract and assume the remaining behavior is obvious.
It is rarely obvious. What if a date is missing, a source was superseded, a message times out after taking effect, or null means refusal rather than error? A retry must reuse an idempotency key where supported, or reconcile the first effect before repeating it. Matching fields can still lead to different decisions.
Behavior lives in the exceptions
Imagine a Memory contract with a schema stored in the graph and a handler that reads different field names. Each side can be documented and syntactically valid while the pair fails. C15 recorded this as a historical creation risk and proposed a validator; its April inventory should not be treated as a current defect list.
PHS's A22 consumer contract specifies ownership, operations, explicit errors, decision semantics and execution references. T01 calls for service, registry, graph and governor-read tests. M16F proposes versioned calibration and rollback criteria for memory policy. Together they show that a contract must be executable and checked across its real boundary.
Pause here: Which failure case could violate the intended agreement while still producing valid fields?
Prove the agreement with tests and receipts
A written specification can be complete when it defines permitted use, authority, errors, versioning and invariants. Conformance is a separate claim: test the actual provider-consumer pair under ordinary load and failure, with versioned receipts. One passing receipt supports that route and version, not every later deployment.
The fields are the vocabulary of a promise. The contract is the promise kept when a field is absent, a dependency is late or someone asks the system to cross a boundary it should respect.
My answer: A written contract needs semantics, authority and failure rules beyond fields. Tests and versioned receipts establish whether a particular implementation honors it at the boundary.