[ why data is different ]

RL dies on the reward function.Data was born with one.

Every other domain burns months deciding what good means. Data already knew: correct is whether the numbers match. What it could never afford was running the check.

binary

the reward: numbers match or not

2

attempts / hour on production

100+

attempts / hour in the environment

4.20%

of the bytes, joins intact

[ 01 the reward function ]

Everywhere else, “correct” is an argument.

In software you need humans writing rubrics. In chat you need preference data and a model trained to imitate it. Months of work before a single useful gradient.

Data skipped all of it. Row counts, sums, null profiles, distributions. The reward function was already sitting in the warehouse, and it's binary. Nobody has to agree on anything.

Software RL
AGENTwrites the patchROLLOUTruns in 1 msREWARD6 months of rubrics

Cheap to run. Nobody can agree what good means.

Data RL
AGENTwrites the modelROLLOUTevery row, every runREWARDthe numbers match

Correct was never in question. Running it was.

/ THE SAME LOOP, CHOKED AT OPPOSITE ENDS/ FIG. 01

[ 02 the rollout ]

Data’s problem was never the reward. It was the bill.

Grading one attempt means running the pipeline. On every row. At production scale a single rollout costs about as much as the job it is checking.

So nobody could afford the second attempt, let alone the 69th. That's the whole reason RL never arrived in data. Not theory, not tooling. Arithmetic.

015304560 min
Full production data2 attempts / hour
attempt 1 · every row
attempt 2 · every row
4.20% environment100+ attempts / hour
↑ 69 · match

50x more attempts, same hour, same agent.

/ WHAT ONE HOUR BUYS/ FIG. 02

[ 03 the environment ]

So we made the rollout a rounding error.

A deterministic hash on the anchor entity, then every row for those customers in every table. Whole customers, full history, joins intact, at 4.20% of the bytes.

Per-customer aggregates stay exact, which is the only reason a pipeline verified here is actually verified.

events218.4B rowsfull history✓ closed
orders3.1B rowsfull history✓ closed
customers41.2M rows4.20% sampled✓ anchor
addresses88.7M rowsfull history✓ closed
catalog12.4M rowscopied whole✓ reference
sandbox4.20% of bytes
schema drift events carried[47]
retired enum values carried[212]
/ ONE SANDBOX, 4.20% OF BYTES/ FIG. 03

[ 04 what it unlocks ]

What a cheap rollout buys

[ more attempts ]

100+ tries instead of 2

The agent stops guessing and starts converging. Failure becomes the mechanism, not the incident.

[ compounding ]

Every run is training data

What one run learns, the next one can use. We're measuring how much, and we'll publish the numbers when they're in.

[ proof ]

Nothing merges on trust

Row counts, aggregates, nulls, distributions. Your engineer reviews evidence, not output.

[ the dare ]

Bring the pipeline your agents keep getting wrong.

The one your team has re-prompted nine times. Point it at the environment and watch it converge. Or watch it miss 68 times and match on attempt 69, which is the same thing.

Bring us the hard one

run log · one pipeline, one hour

  1. attempt 01✕rows · nulls · distΔ 30.4%
  2. attempt 02✕rows · nulls · distΔ 15.6%
  3. attempt 03✕rows · nulls · distΔ 26.3%
  4. ···
  5. attempt 66✕sumsΔ 0.65%
  6. attempt 67✕sumsΔ 0.67%
  7. attempt 68✕distΔ 0.59%
  8. attempt 69✓the numbers matchΔ 0