Egghead: Chubb's Hackathon Challenge

I participated in the 2026 Stevens Business + AI Hackathon with my friend. This was my first hackathon, so building and presenting an AI model on a short timescale was both a lot of fun and a great learning experience.

Teams were tasked with building an AI model in 6 hours to tackle challenges given by the event's company sponsors. My team, the Eggheads, decided to approach Chubb's challenge.

Chubb wanted an early warning system to detect emerging global risks before they impact the world. By monitoring public news and bulletin services, the warning system would be able to give clear, actionable alerts to keep insurance companies ahead of the game.

My team chose to start with a small scope and focus on disease outbreak prediction. By building a robust, scalable design, our model could then be expanded to whatever global systems a company would want to track.

We architected a system where an LLM dynamically extracted events from the WHO disease outbreak bulletin and fed them into an EPI model. From there, the severity of each event was tracked, and, if the score was high enough, the LLM produced an alert detailing the disease and its predicted impact.

Our showcase involved a backtest of taking real bulletins from the end of 2019 into January of 2020. Given reports on the spread of pneumonia in Wuhan, China, an alert was raised. The alert said that this disease was spreading quickly and should be monitored. In reality, this pneumonia outbreak was the beginning of Covid.

A global alert came from Dr. Zhong Nanshanon Jan 20, 2020. Our model raised an alert starting on a bulletin from Jan 11, 2020. This 9-day difference can lead to huge impacts on how companies respond to a global crisis. By seeing a crisis before its impacts, a reactive response becomes a proactive response.

Although this backtest was limited in scope, it demonstrated the potential of the framework we had developed.

Designing Extraordinary Magnetoresistance (EMR) Sensors

EMR devices can detect very weak changes in magnetic fields, having applications in fields ranging from biomedical diagnostics to dense data storage.

However, these microscopic devices are expensive to manufacture, requiring expensive materials such as gold and advanced fabrication equipment. Testing for new designs, especially in broad design spaces such as branching structures, is slow and inefficient.

Using machine learning, I was able to predict highly sensitive EMR designs, narrowing down the search space significantly. I then presented my work at the 2026 Stevens Undergraduate Research Symposium.

Under Dr. Eui-Hyeok Yang, work was split between two teams: the COMSOL Simulation team and the AI Development team. COMSOL simulated different designs and geometries, and I used this data to train a surrogate model (XGBoost) capable of taking a device's geometry and predicting its sensitivity.

From there, Bayesian optimization was used to effectively work backwards. The optimization process would find locally optimal designs, and then output the geometry parameters for that design. Through this method, highly sensitive EMR designs could be identified efficiently.

For the sake of validation, the model was only trained on disc, bar, and off-center disc EMR designs. These design branches have been heavily researched, so it was easy to compare my model's outputs to existing designs and validate the model. However, the framework developed can be extended to more novel applications such as branching structures.

A major learning point was in managing what data the model sees. In training, the COMSOL datasets included parameters such as magnetic field and resistance. However, both values are used to calculate a device's sensitivity, which led to leakage in my model's training. By giving my model a shortcut to the answer, predictions could be made for the wrong reasons.

I was able to catch this issue when performing SHAP analysis on the model and seeing those fields being heavily favored. Future work on this project would focus on controlling the information the model sees to force it to make stronger and more nuanced relationships between device geometries.

HeraHealth Postpartum Hemorrhage Tracker

Today, 200 mothers worldwide will die from postpartum hemorrhaging, the leading cause of maternal deaths. This excessive bleeding after childbirth will cause 70,000 deaths this year, and it remains one of the leading and most preventable causes of maternal death.

HeraHealth is determined to fight this statistic and help new mothers.

For my senior capstone project at Stevens, I had the pleasure to work with HeraHealth on this mission. I worked with a team of 6 to design the HeraHealth PPH Tracking app.

With the app, any smartphone can be used to upload pictures of menstrual pads to be analyzed by our AI model. The model can then, in seconds, closely estimate the amount of blood loss on the pad and whether or not immediate intervention is needed. Medical staff using the app can sync with their patients to track blood loss and know when intervention is needed.

We finetuned Meta's DINOv3 computer visionmodel to serve as the app's blood loss detection system.

Training involved using a custom-made dataset of menstrual pad images with varying blood loss. To further expand our dataset and improve model robustness, we employed data augmentation techniques. A key motivation behind the augmentation was to also emulate photos that would be submitted by mothers, so we implement different lighting, blur, noise, and other poor conditions in our augmentation.

Since the PPH app is classified as a medical device (SAMD), we had to adhere to strict guidelines and perform extensive validation on our work.

Much of my time was spent writing documentation describing the app's design and alignment with international standards such as the ISO and IEC. Validating the app and backend infrastructure via test cases was equally important, especially since users' sensitive medical data would be stored on their accounts.

We presented our project at the Stevens Innovation Expo 2026 at the end of the school year.

As my team ended their time with HeraHealth, the app was making significant progress towards its full release. 4 hospitals, including one in Kenya, piloted a demo build of the app to begin the feedback process. This was also a major step in the app's FDA approval process, acting as one of the last major barriers to full release for the startup.

PECO: Peer Support Coach

Millions of people worldwide suffer from mental health issues, yet access to professional support is limited. Many turn to online resources such as 7 Cups for support, but this comes from non-professional volunteers.

While their intentions are good, untrained volunteers may end up not helping or even harming those seeking support. A safe, scalable solution to train these volunteers can cause a significant improvement to the quality of support seekers receive.

Under the mentorship of Dr. Sang Won Bae and Dr. Rahul Islam, I helped design PECO, an AI-powered mental health support coaching system and presented the system at the Stevens Next-Gen Healthcare Innovators Symposium 2025.

PECO (AI-Powered PEer COaching System) is a training platform designed to strengthen the skills of peer supporters. Users will have a conversation with a simulated support seeker, and as they do, they will receive live feedback telling them how to improve their responses.

The simulated seeker is built upon Patient-Ψ, a large language model (LLM) framework that employs Cognitive Conceptualization Profiles to generate realistic mental health patients in varied scenarios. When starting a conversation with these simulated seekers, users will experience a wide range of personalities and traits, such as hostile or verbose, giving them extensive practice in handling different situations.

As the conversation progresses, FIDO (Feedback for Improving DialOgue) reads the user's responses and evaluates them based on professional support strategies. From there, FIDO gives feedback on how to improve the support messages, coaching the user as they practice. FIDO is a custom model fine-tuned on Meta's LLaMA 4 Scout model.

FIDO (Feedback for Improving DialOgue). FIDO provides indirect, descriptive feedback that highlights opportunities for improvement while encouraging users to revise their own responses. This reflective feedback style is intended to preserve the user's voice and foster active learning.

This was my first true AI project, and the biggest lesson I learned is that asking for help is the best way to learn. The biggest leaps of progress I made were always after I asked others for advice, either from my advisors or from experts I approached myself.

The advice I remember best is a graduate student teaching me about RAG pipeline design. It really helped me understand how the architecture of the AI system is just as important as the models you use. Although we eventually chose not to use RAG pipeline in the final system, the insights I gained from researching it helped me with the rest of the project.

Barbusoft 9000

In a project for my Computer Architecture and Organization course at Stevens Institute of Technology, I was assigned with creating a custom CPU from scratch.

Using Logism Pro, I was able to make a CPU with 4 registers, an accessible RAM for data, and a display to show values.

I also created an Assembly language that could be compiled into binary code and be executed by the CPU.

It was a fun challenge creating as much functionality as possible with basic instructions. I assigned only 16 bits to each instruction, yet still had an addition, subtraction, loading, storing, displaying, and setting function for a user to implement in their programs. The CPU allowed for both the use of 2 registers or a register and a 4-bit immediate number for its instructions, and the user could even display register values or immediate numbers.

The CPU also had a RAM that was accessible by the program. Register values could be stored at specified addresses in the RAM, and data could also be retrieved from the RAM and stored in registers. The instructions for a program were stored in a separate RAM, and a program counter would automatically iterate through the stored instructions until it reach an empty instruction. At that point, the CPU would automatically stay at that empty instruction to end the program.

The user would be able to write an assembly program, then compile it using a compiler that I wrote in Python. The compiler converted a custom .barb assembly file into a hexadecimal image readable by the CPU, and the compiler allowed for comments, whitespace, and empty lines.

I also made a manual for the CPU to help others understand and write programs for it. It gets into the grittier details of how the CPU works and how one can write, compile, and run code for it. Feel free to give it a read by downloading the manual.

I was able to make the CPU, assembly language, and compiler in a day, and I am very proud of the result.

I've spent a fair bit of time just writing custom programs for the CPU and watching it do its thing. Assembly becomes a lot more fun when you're the one who designed it!

Climate Reality Gateway

I was an involved environmental activist at my high school, and so I was invited to join the Climate Reality NJ Youth Chapter.

After talking about my coding hobby, they quickly arranged for me to build a website for their chapter.

Effectively, the website was meant to be a database full of articles for teachers and students. Teachers would be given learning plans and student would be given educational reading on environmental issues. The most difficult part was this: every member had to be able to go onto the website, write an article, and post it onto the website to be accessed. I had to find a secure yet user-friendly way for my teammates to write these articles with, and this took me some time to figure out.

I eventually settled on TinyMCE, a rich text editor than can easily be implemented into a website. A teammate could go onto an article creation page, use TinyMCE to write the article (including content such as images and videos), add a title, tags, etc., then send it to the server as an html file. The server would then take this html file and store it in the porper folder (There was a folder tree of teachers and students, and each tree was separated into grade levels). Now, a user could go onto the site and search for an article using keywords and filters for user-type and grade level. The website would automatically find every relevant article and list them out for the user to enter. When clicked, the user would be brought to the corresponding article.

The website was eventually fully finished and hosted, and my team immediately began using to create and post their resources. Altough the website is no longer online, I am still proud of the contribution that I made to the Climate Reality project.

Calendar for a Friend

The first website I ever made was for a friend. He offered to pay me some cash to make him a calendar website, so I immediately got to work learning how to even make a website.

He effectively wanted to be able to add events to an online calendar (like Google Calendar), except everybody who went on the website accessed and modified the same calendar. Although the website was simple, sending user input to the server, storing it, then later retrieving it was a big challenge for me to learn. I eventually came up with a solution using Node.js involving using a manifest text file to store the events, then the server would read this text file and send the events to the user.

The user was able to add an event, specifying its name, date, time, location, and description, and this would be sent and stored in the server. The user could then view a month or a day. The month would show a list of days with events in them, and this would have a brief look at the events. The user could also look at a specific day, and here they would find more details on each event. Lastly, the user could delete any event, making the calendar fully modifiable.

It worked after 2 weeks, and I had officially finished my first coding commission!

Oregon Road 83

Oregon 83 is a project currently being developed by Professor Alex Wellerstein at Stevens Institute of Technology. The game is designed for the player to experience an alternate history America where the nuclear tensions in 1983 boiled over and the world entered a nuclear exchange.

The game combines heavy research of the time period with an homage to The Oregon Trail to make a historically accurate survival game where the player must cross the country to reach their brother's bunker in Oregon.

This project is the first large-scale video game that I have ever worked on, and it has taught me many unique lessons.

My work on the project was with the audio team. I not only contributed to the team by making music and sound effects myself, but also by helping to implement the audio in the game engine.

The game uses a custom-built Javascript engine, meaning that it was up to the audio team to organize the audio system in the code. We eventually settled on FMOD, a third party software meant to allow game developers to implement dynamic audio.

By setting up audio events and parameters to control those events, we could abstract the code behind playing the proper audio at the right time to a simple changing-of-variables for the programmers. This also allowed us to experiment with dynamic audio systems. For example, we drafted a general travel theme that would change based on which companions you had in your party.

The most important lesson that I learned from this project was the value of organization.

The audio team alone had 11 people in it, and so I thought production would be easy. However, the opposite was true.

That many people working on the same project lead to clashing ideas, redundant work, and a general lack of direction.

One of the most important contributions that I made to the project wasn't any of the music that I made or the FMOD system that I implemented, but this:

I helped to create a list of all of the music and sound effects that we absolutely needed for the project, ranging from car engine noises to the menu theme. I then made an FMOD event for each piece of audio that we needed and shared it with the team.

Now, instead of simply working on whatever they thought was worth doing, the team had a clear, managable list of individual tasks to work through.

This significantly improved the workflow of the team, as now team members were able to work on the project and feel confident that what they were doing was effective.

Although the project is still under development, I am extremely grateful to work on a video game of a larger scale. It taught me many valuable lessons about video game development that will stick with me for the rest of my career.

I learned the importance of organization, how to work within a larger team, and how to communicate with others to make sure that everyone worked towards one unified vision.

Deck Thrower

Deck Thrower was made for the first Stevens Game Development Club's Game Jam that I participated in.

I had 48 hours to build the game based on the theme they gave (Unusual Weapon).

I was able to finish the game by the deadline and got 2nd place in the entire jam!

I made all of the game's assets myself during the jam.

Some time after the jam, I decided to polish up the game into a more completed state.

I added art, sound, and music, added a main menu, and also squashed many bugs.

I'm proud of the game that it has become.

Click the image to play it in the browser. Simply use WASD to move and Left Click to shoot a card. Scroll or use numkeys to choose your card.

Fruity Catcher

Fruity Catcher was the first game that I ever fully completed.

Although it is simple, it took over a month to develop simply because I was teaching Unity to myself as I made it.

This game is a fruit catcher game, where the player must move around the ground to catch fruit falling from a tree.

However, I also added bombs and powerups to make things more exciting!

The powerups range from making the player bigger to slowing down gravity to having everything spawn in faster!

Every asset in the game, from the sprites to the music, is entirely made by me.

One of the largest challenges of the game was organization.

Even something as simple as keeping score required a lot of work to keep everything organized.

I eventually learned to use game managers to keep every aspect of the game modular and abstracted.

Rather than have my collision code also apply the powerup when the player picks up one, it simply asks the powerup manager to do so.

Rather than have my menu screen handle the transition to the main game, I simply had my menu manager do the work itself.

I eventually submitted this game to the Computer and Console Gaming Society and the Stevens Game Development Club's gaming tournament.

This event had many students on my campus come together and compete to earn in the best scores in games developed by the Stevens Game Development Club.

It was fun and very rewarding to see a whole group of people play my game and get very competitive over it!

Click the image to play it in the browser. Simply use A and D or left arrow and right arrow to move and catch the fruit!