Execution

What execution covers

Execution is where a workload actually runs: an isolated chain or container on hardware belonging to an operator the tenant has no contract with. That arrangement only works if two things are settled first. The workload has to be bounded, so it cannot consume the machine it lands on or reach its neighbours. And capacity has to be located and held before the workload is dispatched, so a deployment is not a request to a host that has already given the same cores away.

The unit of work

Two shapes of workload share one isolation model.

| | UniNet chain | Container | | --- | --- | --- | | Purpose | a dedicated execution environment with its own ownership and state | a hosted workload | | Resource limits | declared before it runs | declared before it runs | | Isolation | container-level | container-level | | Lifecycle | operations to start, stop and remove | operations to start, stop and remove |

The declaration is the part that carries weight. Limits are stated up front and are the same limits the reservation is made against, so what a tenant may consume is known before placement and what an operator gave up is countable after it. There is no runtime negotiation in which a workload asks for more than it declared.

Capacity discovery

Discovery answers one question across independent nodes: what is available, and where. It covers three dimensions.

| Dimension | Discovered | | --- | --- | | CPU | available cores | | Memory | available memory | | Storage | available storage |

That list is exhaustive. Capacity discovery is not GPU-aware scheduling: accelerator class is not a dimension the discovery layer reasons about, so a workload that requires a specific GPU cannot be placed by this mechanism. Discovery also returns a set of candidates rather than a single answer, which is what makes the next step possible.

Reservation

Reservation is the commitment point. A request names the resources it needs and the period it needs them for, and the node either holds exactly that or it does not — the operation is atomic, so the same capacity is not handed to two schedulers at once. Where the requested node cannot satisfy the request, the request falls through to another suitable candidate rather than failing the deployment.

   request: 8 CPU · 32 GB memory · 100 GB storage
        │
        ▼
   candidates ──▶ node A  ──▶  reserve (atomic)  ──▶  held
                  node B
                  node C
                     ▲
        node A full ─┘  next suitable candidate

For a caller this changes what a deployment target is. Placement becomes the result of a query evaluated at the moment of dispatch, rather than a hostname written into a configuration file months earlier and hoped to still be correct.

The primitives described here are per-node: discovery across candidates, reservation against one of them, and the lifecycle of a workload on the node that accepted it. Coordinating a single logical deployment across many nodes — placement policy, failover between them, rescheduling after loss — is a layer above these primitives rather than a property of them.

What an operator sells

The distinction that matters on the supply side is that an operator sells capacity, not shell access.

| Arrangement | What the tenant receives | What the operator hands over | | --- | --- | --- | | Machine or shell handover | a login on the host | administration of the machine, and an account to police | | UniNet | a container bounded by its declared limits, for a declared period | the resources that were reserved, and nothing adjacent to them |

The operator keeps administering the machine the way they already do. A tenant's claim is bounded by the reservation and the container's declared limits, which means the end of a period is capacity reclaimed rather than a disagreement to resolve.

The isolation boundary should be read precisely. It is container-level and it is not hardware-backed. The host operator is therefore inside the trust boundary: they can observe what runs on their machine. A workload whose threat model includes the party executing it is not served by this model, and no arrangement of private networking in front of it changes that — routing conceals where a workload runs from everyone except the machine running it.

On the other side of the same transaction, a node operator is a cryptographic identity rather than an address. Delivery history accumulates against that key, so a scheduler can weight candidates by a recorded reliability signal, and that record remains referenceable outside whatever marketplace or scheduler produced it.

How it composes

A reservation is held by an identity, and so is the operator serving it. Both sides of a placement are keys rather than accounts in someone's database, which is what makes a delivery record portable.

Software that reserves capacity on its own behalf does so under delegated authority bounded in scope, spend and duration. An agent permitted to reserve compute is not thereby permitted to reserve without limit, and revoking the delegation cascades to what was derived from it.

Once running, the workload is reachable over UNP at an address not derived from the node that won the reservation — so the fallback described above is invisible to callers, who never held the host address in the first place.