Re:Earth Flow was eighteen months in the making when we presented it here last year: a visual, node-based ETL engine for geospatial data, built primarily against Japan's PLATEAU 3D city model. Like most projects on a deadline with a small team, we shipped fast, and we leaned heavily on AI assistance to do it. This talk is about the year that followed — the one where we read our own work back.

The same decision turned up at three layers of the stack. The geometry core is being replaced with a unified model, migrated action by action behind a feature flag rather than on a long-lived branch. The expression language that users write inline in their workflows was rebuilt from scratch instead of patched further. And every one of our 164 workflow actions now has to meet a written standard covering naming, parameters, port conventions, and how failures are routed rather than dropped — with 74 audited and visible today, the remaining 90 hidden behind a server-side gate until each has been through the same review, then brought back batch by batch.

I'll walk through that third one end to end: what a standard for a workflow action actually needs to say, the bugs an audit finds that a passing test suite doesn't — parameters the schema advertises that the code never applies, names that promise more than the implementation delivers — and why writing the standard down is what made the rest of the work delegable at all. The honest version of the AI story isn't that we stopped using it; it's that we learned which decisions it shouldn't be making.

The talk closes with a live demo on PLATEAU data of the tooling that makes this possible: inspecting feature data at any port mid-pipeline, checking attribute schemas before a run, viewing CityGML LOD geometry in the browser, and re-running from a selected node against cached upstream results. You can't hold a standard on a pipeline you can't see inside.

Takeaways: what to specify before delegating implementation work at scale; why hiding functionality can be a better release strategy than shipping it unreviewed; a concrete checklist for evaluating the transformer library of any ETL tool.

Who this is for: maintainers of geospatial tooling, anyone working with CityGML or PLATEAU data, and anyone currently deciding how much of their codebase to hand to AI.