In this series, we are looking at a complex XML conversion project from 2015 through today's lens. The previous documents described what such a project needs: small issues, revoke and specialisation, a second opinion from an LLM, and provenance underneath it all. This document is about building it.
In 2015, writing software was not for the faint of heart. Commercial software was usually expensive and slow to change, because you depended on the vendor's roadmap. Open source software existed and could be of high quality, but it often came with installation hassles, and it was not easy to change either for "normal" organisations. A team that wanted something better would spend weeks or even months specifying, selecting and negotiating with a vendor. As these kinds of systems didn't score high on procurement's priority list, the net result was often a witches' brew of Office tools with whatever specialised software a team could get their hands on.
In 2026, coding agents have completely changed the landscape. What used to cost teams years can now be done by individuals in months. A system like this is now within reach for everyone, not just organisations that could commission one.
That moves the hard part. Being able to build something rapidly doesn't automatically make it useful. If you don't know what you're doing, you will just fail faster. The challenge is now to design the system, and the implementation will follow. Above all, the design must get the core right. Getting the core functions wrong is like building a house with a wobbly foundation. It might not survive the first real storm.
This is why going through the 2015 conversion project was so useful. To a certain degree, revisiting the conversion was the design work. In 2015, we did not have that luxury. What follows is the system that came out of it. A screencast demo shows how it works.
There are many, many ways to build a system like this. In this specific case, two choices were made that shape almost everything you're about to see, so they're worth flagging before the demo.
The first is that this is a command-line tool, not a web app. In 2026 that might look like a step backwards, but it's a deliberate choice. A command-line interface (CLI) exposes and enforces a set of commands, options and flags. Power users know and love command-line interfaces because they make them more productive. But now the LLM can help everyone else. By carefully feeding relevant parts of the CLI documentation into the LLM request context, it can help convert natural language into real commands, thereby helping non-power users become more productive. With a capable model it works remarkably well and it is something that will be shown in an in-depth screencast.
The second is that the heavy lifting happens on the filesystem, not in a database. There are good reasons for this, mostly to do with the provenance requirements from earlier, but they don't matter for the walkthrough. If you're curious, the FAQ makes the case. Metadata and queries run against SQLite indexes, which are derived from the event log and can be rebuilt from it at any time.
The first demo walks through the basic flow. It starts with works and issues: the documents in the collection, and the problems found in them. Then it takes one issue and the transform that fixes it, and tests it twice: first without an LLM, then with a prompt that asks an LLM for a second opinion on each change. Finally, the issue is approved and applied to the collection.
The demo starts with a web interface, which is read-only. The split is deliberate: you explore the corpus, the issues and the history in a browser, and anything that changes a document happens on the command line, where there is an actor and an approval to answer to.
Watch for four moments, because they are the design decisions from earlier doing real work. The first test reports whether the text survived the transform, character for character, and it is strict enough to complain about a changed space. The second test puts every change to the LLM, and of all of them, it flags one: look again. That one case is where a person's attention goes. The apply is refused until somebody has approved the issue. And when the change lands, the state the document had before is still there in its log, beside the new one: nothing is overwritten, ever.
With that out of the way, let's watch it work.
Apart from the second opinion, this demo leaves the LLM features that we've discussed earlier aside. This was on purpose. The next document has one more screencast, where an LLM helps from the interactive mode.
Do you hold a large XML collection, and have good reasons to put AI to work on it, but no safe way to begin? Here is how we would work together. It starts with an hour online, no charge: we look at your own documents, and you see the system running on them.