Output
What a job returns to the team that submitted it: a trained model, inference results, processed files, or a report. The fourth thing a job declares and the reason it was run.
· 2 min read
IN SHORT
Output is what a job returns to its submitter: a model, a set of results, processed files, or a report. It is the fourth thing a job declares, and naming it is what lets the job finish without anyone watching. In E31 Network's design, output is returned before the compute is released and the meter stops; retention specifics are not yet published.
Output is what a job returns to the team that submitted it: a trained model, a set of inference results, processed files, a report, or whatever else the job was declared to produce. It is the fourth thing a job declares and the reason the job was run.
Why it matters
Naming the output up front is what makes a job a job rather than an open-ended session. A team that can say what should come back can also say when the work is done, which is what lets the compute be released and the meter stopped without anyone watching. Work with no defined output tends to turn into a running instance, and a running instance is the thing the network is designed to avoid.
Output is also where the value of the rented hours lands. The hours themselves are gone the moment the compute is released; the model, the processed footage, or the simulation results are what the team keeps. Thinking in terms of output keeps the question focused on what the job produced rather than on what hardware it ran on.
How it works on E31 Network
In the designed flow, output is the fourth of five steps: submit, rent, run, output, release. When the job finishes, its results are returned to the submitter. Only then is the compute released and the meter stopped. The team pays for the hours compute was held while the job ran, not for the step in which results come back.
What counts as output depends on the work. A retraining job returns a model. A batch inference job returns results, often as a file. A footage job returns processed footage, detections, or a summary. A simulation sweep returns a set of results across the swept parameters. A job description would name the expected output alongside the work, the data, and the request, so that completion has a concrete meaning.
The design intent is that the output is returned to the submitter and that what was held is accounted for alongside it. How long outputs or staged data are retained, and how deletion works, are specifics the program has not yet published, and they should be read as open rather than assumed. The examples page shows what the output looks like for each of the illustrative requests.
Related terms
Questions this raises
- How is output returned to me?
- The design is that results are returned to the submitter when the job finishes, before the compute is released. The exact mechanism for delivery has not been published, and no interface should be assumed beyond the fact that the output comes back to the team that submitted the job.
- What if a job produces no useful output?
- A job still runs to completion and the compute is still held while it runs, so the meter counts those hours regardless of what the output turns out to be. That is a reason to describe the work and the expected output carefully before submitting.
- Is output kept on the network after the job?
- The retention and deletion specifics for outputs and staged data have not been published. The program lists this openly among the things not yet settled rather than describing a policy, and nothing should be assumed in either direction.
KEEP READING