Release, and why nothing is left behind

The end of a job on E31 Network is a single step with three effects. The compute held for the job goes back to the pool. The meter stops. What was held is accounted for. After release, the submitter owns no hardware, has no instance running, and is paying for nothing. The design describes this with a short phrase: nothing is owned, nothing sits idle afterwards.

This article is about why release is treated as a step in its own right, what it is designed to leave behind, and why it is the step the whole model depends on.

Release is an event, not a cleanup

In a system where you own or lease machines, the end of a job is a non-event. The machine is still yours, it is still running, and the bill does not care whether it is doing anything. On E31 Network, the end of a job is the point at which the rented compute stops being yours.

The design intent is that release follows the return of the output. The job declared what it would produce; the output has come back; the job is complete; the compute is released. The sequence matters, because releasing before the output is safely returned would risk the result. The article on how output comes back covers the step before this one.

Release is also triggered when a job reaches the limit in its request without completing. The compute is still returned to the pool and the meter still stops. What comes back in that case is covered in what happens when a job fails.

The meter stops

The meter on E31 Network runs for the hours compute is held for a job. Release is the moment that holding ends, so release is the moment the meter stops. There are no hours after release. There is no idle time trailing the job while someone remembers to shut it down, because there is nothing for anyone to shut down.

This is the counterpart to the rule that the meter does not start until compute is held. Together, the two rules mean the bill covers rent and run and nothing else. The piece on when the meter starts covers the front end of that window. No rates are published for any of it yet.

What was held is accounted for

Release produces a record. The design intent is that the submitter can see what compute was held for the job and for how long, so the bill is traceable to something specific. The preview describes this as something an auditor could read, which is a statement about legibility, not a compliance claim.

The accounting is per job. Each job holds its own compute for its own hours and produces its own record. There is no shared pool of hours to reconcile, no rolling balance, and no monthly commitment to true up against, because none of those exist in the design. A team's usage is the sum of its jobs, and each job is accounted for on its own.

Why release makes the economics work

The reason to be careful about release is that it is where the network's economics come from. A team that owns compute for its peak pays for that compute at the trough. A team that rents compute for a job and releases it pays for the job. The difference is only real if released compute goes somewhere.

It does. Compute released by one job is free compute, and free compute is what the next job in the queue has been waiting for. Release is the supply side of the queue. Every job that ends on time frees compute for a job that has been waiting, which is what lets the pool stay busy while each team pays only for its own hours. The article on the queue covers the demand side.

What is left behind

In the design as published, the answer is: a record, and nothing else that the submitter is paying for. The compute is in the pool. The output is with the submitter. The staged data is no longer needed by the job.

What happens to staged data and output after release, how long anything persists and when it is deleted, is not yet published. The program has said so directly rather than describe a retention policy it has not finished. Until it is published, a submitter should treat it as an open question, and raise it when design-partner intake opens. For the full sequence of a job from submission to this step, see how it works and the life of a job.