It was late 2025, eleven at night, and I wasn't debugging anything. No alert had fired. I was running a distribution query on our fitness engine because something had felt off for a week and I couldn't say what.
Ninety-six percent of the patterns had collapsed into a three-cent band around a fitness score of 0.75. Not a flatline. Not some obvious zero. A SELECT DISTINCT came back with fifty-one values, enough that every check we had passed clean. Fifty-one values, nearly all crammed into the same narrow range. That isn't evolution. That's a classroom where everybody copies the same kid's homework.
That was just the fitness engine. Three more followed. One handler had never fired at all. Another had been writing fresh, plausible, entirely counterfeit numbers for two months while I checked on it most weeks and concluded each time that it was fine. Four dead or faking pipelines, and between them they covered every kind of failure this book describes.
Eighteen thousand tests passed the whole time. Every dashboard was green.
I've developed software for more than 40 years, and I've been building systems that learn from the prediction-outcome loop since 1993. From 1994 to 2004 I did it while running a dairy farm. Cows first, code after.
In 1996 I founded x.hlp Technologies, which sold enterprise learning software to JP Morgan, Shell and NATO among others. It was acquired in 2004, and after two further acquisitions the technology ended up inside SAP. A patent I filed in 2000, published the following year as US20010039552A1, has since been cited by more than fifty patents, from Microsoft, Apple, IBM, Samsung, Nokia and SAP itself among others. The number is there so you can check it.
I've also engineered, built and operated power plants.
Since 2023 I've been building AI-assisted systems at scale: around 1.8 million lines of production code across four complete rebuilds, most of it written by the model rather than by me.
None of that saved me. That is the point of the book.
The failure isn't a competence problem. It's structural, and structural problems need a different kind of check than the ones most of us are running. That's what the book is about, and what the field manual at the back of it is for.
The book names the problem. CleanAim® is what I built to fix it, and what we now build with.
CleanAim® Studio is its fourth generation. We build and maintain AI applications that automate the recurring work of professional firms. The AI prepares the work. The firm's own people do the work with it, decide and sign, and every figure can be checked against its source.
I also run the book's method over other people's systems, as a fixed-scope audit. I'd rather say so here, plainly, than have you find it out later and wonder what else the book was for.
The rest of what I do, and everything else I have built, is at tomkilli.com.