What a design partner would be asked to do

Design-partner intake for E31 Network is not yet open. When it opens, it would involve a small number of teams, and each would be asked to do a specific set of things: describe a real job precisely, engage at the engineering level, run the job when the time comes, and say honestly what went wrong. This article sets out what each of those would mean in practice so that a team can decide, before intake opens, whether it is the kind of team the program is looking for.

Describe a job precisely

The first thing a design partner would be asked for is a job, written out in the form the network uses. The work: what runs, whether a training run, a batch of inference, a processing pass over footage, or a set of simulations. The data: what the job reads and how large it is. The request: how much compute, for how long or until done, and when it must be finished. The output: what should come back.

This is harder than it sounds, and that is the point. Most teams know roughly what they need. A design partner would be asked to know exactly, because the gap between roughly and exactly is where the program expects to learn what a job description is missing. A team that cannot yet describe its job this precisely is not a bad team; it is simply not a design partner yet.

Engage at the engineering level

The program is not looking for a sponsor or a logo. It is looking for engineers who would sit with the design and say where it does not fit their job. That means reading how a job moves through submit, rent, run, output, and release and pointing out where their work does not match. It means saying what their data staging actually looks like, what their job does when it is given less compute than it asked for, and what output format their downstream systems need.

It also means being willing to be told no. Some of what a partner asks for will be real-time work that does not belong on the network, and the program would say so rather than stretch the design. A partner who hears that and reroutes the real-time part to their own systems is more useful than one who argues for an exception.

Run the job for real when the time comes

A design partner would be asked to run the job they described, on the network, when the network is ready for it. Not a toy version and not a demonstration: the actual retraining, the actual footage backlog, the actual simulation sweep, with the actual data. The design intent is to learn from jobs that matter to someone, because those are the jobs that reveal what the design got wrong.

This is also why the program is looking for teams with heavy, bursty AI jobs specifically. A team whose demand is flat or small would not exercise the queue, the scheduling, or the release step in the ways the program needs to see. A team with a real spike in front of it would.

Report what did not work

Finally, a design partner would be asked to say what went wrong. Which part of the job description was ambiguous. Where the staging was slower than the job. Whether the output came back in a form that was usable. Whether the accounting of what was held matched what the team expected to pay for. The program would treat each of these as a finding rather than a complaint.

This is the part of the arrangement that most directly serves the unsolved list. The problems the program has published, getting data to compute, scheduling mixed sizes, knowing what a job must declare, are the problems design partners would be helping to solve. Their findings are the input.

What a design partner would not be asked for

A partner would not be asked for a commitment to buy, a reference, or a quote for the site. There are no rates to agree to, because none are published. There is no form to fill in, because intake is not open. When it opens, the program will say so on the design partners page and nowhere else.

For the list of problems a partner would be helping with, see what we have not solved yet. For why the program is willing to say all of this before it has anything to show, see how the preview decides what to publish.