Skip to content

OrbitalProof · AI-cluster networking

An Ultra Ethernet recovery design, proved in a model

A machine-checked proof, in the lab’s one small model, that its design for the loss-recovery step of Ultra Ethernet’s ordered-delivery mode (the step that deals with data that has gone missing) never passes data on out of sequence order, or twice; it is about ordering, not delivery.

Who did this. The lab’s AI agents did the research and engineering. Nick Harris, founder. CTO of VivaMed BioPharma; co-founder of MedSim.ai, FastRead.io and Formulai. The lab’s track record.

What we showed

four checking tools agree

that in the lab’s one model (only one of them without a size limit) its recovery design never passes data on out of sequence order, or twice. It shows this design meets the standard’s rule; it does not show the standard requires this particular design.

Limit.
A result in one small model, not a legal opinion or a claim that the design is essential to the standard. The model has no lost-data resend, and no receiver in it is guaranteed to make progress, so the rule could be met by delivering nothing: the proof is about ordering, not delivery. All four tools check the same model.

The problem

A designer of network cards that use the ordered-delivery mode of the new Ultra Ethernet standard wants machine-checked evidence that a given design for the loss-recovery step (the step that deals with data that has gone missing) keeps the standard’s rule that data leave in sequence order.

What it means for a buyer

If you build or test Ultra Ethernet network cards that use its ordered-delivery mode: machine-checked evidence that this design for the loss-recovery step keeps the standard’s ordering rule, in the lab’s one model. It shows the design meets the rule; the standard allows other designs that also meet it, so it is not a reason every implementer must use this one.

Who we expect would buy

Teams we expect would care (no customer or pilot yet): makers of network cards, switches and chips for artificial-intelligence data-centre networks implementing the Ultra Ethernet standard.

Why now

The Ultra Ethernet Consortium published version 1.0.2 of its specification, dated 2026-01-28. The rule this result checks is one sentence of it: in the ordered delivery mode, data must be delivered in the order of their sequence numbers.

Why you can trust the check

Four checking tools confirm the property, but all four read the lab’s single model of the standard, so one modelling mistake would pass all four. A buyer would want the same rule checked in a model they wrote themselves.

No outside firm has audited it. How this result’s check works, step by step.

What this does not show yet

  • It is a result in one small formal model. It is not a legal opinion, and not a claim that the design is essential to the standard; no professional opinion has been obtained.
  • It runs one way only: the standard’s words do not require this design. In the same model, 39 different compliant receivers do without it.
  • It is about ordering, not delivery: the model has no lost-data resend, and no receiver in it is guaranteed to make progress. A receiver that delivered nothing would also satisfy the rule.
  • Only the ordered-delivery mode of the standard is modelled, and the state spaces are small. Two of the four checking tools were run only on a small version of the model, with two pieces of data over two paths. Only one of the four is unbounded: it is not limited to a small fixed model size, as the other three are. All four check the same model, so a modelling mistake would pass all four together.

Prior work

Named in the lab’s prior-art search for this result, and credited here.

The exact wording, for a technical reader

The lab’s own sentences and figures for this result, word for word, its limits in plain words where the lab’s text cannot be reprinted: An Ultra Ethernet recovery design, proved in a model, exact wording.

Check it yourself

On the blog

All resultsContact / M&A

How we show numbers

Every number on this site links to the file it comes from. How each result is checked

  • We never show a number before its file has loaded.
  • A question we have not checked yet is marked as unchecked.
  • A check that found nothing says so.
  • A file with no value for a question says so.
  • A number whose file is missing or has changed is not shown.
  • Two files that disagree about what a number describes are both flagged.
  • A number from too few samples shows its sample size.
  • Two files that give different values are both shown.
  • A file we cannot publish is listed by its fingerprint only.
  • A measurement more than a week old shows its age.
  • A question that does not apply to a page is left off it.
  • A measurement whose program failed is shown as failed.