Eligibility
The storefront concern of WHO MAY TRANSACT for a product and under WHAT PER-ORDER LIMITS and CREDENTIAL GATES — the offer-level access rules, as opposed to what the product is (Axis K) or what it costs (pricing). It holds the buyer segment an offer is restricted to (customer_type_eligibility), the minimum and maximum quantity purchasable (minimum_order_quantity / maximum_order_quantity), and the credential a buyer must present to complete the purchase (purchase_gate). Orthogonal to `pricing`: `price_eligibility` (b56) selects which PRICE TIER a buyer qualifies for among prices all still buyable; this concern gates whether a buyer may buy AT ALL and how much. Its members are offer FILTERS, not product-variation axes — no product is sold in a 'trade version' vs a 'public version', so a family never splits on eligibility (axis-eligibility is derived, not stored). The realised checks — is THIS buyer a member, does THIS buyer hold the licence, how many are in THIS cart — are downstream catalogue/offer data (L1); the grammar that an offer CAN be so gated is the Pool's. Business-function (an offer's verb, Sell/RentOut/Repair — edges into services) is tracked separately and is deliberately NOT a member here.
4 questions in all: 2 measured figures (minimum order quantity and maximum order quantity) and 2 answered from a set list (customer eligibility and purchase gate).
The storefront concern of WHO MAY TRANSACT for a product and under WHAT PER-ORDER LIMITS and CREDENTIAL GATES — the offer-level access rules, as opposed to what the product is (Axis K) or what it costs (pricing). It holds the buyer segment an offer is restricted to (customer_type_eligibility), the minimum and maximum quantity purchasable (minimum_order_quantity / maximum_order_quantity), and the credential a buyer must present to complete the purchase (purchase_gate). Orthogonal to `pricing`: `price_eligibility` (b56) selects which PRICE TIER a buyer qualifies for among prices all still buyable; this concern gates whether a buyer may buy AT ALL and how much. Its members are offer FILTERS, not product-variation axes — no product is sold in a 'trade version' vs a 'public version', so a family never splits on eligibility (axis-eligibility is derived, not stored). The realised checks — is THIS buyer a member, does THIS buyer hold the licence, how many are in THIS cart — are downstream catalogue/offer data (L1); the grammar that an offer CAN be so gated is the Pool's. Business-function (an offer's verb, Sell/RentOut/Repair — edges into services) is tracked separately and is deliberately NOT a member here.
| customer eligibility | ◇token |
| minimum order quantity | №number + unit |
| maximum order quantity | №number + unit |
| purchase gate | ◇token |