What is accounted for when a job ends
The last step in the life of a job is RELEASE, and with it comes a record of what was held. What that record is being designed to contain, and what it is not.
· 4 min read
IN SHORT
When a job ends on E31 Network, the design intent is that what was held is accounted for: the compute held, the hours from the rent step to release, the data staged, and the output returned. The meter stops at release. The record is meant to be something an auditor could read; its exact form and the rates behind it are not yet published.
RELEASE is the quietest step in the life of a job. SUBMIT has the team's attention, RENT starts the meter, RUN does the work, and OUTPUT is the moment the team gets what it came for. RELEASE is just the compute going back to the pool. But it is also the step where the design closes the books, and what gets written down at that moment is the subject of this article.
The phrase the program uses is that what was held is accounted for. That is short, and each word in it carries a specific meaning.
What was held
Held is the operative word. A job on E31 Network does not own anything. At the rent step, compute is held for the job; at release, the hold ends. Everything in between is a period during which specific resources were set aside for one job and no other.
The design intent is that the record describes that hold. It would say what compute was held, in the terms the job requested it. It would say for how long, from the moment the hold began to the moment it ended. It would note the data that was staged for the job, because that data was part of what the job had set aside for it. And it would note that the output was returned to the submitter, because the return is the point at which the job's purpose was met.
That is the shape. The exact format is not yet published, and the program is not inventing one for the sake of a tidy article.
What is paid for
The commercial rule is simple to state. A job pays for RENT and RUN only. The meter starts when compute is held and stops when the job finishes and the compute is released. Rates will be published when access opens; none are published today, and this article does not guess at one.
Several things follow for the record. Time a job spent in the queue is not time compute was held, so it is not metered and would not appear as a charge. The moment the job finishes is the moment the meter stops; there is no trailing period in which released compute is still charged to the job that released it. And because held compute belongs to exactly one job at a time, the hours in one job's record are not shared with any other job's.
A team reading its record should be able to see one job, one hold, one span of hours, and nothing else bundled into it. That is the design intent, stated as intent.
Why the record is kept plain
There is a temptation in any metered system to make the bill elaborate. The program's stated aim runs the other way: a record plain enough that an auditor could read it without a guide.
Plainness is partly about trust in a preview. A team trying rented compute for the first time wants to see that what it was charged for matches what it asked for. A record that lists the held compute and the hours beside the original request lets the team do that comparison itself.
It is also about isolation. Because a job runs isolated from other jobs, with its own held compute and its own staged data, there is nothing to apportion. The record does not have to explain how a shared resource was divided. It describes one job's boundary and what was inside it.
And it is about the handoff back to the team. The output has already been returned by the time the record is written. The record is not where the team collects results; it is where the team confirms what the results cost and what was held to produce them.
What the record does not cover
The record is about the hold, and it ends when the hold ends. What happens to the staged data and the returned output after release is a separate question, and the program has not yet published the retention and deletion specifics. The article on what has not yet been published about retention is the honest statement of where that stands.
The record is also not a performance report. It would say how long compute was held, not how fast the job ran relative to anything else, and the program makes no performance claims for the preview. It is not a certification. It is not a bill with a published rate attached, because there is no published rate.
What it is, as designed, is the last thing a job produces: a plain account of what was set aside for it, for how long, and what came back. The how it works page shows where RELEASE sits in the sequence, and the article on isolation while a job runs explains why the account can be so simple.
Questions this raises
- Does the record show time spent in the queue?
- The design intent is that queue time is not metered, since compute is not held while a job waits. Whether the record notes that a job waited, for the team's own planning, is a detail not yet published. What is clear is that waiting would not be charged.
- What if a job is submitted but never runs?
- If compute was never held for it, nothing was rented and the meter never started. The program has not published what the record of such a job would contain beyond that. No rate, minimum, or fee of any kind is published.
- Is the record a compliance artifact?
- No claim of that kind is being made. The design intent is that the record is plain enough that an auditor could read it, but the program is not asserting any certification or compliance status for the preview.
KEEP READING