The setup
An office and a restaurant have a standing Catering Agreement. It fixes price rules, delivery area, order cutoff, restaurant capacity, participant Channels, and the operation that may create child Orders.
The request exceeds the exact 50-meal capacity constraint and is withheld without creating an Order.
The operation matches the Agreement and creates one bounded Order with the office’s occurrence-specific data.
Its own source Timeline and Mandate are verified against the Order operation and current capacity.
The provider contributes the fact it controls. The Order changes and the PayNote condition becomes satisfiable.
Blue records the provider-backed outcome and updates the relationship ledger; it does not claim that document code moved the funds.
Embedded or autonomous Orders?
Orders may be embedded when one Agreement clearly owns them, access and retention align, and throughput is modest. Use autonomous Order Roots when customers, merchants, logistics, payment providers, or other systems need a separately shared object; when lifecycle survives the Agreement; or when scale and access policy diverge.
What this proves
- The Agreement is a reusable operating framework rather than a template copied into private databases.
- Order creation is a document operation with exact eligibility and request constraints.
- Provider facts and payment truth remain attributable to the systems responsible for them.
- A document network can grow without collapsing every lifecycle into one monolith.