Gyre Data Engine

You already have robot demonstration data.
We rebuild it so the same policy gets better — and we measure how much.

No new teleoperation. No new hardware. Your data stays on your side. You see the number before you pay for it.

STEP 1

You train your policy on your data. That success rate is the baseline, and it stays fixed.

STEP 2

We rebuild the dataset — same tasks, same robot, same episode count. Then the identical policy is retrained on it.

STEP 3

Both models run the same task suite. The difference in success rate is the product, and it is what you are billed on.

A different data scaling law.

Every robot policy climbs with more demonstrations — that is the horizontal axis, and it is the expensive one. We move the same climb onto a higher curve, so each episode you already own is worth more.

1.5×

the episodes the original pipeline needs to reach what our model reaches — about 570 more demonstrations, uncollected.

+6.4pts

of task success added at the same episode count, where the effect is strongest — overwhelming, not marginal.

new demonstrations you have to collect, and no change to your robot, your policy or your training code.

Measured, not modelled: four data scales, two datasets, 1,400 rollouts across 28 tasks at every point — 11,200 robot episodes in total. Identical architecture, schedule and seed protocol; the dataset is the only thing that differs. The chart covers the range above the crossing point; below it the effect reverses, which is the first question answered below.

Three we answer with a measurement, not an opinion.

“We have a few thousand demonstrations. Should we collect more, or is there something valuable in what we already have?”

A · what we measure

We don't guess. We find the turn.

Every corpus has a point where more of the same stops paying and rebuilding starts.

That point is not a rule of thumb — it moves with your tasks, your robot and how the data was collected. So we locate it on your data and tell you which side of it you are sitting on, before you commit to anything.

Below the turn we would make your policy worse, and we will say so — collect first. Above it, the episodes you already own are worth more than they are being asked to do. The deliverable is knowing which, and by how much.

“Should we add depth, pointmaps or learn 3D representations to our policy?”

A · measured

The 3D is already inside the data.

Our synthesis fuses the geometry in, so the policy learns structure without ever being shown depth.

We tested it the hard way: we handed the competing condition the original data plus a depth-prediction stream, and it still finished behind our data carrying no extra stream at all. Bolting a 3D head onto ours adds nothing — the information is already in there, so all that is left is its compute cost.

Where 3D does earn its keep is crossing domains — sim-to-real, a new camera, a different rig — because geometry is the part that survives the move. That is where we would spend it, and we would measure it there too rather than assume it.

“Our tasks are contact-heavy — insertion, wiping, lifting. Would a touch signal help where vision doesn't?”

Running now

The engine goes looking for what the data is missing.

We don't pick the modality. It proposes one, builds it, and proves it carries information before training starts.

Touch is the current candidate: the signal predicts what the gripper is about to touch, not what it feels now. Every check it had to clear was written down in advance — a null result on a badly built signal teaches nobody anything.

And we are testing it below the turn, in the small-data region where rebuilding alone loses. If a missing modality pays anywhere, it has to pay there. That is the whole point of the experiment, and it is running now.

Three teams, one question each.

01 · Hardware

Robot hardware teams

You need a collection and modelling strategy that gets a task working in the real world — not a bigger corpus.

02 · Real2sim2real

Real2sim2real teams

You need each synthesis pass to add to the last, measurably — instead of quietly subtracting.

03 · Collection

Robot data collection teams

You need a quality report to hand your customer — graded on what episodes do to a model, not on how long they ran.

Tell us what you'd want measured.

One question, on your data, with the comparison fixed before we start.

You already have robot demonstration data. We rebuild it so the same policy gets better — and we measure how much.