Fictional order handoff

State what the receiving team can rely on.

For order O-204, assume the receiving service validates before creating a warehouse order and can record a rejected request. These are proposed local rules, not a complete ODCS document or a tested product configuration.

Identifier

Example agreement: order_id is a required, nonempty string; O-204 retains the same source ID

If it breaks: Reject an absent or empty ID and record the reason; do not invent a replacement

Allowed status

Example agreement: Only ready orders enter this handoff; an unknown value is not mapped to ready

If it breaks: Hold the record for the source owner rather than silently choosing a default

Delivery date

Example agreement: requested_delivery_date must be a real calendar date written as YYYY-MM-DD

If it breaks: Reject an absent or invalid date before creating the warehouse order; sales operations obtains the correction

Separate update rule

Example agreement: When updating an existing order, an omitted delivery_note leaves the old note unchanged; explicit null clears it

If it breaks: This rule is separate from order creation. Test omission and null with the receiver before relying on either behaviour

Timing

Example agreement: Example local rule: the receiver validates and commits the change within five minutes of its source commit, using comparable UTC timestamps

If it breaks: Compare source commit time with receiver validation-and-commit time, linked by the same change ID. A transport receipt alone does not prove completion. Route a late or missing committed result to the integration owner; investigate clock or monitoring gaps.

Change process

Example agreement: The source owner proposes a new status and checks affected receivers before release

If it breaks: Test the new value and its business mapping; do not assume a new version is compatible

Contract vs schema

A schema checks constraints. The agreement explains their use.

JSON Schema can require a property and restrict its permitted values. That does not decide which team repairs a rejected order or whether a late update should be applied. Treat the schema as part of the agreement, rather than claiming it can only check basic types.

QuestionMachine checkOperational agreement
Is the order ID present?required checks presence; a separate nonempty-string constraint rejects an empty valueRecord the rejection and name the team that obtains the source ID
Is the status permitted?enum can restrict the accepted valuesAgree what ready means and which source states are allowed to map to it
Can the payload carry an extra field?The schema can allow or reject additional propertiesTest the affected consumers before changing the payload
What happens after validation fails?The validator reports the fields that failed its rulesSpecify the holding queue, notification and correction process

When contracts are absent

Check what the receiver actually does.

These are possible failures in the fictional handoff, not a claim that every integration fails this way. The expected response needs both an agreed rule and an implementation test.

Failure 1

An ambiguous date arrives

The source sends 05/11/2026. One parser might interpret that as 5 November, another as 11 May, and a strict receiver may reject it. The outcome depends on the implementation.

For O-204, agree 2026-11-05 and test that the receiver treats it as the intended calendar date. If old records may have been misread, assess those records rather than assuming that changing the parser repairs them.

Failure 2

The required date is missing

The receiver may reject the request visibly, while the sender fails to surface the rejection to the order owner. A rejected record is not proof that a null was written into the destination.

The agreed response for O-204 is to stop before creation, retain the reason and send the correction to sales operations. Retrying the unchanged invalid record does not supply its missing date.

Failure 3

A new status has no mapping

The source adds paused, but the warehouse handoff only accepts ready. A schema can detect the unexpected value; it cannot decide whether the order should enter picking.

Hold the order for the source owner to review. Add a mapping only after the receiving team agrees its meaning, rather than making an unknown state behave like ready.

Failure 4

A changed payload reaches an older consumer

Renaming requested_delivery_date can leave an older consumer looking for a field that no longer exists. Even adding an optional field can affect a receiver whose schema rejects additional properties.

Keep representative consumer tests beside the contract and check which deployed versions use it. Announcing a change or assigning a new version number does not prove that the running receivers accept it.

When to write it

Write the expected result for the rejected order as clearly as the result for the valid one.

For a new integration, agree consequential rules before implementing them. For an existing integration, first compare the written agreement with actual payloads, validation and recovery. A shared definition can reduce duplicated rules, but it does not prove that every deployed consumer uses the current version.