DEV Community: Giancarlo Vizhnay

Aegis Pulse: Exploring What a Camera Can Tell Us About the Human Body

Giancarlo Vizhnay — Mon, 09 Nov 2026 17:12:12 +0000

What I Built

I've always been curious about how far we can push technology beyond what it was originally designed to do.

We use cameras every day to take pictures, record videos, and make video calls. But what if that same camera could help us understand signals from the human body without needing to wear a device?

That question caught my attention.

When I discovered the Presage SmartSpectra SDK, I wanted to explore what was actually possible. I didn't want to just read about it or run a quick example. I wanted to build something I could interact with, experiment on, and learn from.

That's how Aegis Pulse started.

I built a macOS desktop application using Electron, React, TypeScript, and the SmartSpectra SDK to explore contactless pulse and breathing measurements.

Seeing a heart-rate reading appear on screen was exciting, but what really interested me was everything happening behind that number.

How was the signal developing? Why did some measurements settle faster than others? How much confidence did the SDK have in what it was reporting? And what could I learn by making more of that information visible?

Those questions led me to expand Aegis Pulse into five different views: Live Monitor, Signal Lab, Sessions, Diagnostics, and Settings.

Live Monitor is where I can see pulse, breathing, and how confident the SDK is in those measurements. Signal Lab lets me explore the relative waveforms and watch how confidence changes over time.

I added Sessions because I wanted to look more closely at the measurements collected during a run. Diagnostics came from wanting to understand what was happening behind the scenes, especially frame rates, processing delays, and dropped frames.

Settings brings everything together with camera consent, API-key security, privacy information, and accessibility options.

Each view gave me a different perspective on what the application was doing. And the more I explored it, the more questions I wanted to investigate.

Demo

One of the most rewarding moments was seeing real pulse and breathing measurements appear through an ordinary camera.

I recorded a short, silent demonstration using the actual Aegis Pulse application and SmartSpectra SDK.

In the recording, the pulse reaches approximately 92–93 BPM, while the breathing measurements continue to settle. The application shows that difference instead of treating every reading as equally reliable.

The video also demonstrates the camera being released when I stop the session. The application returns to IDLE, and the preview turns off.

The recording begins with a session already running, so it doesn't include the initial consent or Start clicks. Those controls are explained in the application and shown in the project screenshots.

I covered the camera preview with an opaque panel because I wanted to share the software without showing myself on camera.

Here's the demonstration:

Watch the video on YouTube

Code

Aegis Pulse source code and documentation:

Aegis Pulse on GitHub

I built the application with Electron, React, TypeScript, and the Presage SmartSpectra SDK.

One area I spent quite a bit of time on was keeping the SDK integration separate from the frontend.

I didn't want API credentials exposed directly to the interface, so the SmartSpectra integration runs through Electron's main process, with a restricted IPC layer connecting it to the React application.

The API key is protected using Electron's macOS-backed encryption facilities.

I also spent time building tests for camera permissions, session behavior, credential handling, and application security.

At the time of preparing this submission, the project passes 188 automated tests, along with TypeScript validation, production build checks, and its configured security scan.

The repository includes the original application source, installation instructions, architecture documentation, security notes, and screenshots from real application sessions.

My original code is available under the MIT License. The Presage SDK has its own licensing terms, and developers who want to run Aegis Pulse need their own Presage API key.

How It Responds to Human Signals

This was probably the part of the project I enjoyed exploring the most.

Once a measurement session begins, the camera sends frames through the application's processing pipeline to the SmartSpectra SDK.

The SDK provides pulse, breathing, confidence, and relative waveform information that Aegis Pulse displays in real time.

I didn't want to build an interface that simply showed numbers and made everything look perfect.

Real measurements take time to settle. Lighting, movement, and camera positioning can affect the readings.

During one recording, I watched the pulse measurement become stable while breathing was still preliminary.

That caught my attention because it showed why confidence matters just as much as the number itself.

Rather than hiding that uncertainty, I wanted the application to make it visible.

That's also why I created Signal Lab. It gives me a way to inspect relative pulse and breathing waveforms while following changes in confidence.

These are relative signals from the SDK, not blood-pressure measurements or independently validated clinical waveforms.

I was also curious about what was happening inside the application while those measurements were coming in.

Was the camera delivering frames consistently? Were frames being dropped? How much delay was being introduced as information moved through the application?

That's where Diagnostics became useful.

During one observed session, Aegis Pulse reported approximately 30 accepted frames per second, with 5,140 out of 5,140 frames accepted and an IPC transit p95 of approximately 3 milliseconds.

Those numbers come from that particular session. They aren't a guarantee of performance across different machines.

The physiological readings haven't been independently validated against a medical reference device either.

For me, being able to explore both the signals and the engineering behind them made the project much more interesting.

Prize Categories

I'm submitting Aegis Pulse in the Best Thoughtful Real-World Use category.

I wanted to explore a technology with real-world potential while creating something that people could understand and control.

The goal wasn't simply to show pulse and breathing measurements. I wanted the user to know when the camera was active, see when readings were still settling, and have a clear way to end the session.

I also wanted developers to have visibility into what was happening behind the interface.

To me, thoughtful technology means more than getting something to work. It means being clear about what the system can do, acknowledging its limitations, and giving people control over how they use it.

Consent and Data Handling

Privacy became one of the most important parts of building Aegis Pulse.

Before a measurement session can begin, the application requires explicit camera consent.

Granting consent alone doesn't turn the camera on. Starting a session is a separate action, and the application provides a Stop & release camera control so users can end measurement whenever they choose.

Camera frames are processed in memory rather than being saved as video files by Aegis Pulse.

But there's something important I discovered while reviewing Presage's documentation.

According to Presage's SDK Privacy Policy, the SDK transmits derived physiological measurements, including pulse, breathing, and HRV, along with session metadata, to Presage for its Insights functionality.

The policy states that camera video and images aren't transmitted to Presage.

Disabling optional SDK telemetry does not disable those measurement transfers.

Initially, I thought disabling telemetry meant less information was leaving the device. Reading the privacy documentation more carefully showed me that these were separate behaviors.

That discovery made me revisit the application's consent and privacy information.

I wanted users to understand what happens to their measurements rather than simply assume the system was completely offline.

I haven't independently inspected the SDK's network traffic, so these disclosures are based on Presage's published policy.

For local storage, Aegis Pulse keeps current-session readings and waveforms in memory rather than writing them into its own diagnostic logs. Those logs contain processing counters and timing information.

The API key is handled through Electron's main process and protected using macOS-backed encryption.

Aegis Pulse is intended for general wellness information and engineering exploration. It isn't a medical device, hasn't been clinically validated, and shouldn't be used for diagnosis or treatment.

What I Learned

When I started this project, I thought getting physiological measurements from a camera would be the biggest challenge.

It turned out to be only one part of the experience.

I spent time working through camera permissions, securing credentials, managing SDK sessions, and making sure navigating between views didn't accidentally create another camera session.

I also learned how important it is to test software beyond an automated test suite.

At one point, I needed to confirm that stopping a session actually released the camera. That meant running the application, examining lifecycle logs, and checking the behavior of the camera stream.

Getting those details right took more investigation than I originally expected.

Another important lesson came from reading the SDK's privacy documentation more carefully.

I had made an assumption about telemetry and data transmission that wasn't completely accurate. Once I understood the difference, I corrected the application's privacy disclosures.

That reminded me that part of engineering is being willing to question your assumptions, inspect the evidence, and change something when you discover a better understanding.

Those lessons were just as valuable as getting the first measurements working.

Credits

Aegis Pulse uses the Presage SmartSpectra SDK.

I referenced Presage's documentation and official examples while developing the integration.

The desktop interface, Electron architecture, camera lifecycle controls, diagnostics, session management, and automated tests were developed as part of this project.

Final Thoughts

Aegis Pulse began with a simple question:

What else can we learn from a camera beyond what we can see in an image?

It turned into a much larger exploration of contactless physiological sensing, software architecture, privacy, and real-time system reliability.

There's still plenty I'd like to investigate, especially around measurement accuracy, different hardware, and how this technology might evolve.

But getting from an idea to a functioning desktop application has been a rewarding experience.

Seeing real measurements appear on screen was exciting. Understanding what was happening behind those numbers made it even more interesting.

And that's one of the things I enjoy most about building software.

Every working system opens the door to another question, another experiment, and another opportunity to learn something new.

Neuroscience Evidence Lab: Building a More Reliable Foundation for Scientific Research

Giancarlo Vizhnay — Fri, 06 Nov 2026 23:44:25 +0000

Scientific research depends on evidence. But finding information is only part of the challenge. Understanding where that information comes from, whether its references are accurate, and how different findings connect is just as important.

That's what led me to start building Neuroscience Evidence Lab.

It's an independent software engineering project focused on making scientific research more organized, traceable, and easier to evaluate.

I'm developing it with a simple objective: build software that helps people work with scientific evidence more reliably.

Why I Started This Project

We have access to an enormous amount of scientific information.

Platforms like PubMed, Crossref, and OpenAlex make it possible to discover research across different disciplines. But managing publications, checking references, and connecting evidence to scientific claims can still be complicated.

As a software engineer, I started thinking about how better infrastructure could help address those problems.

Rather than creating another application that simply retrieves information, I wanted to explore a system where research integrity and evidence traceability are part of the foundation.

That's where Neuroscience Evidence Lab began.

What I'm Building

The project focuses on five areas:

1. Research integrity

Helping identify inconsistencies in scientific publication information so researchers can better understand the records they're working with.

2. Evidence traceability

Maintaining clear relationships between scientific claims and the research sources associated with them.

3. Structured research

Organizing publications, references, and evidence in a way that supports more systematic inspection and analysis.

4. Software reliability

Applying validation, automated testing, and careful data handling to reduce avoidable errors.

5. Transparency

Making it easier to distinguish between recorded evidence, unresolved questions, and conclusions that require further scientific evaluation.

The goal isn't to replace researchers or scientific judgment.

It's to create better tools to support the research process.

The Engineering Approach

I'm building Neuroscience Evidence Lab with a technology stack that includes:

Python and FastAPI for backend development
PostgreSQL for structured data storage
React and TypeScript for the user interface
Scientific data integrations for working with research publications

Much of the development effort has gone into building a dependable foundation before expanding the project's features.

That includes organizing the data model, implementing validation, establishing automated tests, and improving how the application handles scientific publication information.

The project currently has working backend functionality, a frontend application, and automated testing infrastructure.

It's still under active development, and there is more work to do before treating it as a public research service.

One Important Lesson

Something I've learned throughout this project is that retrieving information and verifying information are two different problems.

A successful response from a scientific database doesn't necessarily mean every piece of information associated with a publication is consistent.

And correctly identifying a scientific publication doesn't automatically establish that its findings support a particular claim.

Those distinctions have influenced how I'm approaching the engineering.

I want the software to make uncertainty visible rather than create a false sense of certainty.

For a research-focused application, that matters more than simply producing fast results.

Where I'm Taking the Project

My longer-term goal is to explore how evidence-centered software can improve scientific research workflows, particularly in neuroscience and related disciplines.

The next stages involve improving the user experience, expanding real-world validation, and eventually demonstrating complete research workflows.

I'm taking an incremental approach: build, test, evaluate, and improve.

Neuroscience Evidence Lab is an ongoing independent software engineering project. It's not a finished scientific validation service.

As development progresses, I'll share selected milestones, engineering lessons, and demonstrations.

Final Thoughts

One reason I enjoy building software is the opportunity to turn complicated problems into systems that are easier to understand and work with.

Neuroscience Evidence Lab brings together several areas I'm interested in: software architecture, scientific research, data integrity, and reliable infrastructure.

It's an opportunity to keep learning while building something that could eventually be useful to researchers, developers, and students.

I'm interested in hearing from people working with scientific data and research software.

What's the biggest challenge you've encountered when trying to verify, organize, or connect scientific research?

Building Real-World AI Systems: From Local LLMs to Scientific Evidence Verification

Giancarlo Vizhnay — Fri, 06 Nov 2026 18:25:44 +0000

Building Real-World AI Systems

I'm Giancarlo Vizhnay, a software engineer working on AI agents, local-first AI, automation, backend infrastructure, and scientific research tools.

My goal is to build systems that go beyond demonstrations and can eventually operate reliably in real-world environments.

What I'm Working On

Aegis Vision — Computer Vision and Spatial Intelligence

Aegis Vision explores real-time object detection, tracking, spatial measurement, camera calibration, and interactive 3D visualization.

The challenge is connecting computer vision with reliable real-world measurements.

Neuroscience Evidence Lab — Scientific Research Verification

This project focuses on retrieving scientific literature, validating research metadata, and checking identifiers such as DOI and PMID.

I'm exploring how automated research systems can distinguish verified scientific records from mismatched or unreliable references.

SerpentOS — Quantitative Decision Engineering

SerpentOS explores deterministic decision-making, API-based analysis, automated evaluation, and system reliability.

Local-First AI — Running Models on Personal Hardware

I'm also experimenting with local language models, agent orchestration, and model optimization.

The objective is to understand how much AI capability can run locally while maintaining control over infrastructure, execution, and data.

My Engineering Philosophy

I primarily work with Python, TypeScript, FastAPI, React, PostgreSQL, and related infrastructure tools.

My priorities are:

Reliable and maintainable architecture
Reproducible experiments
Security and controlled execution
Measurable performance
Automated testing
Practical deployment

I believe building reliable AI software requires more than connecting an application to a language model.

What I'll Share Here

I'll document engineering decisions, technical experiments, architecture, debugging, performance results, and lessons from building these projects.

Some experiments will succeed. Others will reveal limitations worth understanding.

My intention is to share the actual engineering process.

You can follow my projects on GitHub.

[Boost]

Giancarlo Vizhnay — Thu, 05 Nov 2026 18:59:10 +0000

dev.to staff for The DEV Team

Jul 10 '24

Join Us For The First Community Smart Contract Challenge With $50,000 In Prizes!

#devchallenge #stellarchallenge #web3 #blockchain

447

9 min read