How the preview decides what to publish
A technical preview can say almost nothing that is not a plan or a guess. The program's rule is to publish what has been decided, name what has not, and refuse to fill the gap with claims.
· 4 min read
IN SHORT
E31 Network publishes what has been decided as forward-looking design intent, publishes what has not been decided as named open problems, and declines to speculate about what it is not yet ready to say. That rule is why no hourly rate is published, why the unsolved list is on the site, and why there is no form while design-partner intake is closed.
E31 Network is a technical preview, and a preview has a particular problem with publishing: almost everything it could say is either a plan or a guess. The program's rule for sorting them is simple to state. It publishes what has been decided, says plainly what has not, and declines to fill the gap between with anything that sounds like a claim. This article explains how that rule is applied across the site.
Decided, not yet decided, and not going to be said
Every statement the program might make falls into one of three groups. The first is things that have been decided: the unit is the job, a job declares work, data, request, and output, the meter runs during rent and run only, real-time work does not go to the network. These are published as design intent, in forward-looking language, because nothing has shipped.
The second group is things that have not been decided: the rate per hour, how large datasets reach the compute, how mixed job sizes are scheduled, exactly what a job must declare. These are published too, but as open problems. They appear in the section on what the program has not solved and in articles like this one, named as unsolved and not dressed up as features.
The third group is things the program is not going to say, at least for now: where the capacity comes from, retention and deletion specifics, anything that would be a performance or security promise. These are not hidden; the site says they are not yet published. But the program does not speculate about them, because speculation on a preview site reads as a commitment later.
Why no rate is published
The clearest application of the rule is pricing. The program has decided the shape, by the hour for the hours compute is held with the meter stopped at release, and has published that. It has not decided the figure, and it has not published one.
The temptation to publish an estimate is real. A figure would make the site more concrete and would let teams start planning. But an estimate on a preview site is read as a price, and a price that is later changed is read as a broken promise. The program has judged that saying rates will be published when access opens costs less in trust than a figure it would have to revise. A related article goes into what such a rate would need to cover, which is a way of being useful about pricing without naming a price.
Why the unsolved list is a feature
A conventional product site hides its open problems. A preview cannot afford to, for two reasons. The first is that the people the program most wants to hear from, teams with real batch jobs, are exactly the people who would spot a hidden problem on first contact. Publishing it first saves everyone the discovery. The second is that the list is how the program recruits help. A team that reads the scheduling problem and recognizes its own jobs as the hard case is a team the program wants as a design partner.
The list is maintained with the same rule as everything else. An item comes off when the problem is solved and the solution can be described as design intent. It does not come off because it has been there a long time or because it is awkward.
Why there is no form
The program does not mount a form, publish a contact address, or ask readers to register interest. Intake is not open, so a form would collect interest the program cannot act on. When intake opens, the design partners page will say so, and that will be the only place it is said. Until then, the site is for reading.
What the rule costs
Applying this rule makes the site quieter than it could be. There are no benchmarks, no customer stories, no rates, and no dates, because none of those can be published honestly yet. The program accepts that a reader may leave the site with fewer answers than they wanted. The alternative is a site that answers everything and has to take some of it back later.
For the current list of open problems, see what we have not solved yet. For what a team would be asked to contribute toward them, see what a design partner would be asked to do. For an example of the rule applied to pricing, see what a published rate would have to cover.
Questions this raises
- Will the site ever publish benchmarks or customer stories?
- Not while nothing has shipped. Benchmarks would be performance claims the preview cannot support, and there are no customers because no jobs can be submitted. Both would have to wait until there is something measured and someone real to describe.
- What would make the program publish a rate?
- Access opening. The program has decided the shape of pricing, by the hour for the hours held with the meter stopped at release, and will attach a figure to it when the variables that figure depends on are settled rather than assumed.
- Is the unsolved list the full set of risks?
- No. It is the set of design problems the program has identified and is willing to describe. Items are added as the program learns what else it underestimated, and the program does not claim the list is complete.
KEEP READING