Describe requirements, not machines
A worker declares the models it needs by alias. A model name pins that model exactly; a requirement such as{"kind": "agent", "intelligence": "medium"} states a floor that placement resolves against what outposts serve. Intelligence tiers are declared by the operator who serves a model, never guessed from its weights. On one outpost a warm model beats a cold one, then the lowest satisfying tier wins.
Eligibility comes first: an outpost must be among the allowed set, be fresh in the registry, run or be able to load the model, advertise an executor for the operation’s kind and a peer endpoint, and be able to carry the output back in one reply. Eligible outposts are then ranked by your preferred list, then warm models, then advertised capacity per attempt already in flight, then local before remote. A Broom sweep is placed stage by stage instead: a stage runs on the outpost holding its data, and its rows move to outposts that can run its detectors or code when that one cannot.
Capacity is what each receiver advertises in its heartbeat, per operation kind, and the receiver’s admission remains authoritative. A detector attempt goes first to an outpost already running that detector, then to one that would load it and has the GPU memory free; a detector loaded for an attempt is unloaded after 15 idle minutes.
Preview before you submit
estimate(), and .explain() on a dataset, describe the scheduler’s plan without reserving capacity, moving inputs or running the worker: record and partition counts, the eligible outposts in rank order, a recommended concurrency, transfer bytes, the assumptions made and why any outpost was blocked. Durations are not estimated. Use preferred for a locality hint and allowed when execution must stay within named outposts.
Inspect a plan
“self” is resolved only inside preferred and means the outpost receiving your submission; peers stay eligible. allowed takes outpost IDs from outposts() and is the restrictive option.