Agreements, Offers, Orders, and commerce packages
Reusable document families for complete agreements, customer offers, concrete orders, stage processes, referrals, capacity, guarantees, and wider commerce.
Why this area deserves dedicated pages#
The core stack is abstract by design. Commerce packages give the architecture names people already understand: Agreement, Offer, Order, acceptance, invoice, milestone, fulfilment, renewal, termination, referral, capacity, and dispute.
The package ecosystem should grow from repeated real-world need, not from publishing dozens of shallow nouns.
Agreements#
The current Agreement architecture preserves complete authored text and owns ordered lists of reusable process occurrences. Parties and process parameters link back to exact clauses. Child processes prove that configured rules are satisfied; the Agreement Root owns authoritative lifecycle events and state.
This architecture is design-stage. It should be explained prominently but not labeled as a released interoperability profile.
Offers#
An Offer describes what another participant may accept: subject, price, capacity, constraints, expiry, participant roles, and order-creation path. Offers can be composed from other capacity or service documents and may be created or proposed by agents under bounded authority.
Exact standard Offer types should be published only after repeated patterns stabilize.
Orders#
An Order records one concrete occurrence. It can reference an Offer and Agreement, bind occurrence-specific participant channels, expose operations, receive provider facts, create or link PayNotes, and emit fulfilment or dispute events.
The same Order type may support an embedded profile and an autonomous Root profile. Ownership determines the boundary, not the noun.
Wider commerce patterns#
Capacity publications, referrals, living passes, organizer wallets, guarantees, disputes, substitutions, reservations, and distributor revenue shares can be modeled as specialized document networks. They should begin as explanatory application profiles and move into packages only when semantics repeat across real deployments.
Small initial process catalog#
For Agreements, a high-quality initial library is more valuable than a large catalog. Good candidates include exact-content acceptance, activation after conditions, payment requests, Order creation, stage advance after PayNote confirmation, renewal unless notice, mutual amendment, termination on notice, uncured breach, mediated dispute, and closeout.