March 11, 2026
Today we attended a seminar on Requirements Engineering at IST — “From the User’s Voice to the Technical Specifications of the Prototype” — led by two guest speakers with hands-on experience building hardware-software products: Rúben Oliveira, founder of Vision Volt, and Diogo Henriques, founder of Genoa Spark. Their practical perspective gave us a valuable outside view on where CosmoMeter stands and where it needs to go.
Starting with the Hardware
On the microprocessor side, the guidance was clear: for the MVP, prioritise something fast, easy to program — Arduino or MicroPython compatible — and capable of lasting at least 8 hours to cover a full flight. Ease of programming and accessibility matter more than optimisation at this stage.
Why Not Just Use a Regular Dosimeter?
A fair challenge was raised: why are we building this at all when dosimeters already exist? The answer lies in context. Standard dosimeters are used in hospitals and nuclear facilities by trained technicians — they’re not designed for aviation environments, nor do they provide the kind of real-time, flight-contextualised data that makes the information actionable for crew. That’s precisely where our value lies.
Where the Real Value Is
The seminar reinforced something important: our chain of value isn’t just the radiation measurement itself — it’s the real-time data and, crucially, how we present it. A number on a screen means little without context. The way we visualise and communicate exposure data to crew is what will set CosmoMeter apart.
Differentiation Through Altitude Correlation
One particularly interesting suggestion: correlating radiation readings with altitude data. This would allow us to show not just how much radiation was detected, but when and at what flight phase — adding a layer of insight that a standalone dosimeter simply cannot offer.
Making the Most of What We Already Have
A sharp question was also raised: what other data can we draw from sources already available to us, without needing to pull from additional external systems? This is a constraint worth designing around — keeping the device self-contained and the data pipeline as simple as possible while still delivering meaningful output.