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 clean-up I had planned, the step that should have removed it, did not work: it retained the cocaine itself and left the lipids behind.
I could have written the study up as though the method had worked. Forcing a result is always available to you in science. It is the easiest thing in the world.
I extracted with acetonitrile throughout, and I had compared two GC temperature programmes and chosen the faster. Larger elution volumes, nitrogen concentration and cold precipitation did not rescue the clean-up, and with no reference standard I could not test how much cocaine I was recovering. So the study became qualitative: I could say that cocaine was there, and not how much. I treated the compounds extracted alongside it as data, and their correlations grouped the city's areas into three chemical profiles, which I offered as a hypothesis rather than a conclusion. 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 software, including retrieval-augmented generation systems and the evaluation around them. As an engineer and, most recently, a CTO, I used tools that 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 evaluation: test sets, rubric scoring and regression checks that 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 many 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
In 2026 I moved 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.