In 2008, Mercer brought me in to lead a new project for their Health and Benefits division: build a more efficient platform to process their clients' employee data. I started with what felt like an obvious question. Mercer helped found HR-XML, the standards body created to define a common format for exactly this kind of data. Could we require clients to send us their data in the standard Mercer helped write?
The client relationship managers laughed. Their clients had zero interest in investing in new data outputs, especially in this newfangled XML structure that many of their systems didn't even support. Each client already had its own archaic format for sharing demographic, payroll, and benefits data, and that was that. We would take what we were given and we'd like it.
Could we at least make sure the data arrived clean?
They laughed harder. Did we not hear the part about being happy with what we could get?
We added it all to the requirements list. No standard inputs: check. Build our own validations: check. The list kept growing, and it was taking our budget with it.
Flexing the standard for benefits data interoperability
This was an expensive problem. Mercer spent six figures a year ingesting client files and passing the data along to the bevy of internal systems that served those clients' employees, and every sale added several new feeds to the pile. The current solution was unsustainable, but without standardization I wasn't sure how I was going to do any better.
But then I realized: the data was standard, it just looked different. Every company needs the same information to track and take care of their employees, so if we could get past the presentation we could manage that core data set. So we took a new approach: standardized in the middle, customized at the edges. We stopped fighting for a single delivery format and focused on getting it to a standard data structure as quickly as possible. The platform embraced variety in how the data arrived and held the line on what the data had to be once it landed. Flexible where necessary, strict where it mattered.
After some fervent debates, we settled on an architecture that worked. We called it DataMan. It cut Mercer's operational load in half while letting them say yes to more clients, and ten years later it was still in place, serving a sprawling empire of benefit, pension, and healthcare data.
Refine, repeat, relief
I built that platform twice more. Reed Group needed one, and the same lessons held: standard in the middle, customized at the edges, validate where and when it matters, don't fight the format. So when it came time to build the Data Nexus at Dart Health, I already knew what we needed to do. By the third time around, you get to skip most of the debates and say, "Trust me."
But now we have AI. In 2008, flexibility was expensive: every new source meant manual mapping and data analysis work for an implementation team. AI collapsed that cost. The Data Nexus supports any format a source can produce, and we map a new one in less than a day. Our validation rules stay strict where accuracy matters, wrapped in AI-powered fuzzy logic and matching that handles the variations a rigid rule would kick out. And when our team finds a new pattern, a human-in-the-loop feedback process folds it into the AI's training automatically, so the platform catches and fixes it on its own the next time it shows up.
I've written before that AI alone won't solve this industry's data problem. You can't vibe code your way to a sustainable solution, and the incentives that produced all those client formats in 2008 are alive and well in 2026. But AI working inside an architecture that already expects the chaos dramatically reduces the wear and tear on your team.
Eighteen years later, I'm finally building what those client relationship managers were asking for: a platform that takes what it's given and likes it.
