How the output comes back

A job on E31 Network is not finished when the computation stops. It is finished when the output has come back. The output step is where the thing the submitter asked for, a trained model, a set of inference results, a batch of processed footage, a simulation report, leaves the compute and returns to the team that submitted the job. It is also the step that tells the network the job is done, which is what lets the compute be released and the meter stop.

This article covers what the design has settled about the output step and is explicit about what it has not.

The output is named before the job starts

The output is the fourth of the four things a job declares. It is stated at submission, before any compute is held, alongside the work, the data, and the request. This is not paperwork. Declaring the output tells the network what to return, and it gives the network a way to recognise that the job is complete.

Without a declared output, a job has no clear end. The design intent is that completion is defined by the output existing and being returned, not by a process exiting. A job that declares "the retrained model" is done when the retrained model has come back. A job that declares "processed footage for every input clip" is done when that set is returned. The piece on what a job declares covers the other three declarations.

What the output might be

The preview describes four broad shapes: a model, a set of results, processed files, a report. Each of the illustrative requests maps onto one. "I need compute tonight to retrain my model" produces a model. "I need eight GPUs for four hours to process this dataset" produces processed files or a set of results. "I have forty hours of warehouse camera footage that needs processing" produces processed files. "I need to run ten thousand simulations" produces a report, or a set of results, or both.

The design does not restrict the output to these shapes; they are the common cases. What matters is that the output is a defined artifact. The intent is that the submitter receives a thing, not access to a machine they then have to copy from.

Returned to the submitter

The output goes to the submitter. The design intent is that the artifact leaves the compute and is returned, rather than sitting where it was produced waiting to be collected. This is consistent with the rest of the design: the compute is rented for the job, and when the job is done the compute should hold nothing that belongs to the submitter.

How the output travels is not yet published. The preview does not describe a transfer mechanism, a storage location, or an interface for retrieval, and this article will not invent one. The program has named getting large datasets to where the compute is as an unsolved problem, and moving large outputs back is the same problem in the other direction.

What return triggers

Returning the output is the event that moves a job from the output step to the release step. Once the artifact is back with the submitter, the compute held for the job is released to the pool and the meter stops, and a record of what was held is written. The article on release treats that step on its own.

This ordering is deliberate. The compute is not released until the output is safely returned, because releasing first would risk losing the result. The hours between the work finishing and the output returning are therefore still held, which is one reason the design wants outputs declared and bounded.

What is not yet published

Two things a careful reader would want to know are not available. The first is retention: how long the staged data and the returned output persist anywhere on the network after the job ends. The second is deletion: when and how anything left is removed. The program has said these specifics are not yet published and has chosen to say so rather than describe a policy that does not exist.

Until they are published, the honest guidance is to assume nothing. A team evaluating the network should treat retention and deletion as open questions to raise when design-partner intake opens, not as settled properties. For the design as a whole, how it works shows the output step in sequence, and the examples illustrate what each of the four requests would return.