Provider and consumer only need to agree on data format. Is that enough?

A shared schema gets the data across

Data format matters. A schema can catch a declared type or structural violation. Yet a timestamp and a name might both be accepted as strings: a weak schema can parse the wrong meaning without complaint. Engineers need tests for that case too.

But matching fields do not guarantee matching meanings. A date may mean planned, observed or last updated. A confidence value may be a retrieval score rather than probability of truth. A null reply may mean a governed choice to stay silent or a service failure.

Semantics and authority cross too

Imagine PHS provides a governed result to a meeting application. It sees content equal to null and treats that as 'the persona passed.' Yet null could accompany an intentional pass, a protected refusal or an incomplete/error response. Status, decision class and will-speak fields must distinguish them. Parseable data alone cannot settle the behavioral decision.

PHS's A22 Governor consumer contract explicitly distinguishes decision class, will-speak state, reason codes and execution reference. Its M16B admission design distinguishes access to evidence from disclosure to an audience. C15 documents a historical schema/handler drift gap. Each example concerns meaning and authority beyond the presence of fields.

Pause here: If every field parses correctly, which wrong decision could the consumer still make?

Write a contract for behavior, not just fields

A complete agreement names owners of decisions, permitted uses, error states, version compatibility, privacy purpose, idempotency and receipts. It specifies how the consumer behaves when information is missing or contradictory. Tests should include negative cases, not only a happy example that parses.

The format is the envelope. The contract is also the promise about what the letter inside may say, who may open it, and what action follows. Systems become trustworthy when those promises survive the crossing.