Obligation

What It Models

Delivery work belongs to a sale, but the application delivering it owns the resulting membership, access or goods. An obligation coordinates that work by retaining the conditions for release, the application responsible, its answers and staff interventions. Physical delivery uses one obligation for each unit.

Identity and Attributes

Identity combines the workspace with a subject, an operation and a unit index. The selected delivery policy is copied onto the obligation with its version and selection source. Authorization history separates a new staff authorization from a retry of an existing instruction; attempt history records both current and stale answers.

Relationships

Policies supply the frozen conditions. Exceptions identify problems without owning the obligation. Allocation units and shipment lines connect physical delivery to the register, while reversal enforcements retain their own instructions beside the original delivery.

Invariants

The structured invariants distinguish database constraints from service checks. Gate opening retains authorization and dispatch together. Outcome application checks the current authorization, while later history and enforcement updates can fail separately.

How It Is Stored and Shared

Fulfillment owns the register and its companion records. Shipping completes physical-unit obligations through the register; Inventory and Operations read the records for their own checks and actions. Migrated final outcomes enter through data operations. Applications receive instructions and use callbacks rather than reading these tables.

Open Design Questions

Product must settle warehouse acknowledgement timing and the ownership and permitted writers of the shared intervention ledger.