Multi-Resource Allocation Validation

Use this skill before returning a batch of resource allocation actions, and after building a feasible schedule to make small objective improvements.

Core Workflow

Replay every proposed action against a temporary resource state. A placement is valid only if each required resource remains non-negative after applying all earlier placements in the same batch. Do not validate each placement only against the original observation.

Example field names vary by task, but common reminders include cpu_free, memory_free, and gpu_slots[*].free_gpu_units.

Replay Skeleton

Use replay validation as the final gate before returning actions:

temporary_state = copy_resources(original_observation)
repaired_actions = []

for action in actions:
  if action is not a placement:
    repaired_actions.append(action)
    continue

  find the work item, target machine, and target slot/resource
  check compatibility
  check every required resource is available

  if any check fails:
    action = repair_or_replace_with_defer_or_reject(action, temporary_state)

  if action is still a placement:
    subtract consumed resources from temporary_state

  repaired_actions.append(action)

The combined action list must be feasible after all earlier actions in the same batch have consumed resources. Each work item should appear in at most one action, and deferred or rejected work should not consume resources.

Repair Order

When a placement fails validation, repair it in this order:

1. Try an alternate slot or resource on the same target.
2. Try an alternate active machine or target that already has compatible allocations.
3. Try an alternate inactive machine or empty target.
4. Defer the work if waiting is allowed and still useful.
5. Reject the work only when no valid placement or defer decision is appropriate.

In shorthand: alternate slot -> alternate active machine -> alternate inactive machine -> defer -> reject.

Feasible-Solution Improvement Pass