What a job declares before it can be scheduled

The scheduler on E31 Network would not see your code, your team, or your deadline pressure. It would see a job description. Whether that job runs tonight or sits waiting depends on how well the description tells the scheduler what it needs to know. The design asks for four declarations, and this article goes through them one at a time.

The preview has not fixed the exact form these declarations will take. What follows is the shape of the design, and the final section lists what remains undecided.

The work

The first declaration is what runs. A training run over a dataset. A batch of inference requests to be answered in bulk. A processing pass over a backlog of footage. A sweep of simulations with varied parameters. The work is the thing the compute is being rented to do, stated plainly enough that the network can tell it apart from a job that should not be here at all.

That last point matters. The network is built for work that can wait for a queue. A declaration that describes a control loop, a live operator tool, or anything else that must answer in the moment describes a job that belongs on local infrastructure, not here. The workloads page draws this line in more detail.

The data

The second declaration is what the job reads. The design intent is that data is staged for the job before it starts, so that the run step reads from compute-local storage rather than reaching back to the submitter mid-run. A declaration that names the data up front lets the staging happen before the meter starts.

Getting large datasets to where the compute is remains on the program's list of unsolved problems. The declaration can name the data; how that data moves at scale is still being worked out, and nothing about it is published yet.

The request

The third declaration is the compute itself: how much, for how long or until done, and when it must be finished. The illustrative request "I need eight GPUs for four hours to process this dataset" states all three in one line. So does "I need compute tonight to retrain my model", though less precisely about size.

The request is what the scheduler would match against free compute. A tight request is easier to place than a loose one. A deadline tells the scheduler how long the job can afford to wait; a job with no deadline can take whatever slot opens, which is the cheapest way to use a queue. The piece on the queue explains why waiting is designed to cost nothing.

The output

The fourth declaration is what comes back. A trained model. A set of inference results. The processed footage. A report from the simulation sweep. Declaring the output does two jobs at once: it tells the network what to return to the submitter, and it tells the network how to recognise that the work is finished.

Without a declared output, the job has no clear end, and the end is what triggers release and stops the meter. The article on how output comes back covers the return step itself.

What is still open

The four declarations are the design's answer to a question the program has not finished answering: exactly what must a job state to be scheduled well. The headings are settled. The fields under each heading are not.

Some of the open points are practical. How a job should describe its size when it does not know it in advance. How a deadline should interact with a request that wants to run until done. How a job that produces intermediate output should declare that, so a partial result can come back if the run stops early. The program publishes these as unfinished rather than pretending the format is final.

If you want to see the four declarations applied to concrete cases, the examples page walks through four illustrative requests, and the life of a job shows where each declaration is used along the way.