Normalize capabilities, not machines
A workload should declare the capabilities it needs rather than name a specific server. Memory, accelerator support, runtime features, locality, policy, and availability are durable requirements. Individual hostnames are implementation details.
The capacity layer can translate each location into a comparable capability profile. Placement then matches intent to approved supply without pretending the underlying environments are identical.
Make desired state explicit
Every deployment needs a durable desired state: workload version, site profile, resource requirements, data policy, rollout cohort, and fallback behavior. Local agents reconcile toward that state and report what is actually running.
- Use immutable workload versions and independently versioned site profiles
- Record why a placement decision was made
- Keep the last known-good state available locally
- Represent blocked or degraded placement as a visible state, not a silent retry
Separate placement from rollout
Placement decides where a workload can run. Rollout decides how a new desired state reaches those locations safely. Combining the two makes failures hard to reason about, especially when capacity changes during an update.
Roll out by cohort with health gates. The system should be able to pause, promote, or reverse a version without recalculating unrelated placements across the entire fleet.
A scheduler finds a destination. A rollout controller earns confidence that the destination is healthy.
Observe the distributed experience
Fleet metrics are useful only when they retain site and workload context. Measure placement time, update success, response latency, saturation, model quality signals, and time spent in degraded modes. Central aggregation should respect each site's data policy.
Operators need to move from a global symptom to a specific local cause: which version, which profile, which capacity, and which recent change. That path is what turns a collection of edge machines into an operable platform.