For engineers who own partner data feeds

Data feeds break.Yours won't stay broken.

When a partner changes their schema, the conforming records keep flowing. The one that broke is quarantined with its reason, and a repair waits on your approval.

See the demo Tell us about your feeds

13 of 13 source fields accounted for in the ruleset below — mapped or declared dropped. No silent drops, ever.

From the demo's authored ruleset — d1-weather v1, as the model wrote it

The explode: nested forecast periods fan out into records

{
  "id": "explode-1",
  "op": "explode",
  "path": "properties.periods"
}

One field mapping: Fahrenheit in, Celsius out, declared

{
  "coerce": {
    "from_unit": "fahrenheit",
    "kind": "unit",
    "to_unit": "celsius"
  },
  "missing": null,
  "on_null": "omit",
  "source": "properties.periods.temperature",
  "target": "temperatureCelsius"
}

Recorded material from the demo's manifest. See it authored in the demo

When a feed drifts

Your pipeline doesn't stop. Your transform gets fixed.

Drift lands mid-run and the run holds. Here is what happens to the record that broke.

The record the gate set asideQuarantined

required field 'precipitationProbability' is missing — expected field 'precipitationProbability' present

{
  "isDaytime": true,
  "startTime": "2026-07-03T06:00:00-05:00",
  "temperatureCelsius": 32.78,
  "weatherDescription": "Mostly Sunny"
}

Recorded from the demo's run — kept whole, reason named, while the rest of the batch kept flowing. Open the failure in the demo

The record is set aside whole, labelled with what failed and why. Everything else keeps flowing.
An agent reads the failure and drafts a repaired ruleset. Deterministic checks vet it before you see it.
You approve, edit, or reject it. Only an approved repair becomes the next pinned version.

The obvious objection

A model never runs your data.

A model reads your schemas and samples once, to write the mapping. After that the engine runs the version you pinned and cannot reach a model at all. That is built into how it runs, not just a policy we promise to keep.

What it writes is a readable mapping, not generated code. So when a repair is proposed, you are reading a few changed lines and deciding, not auditing a program.

Where a model reads, and where it cannot

A model reads — twice, and only here

1 · Authoring, once

It reads your schemas and a few sample records, and writes the mapping.

2 · Healing, on a failure

It reads the one record that broke, and drafts a repair for you to approve.

No model, ever — this is every run

Your records are transformed by the version you pinned. No model call happens here at all; the engine cannot reach one.

The mapping is a versioned document you can read — not a black box you have to trust.

Read the technical detail

Who it's for

Built for feeds you don't control

Partners send data in their own shape, and change it without telling you. Hand-written mapping code makes every new feed days of work and every drift an incident.

The demo walks one real feed end to end from recorded material: authoring, a run, drift landing, the quarantine, and the repair waiting on a decision.

See the demo