Semantic Constraints Catalog¶

**`basket-line-references-product`** — Every Basket Line must reference exactly one Product.

**`basket-may-have-lines`** — A Basket may contain zero or more Basket Lines. An empty basket is valid before item selection.

**`catalogue-must-have-products`** — A published Catalogue must contain at least one active Product.

**`channel-must-have-catalogue`** — An active Channel must have at least one Catalogue assigned. A channel with no assortment cannot transact.

**`consent-belongs-to-customer`** — A Consent record must be associated with exactly one Customer.

**`exchange-belongs-to-order`** — An Exchange must reference the original Order it is replacing.

**`fulfillment-order-belongs-to-order`** — A Fulfillment Order must be derived from exactly one Order. Fulfillment cannot exist without a commercial commitment.

**`invoice-belongs-to-order`** — An Invoice must be associated with exactly one Order.

**`loyalty-account-belongs-to-customer`** — A Loyalty Account must be owned by exactly one Customer.

**`loyalty-member-references-customer`** — A Loyalty Member record must reference exactly one Customer profile.

**`order-belongs-to-customer`** — An Order must be associated with exactly one Customer. Anonymous orders are not supported in UC-BoK.

**`order-line-references-product`** — Every Order Line must reference exactly one Product. An order line without a product has no catalogue meaning.

**`order-must-have-lines`** — An Order must contain at least one Order Line. An empty order has no commercial meaning.

**`payment-belongs-to-order`** — A Payment must be associated with exactly one Order. Payment without a commercial context is not valid.

**`picking-task-belongs-to-fulfillment-order`** — A Picking Task must belong to exactly one Fulfillment Order.

**`refund-belongs-to-payment`** — A Refund must be applied against exactly one original Payment.

**`reservation-references-inventory`** — A Reservation must reserve a specific Inventory Item. Reservations without a specific item are not allowed.

**`return-belongs-to-order`** — A Return must reference the original Order it relates to.

**`shipment-has-lines`** — A Shipment must contain at least one Shipment Line. An empty shipment has no fulfillment meaning.

**`shipment-references-address`** — A Shipment must have exactly one delivery Address. Fulfillment without a destination is not possible.

**`basket-cannot-convert-abandoned`** — An abandoned basket cannot be directly converted to an order. It must be reopened and go through checkout.

**`order-cannot-cancel-when-completed`** — A completed order cannot be cancelled. Post-completion reversals must be handled as returns or exchanges.

**`order-cannot-dispatch-without-confirmation`** — An order must pass through confirmed state before entering fulfilment. Skipping confirmation bypasses fraud and stock checks.

**`order-return-only-from-completed`** — Returns can only be initiated after an order is completed. In-flight orders require cancellation, not return.

**`payment-cannot-reactivate-voided`** — A voided payment cannot be captured. A new payment authorisation must be initiated.

**`payment-capture-requires-authorisation`** — A payment cannot be captured without prior authorisation. Capture directly from pending bypasses fraud and fund-hold controls.

**`payment-refund-requires-capture`** — A payment cannot be refunded unless it has been captured. Refunding an authorisation must use void, not refund.

**`reservation-cannot-confirm-expired`** — An expired reservation cannot be confirmed. A new reservation must be created from available stock.

**`return-cannot-reopen-rejected`** — A rejected return cannot be re-approved in the same return lifecycle. A new return request must be submitted.

**`return-refund-requires-inspection`** — A return cannot be refunded without inspection. Inspection determines acceptance and refund eligibility.

**`customer-owned-by-crm`** — Customer identity and profile is exclusively owned by the CRM.

**`inventory-owned-by-sim`** — Inventory state for store locations is exclusively owned by the SIM.

**`loyalty-member-owned-by-loyalty-platform`** — Loyalty Member records are exclusively owned by the Loyalty Platform.

**`order-owned-by-oms`** — The Order lifecycle is exclusively owned by the OMS. No other application may modify order state.

**`payment-owned-by-payment-hub`** — The Payment lifecycle is exclusively owned by the Payment Hub.

**`product-owned-by-ecommerce-platform`** — Product catalogue management is typically owned by the eCommerce Platform or a dedicated PIM. Exclusive ownership is context-dependent.

**`channel-in-commerce-domain`** — The Channel Business Object is owned by the Commerce domain.

**`customer-in-customer-domain`** — The Customer Business Object is owned by the Customer domain.

**`inventory-in-inventory-domain`** — The Inventory Business Object is owned by the Inventory domain.

**`loyalty-account-in-loyalty-domain`** — The Loyalty Account is owned by the Loyalty domain.

**`order-in-order-domain`** — The Order Business Object is owned by the Order domain.

**`payment-in-payment-domain`** — The Payment Business Object is owned by the Payment domain.

**`product-in-commerce-domain`** — The Product Business Object is owned by the Commerce domain.

**`promotion-in-promotion-domain`** — The Promotion Business Object is owned by the Promotion domain.

**`shipment-in-fulfillment-domain`** — The Shipment Business Object is owned by the Fulfillment domain.

**`store-in-store-domain`** — The Store Business Object is owned by the Store domain.