Validates whether a proposed warehouse action (replenishment, allocation, transfer) satisfies all hard physical and operational constraints before execution: capacity, quality status, shelf life, and allocation bounds. Blocks INFEASIBLE actions before they reach the utility scorer. Use as a pre-filter before `multi-attribute-utility-scorer` or before committing any warehouse operation. Questions like 'Can we physically fit this order in Warehouse B?', 'Is this stock eligible for outbound shipment?', 'Will this allocation exceed our committed quantities?'
Activate this skill when the user asks about:
multi-attribute-utility-scorerRational agents only choose from feasible actions — those that satisfy all hard constraints on the outcome space (Ch.6 §6.1, Algorithms for Decision Making). Before computing utility, infeasible actions must be eliminated from the candidate set.
Hard constraints are absolute — any violation makes the action infeasible regardless of its utility score. Soft constraints produce a penalty score but do not block the action outright.
From Ch.14 §14.3 (Robustness Analysis): evaluate actions under plausible deviations from the nominal model — e.g. capacity calculations should account for already-reserved stock, not just on-hand quantities.
search_knowledge_base(
query="rational preferences constraints feasibility action space completeness transitivity",
k=3
)
What to extract from the result:
get_entity_by_number(number="14.3")
What to extract from the result:
on_hand + reserved (not just on_hand) as the
conservative capacity baseline to avoid overcommitmentGET /api/v1/smart-query/topology/warehouses/{warehouse_id}/capacity-utilization
Fields to extract: used_capacity_units, total_capacity_units,
utilization_rate, location_id
Compute remaining capacity:
remaining_capacity = total_capacity_units − used_capacity_units
Fallback: if endpoint unavailable → assume utilization_rate = 0.9
(conservative stress-test default per Ch.14 §14.3)
GET /api/v1/smart-query/inventory/observed-snapshot
?product_id=<product_id>
&location_id=<location_id>
Fields to extract: on_hand, reserved, quality_status, last_count_at
Also fetch product shelf-life if applicable:
GET /api/v1/smart-query/topology/locations/{location_id}
Fields to extract: capacity_units, type
GET /api/v1/smart-query/orders/{order_id}
Fields to extract per line: qty_ordered, qty_allocated, qty_shipped
Using the feasibility principle from Step 1:
# Hard Constraint 1 — Capacity
capacity_ok = (on_hand + qty_proposed) <= total_capacity_units
violation_1 = None if capacity_ok else "CAPACITY_EXCEEDED"
# Hard Constraint 2 — Quality (outbound shipments only)
quality_ok = quality_status in ('good', 'verified')
violation_2 = None if quality_ok else f"QUALITY_BLOCKED: {quality_status}"
# Hard Constraint 3 — Shelf Life (if shelf_life_days available)
days_remaining = (expiry_date - today).days # if applicable
shelf_life_ok = days_remaining >= 3 # minimum viable shelf life
violation_3 = None if shelf_life_ok else f"SHELF_LIFE_CRITICAL: {days_remaining}d"
# Hard Constraint 4 — Allocation Bounds
allocation_ok = qty_allocated + qty_proposed <= qty_ordered
violation_4 = None if allocation_ok else "ALLOCATION_EXCEEDS_ORDER"
# Collect all violations
hard_violations = [v for v in [violation_1, violation_2, violation_3, violation_4] if v]
Soft constraints do not block the action but reduce its utility score:
soft_violation_score = 0.0
# Soft: capacity utilisation > 80% after action
if (on_hand + qty_proposed) / total_capacity_units > 0.8:
soft_violation_score += 0.2
# Soft: quality is 'acceptable' (not ideal but not blocked)
if quality_status == 'acceptable':
soft_violation_score += 0.1
# Soft: last_count_at > 30 days (stale physical count)
if staleness_days > 30:
soft_violation_score += 0.1
if len(hard_violations) > 0:
feasibility_status = INFEASIBLE
blocking_reason = hard_violations[0] # primary blocker
elif soft_violation_score > 0:
feasibility_status = CONDITIONAL