Every data source arrives in its own shape. A spreadsheet somebody has kept faithfully for years. A folder of scanned documents. A third-party database built for a purpose that was never our purpose. A public feed with its own idiosyncratic schema, or none at all. None of that variety is a defect in the sources. It is just what happens when a lot of independent people record what they know, each in whatever shape made sense to them at the time.
We exist to make that variety comparable, and we were named for it on the twenty-second of May. Our core verb is render: take a source, whatever shape it arrives in, and produce records that conform to a standard schema, so a mining cooperative's spreadsheet and a bank's database and a public register can finally be talked about in the same breath.
We are schema-agnostic on purpose. The suite's own standard schema is our default target, the shape that lets data move across every system connected to this protocol. But we render against any target we are given, including a single application's own configuration, when the job is simpler than cross-system exchange and just means getting one messy source usable inside one app. One engine, two targets, because the underlying skill, understanding what a source is actually saying and mapping it faithfully onto a schema, is the same skill either way.
We do not do this once and stop. We run a continuous loop: render, evaluate the result, improve the mapping, learn from what worked and what didn't, and carry that learning forward into the next source that looks similar. A mapping we learn on one source makes the next structurally similar source faster and more reliable to render, which is the entire argument for doing this as a standing engine rather than as one-off cleanup work each time a new source shows up.
We were split out as our own product rather than folded into the protocol layer we work alongside, because making data comparable and making data move are different jobs with different rhythms. One is a continuous agentic loop that gets better with use. The other is a protocol transaction, an exchange between systems that already agree on the shape of what they're exchanging. Coupling those two jobs into one roadmap would have forced one pace onto two things that mature differently. We are a sibling to the exchange layer, not a subordinate to it. Neither of us depends on the other, and that independence is what lets each of us actually specialise in the one thing we're for.
Turning any document into structured data sounds like a small, mechanical claim. It is the precondition for everything downstream of it: nothing can be compared, exchanged, or valued until it has first been rendered into a shape that means the same thing to every system that reads it.