From research to building AI systems, teams and products.

My first group worked on physiological monitoring for firefighter safety: how could we detect risk while someone was working in a physically demanding and dangerous environment?

The first problem I worked on was estimating core body temperature from signals that could be measured externally, using methods such as Kalman filtering. At that point, I was mostly learning how research and applied engineering actually worked. I was definitely learning more than I was contributing.

Then the work became much more end to end.

The group built a prototype to monitor firefighters’ exposure to carbon monoxide: a physical sensor carried with their equipment, measuring CO in the surrounding air, with a system around it to capture, transmit, store and analyze those measurements.

I ended up working across almost the whole chain:

• the electronics, designed with support from more experienced electronics researchers, and the components, which I selected and sourced;
• assembling and soldering the prototype boards, and helping create a custom enclosure;
• Bluetooth Low Energy communication and the Android app that received the measurements, stored them locally and uploaded them to a server;
• the data analysis, including a physiological formula to estimate blood CO exposure from environmental concentration and time exposed.

The embedded firmware that controlled the device itself was written by a colleague who specialized in it.

Building the whole system helped me understand which part of engineering I wanted to stay closest to.

I liked experimenting with hardware, but this project made something pretty clear: software, data and building systems were where I wanted to go deeper.

It was also one of the first times I realised how much I enjoyed owning something end to end instead of disappearing into one tiny part of it.

For the final part of university, I changed research groups inside INESC TEC.

That move was intentional. I wanted to explore Machine Learning properly and figure out whether it was the field I wanted to work in.

My MSc thesis focused on fingerprint presentation attack detection. Many anti-spoofing models worked well once they had already seen examples of the attack materials during training. The harder question was whether a model could detect a spoofed fingerprint made from a material it had never seen before.

Basically: could it spot an attack without having studied that exact trick already?

The work moved through the field step by step:

1. 01Handcrafted image features, turned into tabular datasets
2. 02Classical Machine Learning: SVM, Random Forest, Naive Bayes
3. 03Multilayer perceptrons
4. 04CNNs trained directly on the images
5. 05Pretrained CNNs and transfer learning
6. 06Adversarial training
7. 07Domain adaptationThe direction that worked
8. 08Experiments with GAN-based approaches

The approach that worked best used adversarial techniques for domain adaptation, helping the model generalize beyond the spoof materials it had seen during training.

That research became my first publication and also confirmed that Machine Learning was something I wanted to keep pursuing, just preferably close enough to real systems that the work did not end at the experiment.

Publication

BIOSIG 2020. Main author; presented as a poster.

Thesis

Graded 20/20.

Recognition

Best MSc thesis in its research area at INESC TEC.

Published research (opens in a new tab) ↗

ANOVA provides hardware monitoring for industrial tanks, but not every tank has a sensor. The product I worked on ↗ estimated the levels of unmonitored tanks from monitored tanks that behaved like them.

Historical refill and level patterns were used to identify which tanks were similar, and at runtime the monitored ones helped infer the current state of the ones without sensors. The goal was simple: anticipate refills and reduce the risk of stockouts.

Taking the person out of the loop

The statistical process already existed when I joined. The problem was that every day, someone still had to make it happen, manually.

The project lead would open some FTP servers, download the new sensor files, run the process manually and upload the outputs somewhere else so the downstream systems could pick them up.

My main job was to remove that person from the loop.

I built the pipeline end to end: automated FTP ingestion, the processing flow and automated delivery of the outputs. With the help from the DevOps team, I also set up an Azure VM that started on a schedule, ran the process, handled completion and shut itself down again.

Once the pipeline was stable, I built an internal control center in Python with Tkinter: part dashboard, part backoffice, showing the data, product metrics, errors, logs and operational status.

It also made it much easier to show leadership how the product was performing instead of asking them to trust a process running somewhere in the background.

Later, I started representing the product in conversations with teams in Portugal and elsewhere in Europe about where Machine Learning could improve it. The existing approach was mostly statistical, and those conversations made me realise I wanted more direct exposure to Machine Learning itself.

The role was also quite isolated: most of the work happened one to one, with my closest collaborator in another timezone. So when a contact suggested I apply for a Data Scientist role at iLoF, I did it.

iLoF was developing proprietary technology that combines photonics and AI. Optical signals were collected from biological samples and turned into optical fingerprints: markers associated with properties of those samples. The long-term potential was in detecting and characterizing disease-related and other biological signals.

At the laboratory, photonics and hardware teams collected the signals. My team picked things up from there: taking raw, high-dimensional optical data, turning it into statistical representations and building models on top.

Working directly on the modelling

The work covered signal analysis, statistical feature extraction, classical Machine Learning and deep learning, usually on relatively small datasets.

A lot of the projects were exploratory by design: could we detect a certain biological signal at all? That meant trying different representations, models and validation approaches, often in collaborations with hospitals and other organizations. It was pure research and development, not clinical work.

Stop rebuilding the same workflow

Running lots of small experimental projects meant repeating the same work again and again. So instead of rebuilding the training and evaluation flow every time, I created a shared Python package that standardized the recurring Data Science work across projects, and I became its main maintainer.

It was one of the first times I noticed a pattern that has followed me ever since: if I have to solve the same annoying problem enough times, eventually I will build something so I never have to do it again.

That same instinct produced two other tools.

One was an internal monitoring application for the laboratory hardware. It used statistical behavior in the optical signal to help indicate when certain components were degrading or might need replacing. I wrote the analysis, the monitoring logic and a simple interface that the laboratory team could actually use.

The other, built with the team lead, was an end-to-end demonstration pipeline: incoming data was processed automatically, sent to a model behind an Azure ML endpoint, and the results and system state were stored in a database and exposed through a simple interface. It ran during real demonstrations in the laboratory, which was a nice step up from “here is a notebook, please imagine the rest”.

Everything around the model

Over time, I started getting increasingly interested in the work surrounding the modelling itself.

Outside technical work, I got involved in planning and longer-term technical discussions, presentations, conversations with doctors and technical partners, external events and company pitches. I also supervised internships and an MSc thesis with a meaningful deep learning research component.

I was also part of a multidisciplinary group focused on company culture, where we discussed internal norms, practices and events. That brought me into more regular contact with the CEO and gave me much more exposure to how the company was actually being built: marketing, organization, communication, strategy and how the technology connected to the business around it.

I was not running those areas, but I was becoming increasingly curious about them.

That was probably the biggest thing iLoF gave me.

I joined because I wanted to do more Machine Learning, and I did. But somewhere along the way I found out that I also really enjoyed mentoring people, explaining technical work, thinking about strategy, shaping how teams operate and understanding why we were building something in the first place.

None of that was in the job description, but it all pointed pretty clearly to what came next.