The day the data refused to cooperate
The banknotes were filthier than anyone had warned me. I was trying to identify cocaine contamination on circulated currency for my undergraduate dissertation at FURB, and the gas chromatography-mass spectrometry system was giving me noise where I needed signal. The samples carried far more organic interference than the literature had prepared me for, and the extraction solvent I had chosen, the one that should have worked, wasn't pulling clean results.
There were at least three moments where I could have stopped. I could have written up what I had, noise and all, and called it an inherent limitation of the matrix. I could have nudged the baseline integration toward the answer I wanted and moved on to graduation. Forcing a result is always available to you in science. It is the easiest thing in the world.
Instead, I changed the solvent system to a more selective chloroform-methanol mixture. Then I adjusted the GC-MS oven temperature programme, slowing the ramp to separate the target peaks from the background interference. When literature data still wasn't enough, I contacted the forensic police to obtain a purer reference sample for validation. It took longer, it was frustrating, and somewhere in that process I learned the thing that has shaped everything I've done since: being determined doesn't mean forcing the result you want. It means refusing to claim one the evidence hasn't earned.
From chemistry to AI
I don't run chromatographs anymore. I build AI systems: production-ready retrieval pipelines, large language models, and the architecture that now sits between people and critical decisions. As a CTO and founding engineer, the tools I use look entirely different from a chemistry lab. The discipline turned out to be identical.
I didn't change who I am when I moved from chemistry to systems analysis and then to AI. I changed the medium in which I apply the same standards.
Here is what the two worlds share. A dirty sample can produce a clean-looking peak that means absolutely nothing. A language model can produce a fluent, confident answer that is just as empty. In both cases, the danger isn't an obvious, crashing error; it is a highly plausible output that hides missing evidence.
The hardest problem I work on in software isn't making a system sound intelligent. It's making it honest about what it doesn't know. In my engineering practice, I treat every LLM output not as a definitive answer, but as a hypothesis that requires programmatic evaluation, guardrails, and rigorous evaluation frameworks to flag when the system is simply filling the silence with syntax.
Why this matters
This stopped being abstract for me a long time ago. I know what it feels like to sit in a clinic holding a folder of mismatched paper records, explaining for the fourth time to a specialist that a symptom isn't an isolated event but part of a systemic pattern. Living with Autism, ADHD, EDS, and POTS means knowing from the inside how much invisible, heavy labour a fragmented system pushes onto the people it is supposed to help, usually the exact people with the least energy to spare.
When a digital health tool assumes a stable, predictable, consistent user, it quietly excludes everyone whose cognitive or physical capacity changes from one Tuesday to the next. That isn't an edge case. For millions of people, a fluctuating reality is the only reality there is.
So this is the work I want to do. AI for the people downstream of clinical decisions, built for fluctuating bodies and minds rather than an imagined average user. I want to build systems that adapt to the person instead of demanding that a vulnerable person distort themselves to adapt to the software. We need tools that are honest about uncertainty, because in healthcare, a confident wrong answer is a dangerous thing.
The next step
This year, I am moving to the UK to begin an MSc in Human-Centred AI at Newcastle University as a Spärck AI Scholar, to go deeper into exactly this domain. For me, this transition isn't about leaving my engineering work behind, but about scaling the technical architecture I've spent years developing toward deeply human vulnerabilities.
The dissertation in that chemistry lab taught me to earn a result before claiming it. Everything since has been the same lesson in a different medium. I care about this because I have been on both sides of the glass: the scientist refusing to force a conclusion, and the patient on the receiving end of systems that forced theirs.
The people most affected by how these systems fail can also be among the ones who redesign them. That's the work. That's why I'm here.