Job
The unit of work on E31 Network: a self-contained piece of compute work that declares its work, data, request, and output, runs unattended, and returns a result.
· 2 min read
IN SHORT
A job is the unit of work on E31 Network. It declares the work to run, the data it reads, the compute it requests, and the output it returns. A job moves through submit, rent, run, output, and release; compute is held, metered, and accounted for per job. Work that must answer now is not a job and stays on the team's own systems.
A job is the unit of work on E31 Network: a single, self-contained piece of compute work that a team submits, that runs unattended, and that returns an output when it is done. Everything on the network is held, metered, and released per job.
Why it matters
Pricing, scheduling, isolation, and accounting all need a unit. If the unit is a server, a team pays for the server whether or not it is busy. Making the job the unit ties every one of those things to the piece of work actually being done.
It also forces clarity. A job has to be described well enough to be scheduled, which means the team has to know what it is asking for before it asks. That discipline is useful on its own: a job that can be written down as work, data, request, and output is usually a job that can be run without someone watching it.
How it works on E31 Network
As designed, a job declares four things. The work: what runs, such as a training run, a batch of inference, a processing pass over footage, or a set of simulations. The data: what the job reads, staged for the job. The request: how much compute, for how long or until done, and when it must be finished. The output: what comes back, such as a model, a set of results, processed files, or a report.
The life of a job has five steps. Submit, where the team describes the work, data, request, and output. Rent, where compute is held for the job and the meter starts. Run, where the job executes unattended and isolated from other jobs. Output, where results are returned to the submitter. Release, where the compute returns to the pool and the meter stops. A team pays for rent and run only.
Not every workload is a job in this sense. Work that must answer now, such as robot control or live perception, is not a network job and stays on the team's own systems. Work that can run tonight is. The program has said openly that exactly what a job must declare to be scheduled well is still an open question.
Illustrative requests are the easiest way to picture a job: "I need compute tonight to retrain my model," or "I need to run ten thousand simulations." The examples page walks through each of them as a job.
Related terms
Questions this raises
- Does a job have to finish in one run?
- As designed, yes: a job is a self-contained piece of work with a defined output, and the compute is released when that output is returned. Work that needs a person in the loop while it runs is not a job in this sense. Long work is still one job as long as it can run unattended to completion.
- What is the request part of a job?
- The request says how much compute the job needs, for how long or until done, and when it must be finished. The deadline is what tells the network how long the job can wait in a queue. No rates are published yet, so the request describes compute, not cost.
- Can a job be interactive?
- No. A job runs unattended from the moment compute is held until the output is returned. Interactive work, where a person waits on each reply, must answer in the moment and belongs on the team's own infrastructure rather than on the network.
KEEP READING