Why the preview publishes before it ships

E31 Network has a public website, a published design, and a list of things it has not figured out, and it cannot yet run a job. That is an unusual order. The more common sequence is to build quietly, launch loudly, and discover afterward what the design got wrong. The program chose to publish first, and this article explains the reasoning.

The short version is that the design is the thing the program most wants feedback on, and a design nobody can read gets no feedback.

What the preview publishes

The site publishes the model: a job as the unit, declared as work, data, request, and output. It publishes the five steps a job is designed to pass through and which of them are paid. It publishes the test for whether a workload belongs, which is whether it can wait for a queue. It publishes the list of workloads that fit and the kinds that do not.

It also publishes a list titled, more or less, what we haven't solved yet. Getting large datasets to where the compute is. Scheduling mixed job sizes fairly. Where the capacity comes from. Exactly what a job must declare to be scheduled well. These are not caveats hidden in a footer. They are a section of the site, maintained as the design matures.

What it does not publish is anything that would be a claim. No rates. No performance figures. No customers, because there are none. No certifications. No delivery language. The articles in this library follow the same rule, and when a detail is not settled they say so.

Candor as a design tool

A design that cannot be challenged before it is built will be challenged after, by the people who try to use it. The preview moves that challenge earlier. A team with a backlog of footage can read the life of a job and decide whether the sequence fits how they work. A team with long training runs can read what happens when a job fails and see that partial output is an open question, and know to ask about it.

This only works if the published design is honest. A preview that described a finished scheduler, a settled retention policy, and a solved data-movement problem would be read as a launch, and its readers would judge it as one. A preview that says the scheduling policy is unsettled invites the reader to think about scheduling policy. The candor is what makes the document useful.

What the unsolved list is for

The list of unsolved problems does three things. It tells a reader what not to assume. It tells a prospective design partner where their engineering judgment would be useful. And it keeps the program honest, because a problem that has been published as open has to be either solved or kept on the list.

The articles in this library are written against that list. Where an article touches an open problem, it names it as open. Where a reader might expect a detail the program has not published, the article says the detail is not yet published rather than fill the gap. This is slower reading than a confident brochure, and it is the point.

What publishing is not

Publishing a design is not shipping a product. No job can be submitted. The meter described across this library has not started for anyone. No rates exist, and any figure a reader encounters elsewhere did not come from the program. Design-partner intake is not open, and the design partners page says so directly.

Publishing is also not a promise about what will ship. The five steps and the job model are settled enough to describe. The details are expected to change as the open problems are worked through, and the site will be updated as they do. A reader who returns later should expect some articles to have moved from "not yet published" to a published answer, and should expect the unsolved list to have changed shape. The companion piece on what is not yet open lists exactly what a reader cannot do today and what they can.

For the design itself, how it works is the shortest summary, and about says who is building it and why.