AMIHAN was a project made a year ago focusing on air quality monitoring in compliance with the requirements of our 2nd year course last year, CS158-1L: Artificial Intelligence Laboratory; where we created, academically, our first machine learning model. My actual first model in practice was SmartGrid, based on neural nets.

AMIHAN started as a local monitoring machine learning model based on Random Forest Regression (RFR), to a global contest-level modeling based on Decision Trees (DT) for Altair Engineering (https://altair.com/).

Its first iteration is documented and recently published in Zenodo, an open-access repository backed by CERN (European Organization for Nuclear Research). They also provide DOI assignments, draft & metadata updating, which is neat!

The Altair Global Student Contest is an annual program hosted by Altair Engineering with a $2000 cash prize. Its a data science focused contest that requires the participant to use Altair AI Studio and work on a data-driven project. This year, they wanted a focus on predictive modeling, AI solutions, visualizations, and optimization tools.

AMIHAN V.1

Title: AMIHAN: An Advanced Monitoring Intelligence for Harmful Air Navigation based on Mandaluyong, Philippines

DOI: https://doi.org/10.5281/zenodo.17827295

Contributors: Reyes, Christine. Ng, Louella. Esperanza, Kim.

Dataset: Philippines - Open, validated, health, climate, environment and socioeconomic linked dataset optimized for machine learning | Project CCHAIN - The Project CCHAIN Dataset

Presentation: Canva, Public View Link

Tools: IPYNB, Python

Mandaluyong was selected to be the area of focus for our research because it was one of the cities that had a generous amount of air pollution due to urbanization, vehicle emissions, industrial activities, and so on; as mentioned in our Introduction section.

AMIHAN employs a Random Forest Regressor (RFR) to forecast daily concentrations of three key pollutants in Mandaluyong City: sulfur dioxide (SO), carbon monoxide (CO), and particulate matter (PM2.5).

Limitations:

• Geographic scope: Focused only on Mandaluyong City; results may not generalize to other urban centers.

• Pollutant selection narrowed: Limited to SO, CO, and PM2.5; excluded other pollutants and environmental variables (e.g., temperature, precipitation).

• Temporal bias: Accuracy declines at higher pollutant concentrations, particularly PM2.5, suggesting unmodeled external factors.

• Data dependency: Relies on HDX dataset validity; missing or incomplete records could affect robustness.

• Model constraints: While RFR captures nonlinear trends, it may underperform compared to deep learning models (e.g., LSTM) for long-term temporal dependencies.

• No vehicle-specific analysis: Future work aims to address emissions from jeepneys and other mobile sources, but V1 remains generalized.

AMIHAN V.2

Title: AMIHAN: Station-Level Air Quality Risk Profiling Based in Spain Exploring the Impact of Urban Design and Traffic on Air Quality Risk (Prezi)

Abstract: AMIHAN V.2 helps correlate urban geometry, traffic intensity, separate emission values, and other dimensional factors with the risk levels of PM10 monitoring stations, categorizing them to each station with predicted risk classes (high-risk (1) vs low-risk (0)) for urban planning, public health improvements, as well as to help in prioritizing areas for early intervention and monitoring.

Contributors: Reyes, Christine Julliane L.

Context: Altair Global Student Contest, Category 2 (Their data, their use case).

Tools: Altairs RapidMiner AI Studio

Process:

1. Turbo Prep (Inspect raw data turned ? values to missing values (NA) Check statistic results)

   

2. Process Design (Retrieve cleaned raw data Filtered Spain, PM10, urban Generate risk labels Select final attributes for subset (geometric/structural data, etc.) Store data subset Generate results)

   

3. Auto Model (Auto-model subset Based on results, save most optimum model (Decision Tree) and results Generate process)

4. Results (Model, Predictions)

   

   

   

Comparative Insights: AMIHAN V.1 vs V.2

Scope and Context

• V.1 (Philippines, Mandaluyong)

  • Focused on forecasting daily pollutant concentrations (SO2, CO, PM2.5) in a single urban area.

  • The goal was to support public health and policy planning through predictive modeling.

• V.2 (Spain - Urban PM10 Stations)

  • Shifted to station-level risk profiling across 425 urban monitoring stations in Spain.

  • Generated station-level predictions (170 outputs) based on metadata attributes.

  • The goal was to identify structural risk drivers (traffic, street geometry, emissions) and predictive modeling across multiple stations in order to link urban design and traffic to PM10 risk.

• From city-level pollutant forecasting to multi-station predictive modeling with structural features.

Data and Inputs

• V.1 (Philippines, Mandaluyong)

  • Historical pollutant concentrations (2003 to 2022).

  • Temporal features: year, month, week, lag, rolling mean.

• V.2 (Spain - Urban PM10 Stations)

  • Metadata attributes (425 urban PM10 stations).

  • Predictive features: Main Emission Source, Longitude, Latitude, Street Width, Building Distance, Traffic Volume, Distance Source.

• From time-series pollutant values to spatial + structural metadata features.

Modeling Approach

• V.1 (Philippines, Mandaluyong)

  • Random Forest Regressor with temporal feature engineering.

  • Predicted pollutant concentrations directly. Similar to General AQIs (MSN Weather).

  • Performance: R ~0.85 (after retraining with temporal features).

• V.2 (Spain - Urban PM10 Stations)

  • Decision Tree classifier/predictive model.

  • Generated station-level predictions (risk categories + metadata-driven outputs).

  • Performance: Accuracy ~70.2%, AUC ~0.77. Balanced with interpretability.

• V.1 emphasized numerical pollutant forecasting, while V.2 emphasized station-level predictive profiling with interpretable rules.

Feature Importance

• V.1 (Philippines, Mandaluyong)

  • Temporal features (lag, rolling mean).

  • Pollutant concentrations normalized and modeled simultaneously.

• V.2 (Spain - Urban PM10 Stations)

  • Street Width (0.237) strongest driver.

  • Traffic Volume (0.079), Distance Source (0.059), Main Emission Sources (0.051).

  • Spatial features (Longitude, Latitude, Building Distance, etc.) also shaped predictions.

• V.1s drivers were time and pollutant dynamics, while V.2s were urban geometry, traffic, and spatial context.

Outputs and Impact

• V.1 (Philippines, Mandaluyong)

  • Forecast pollutant levels for Mandaluyong.

  • Useful for local government, healthcare providers, and awareness campaigns.

• V.2 (Spain - Urban PM10 Stations)

  • Predictive outputs for 170 stations.

  • Useful for urban planners and policymakers to prioritize interventions (traffic rerouting, street redesign; which stations are structurally high-risk, why, and how to intervene).

• From community-level forecasting to station-level predictive modeling for structural risk management.

Limitations

• V.1 (Philippines, Mandaluyong)

  • Restricted to one city and three pollutants.

  • Accuracy declined at higher pollutant concentrations.

• V.2 (Spain - Urban PM10 Stations)

  • Proxy risk labels (traffic vs non-traffic).

  • Limited to Spains PM10 urban subset.

  • Predictions based on metadata, not direct pollutant exceedances.

Summary

• AMIHAN V1: A time-series forecasting model for pollutant concentrations in Mandaluyong.

• AMIHAN V2: A station-level predictive model using metadata features to classify and profile risk across Spains urban PM10 stations.

Personal Notes

One of the things I really liked about Altairs RapidMiner AI Studio is the fact that they have a Simulator! See

Here, I can check out how certain attributes that I included in the subset can affect the results. Example for this is the second graph (the bottom one). Adjusting Main Emission Sources can help you check out what affects the rating of range1 (0) low-risk stations. Which is what is necessary. The nature of V.2 is more of prescriptive analytics. Come AI Studios optimization feature that automizes this by finding the ideal inputs for your ideal outcome based on the model.

All in all, AI Studio is amazing for data (pre)processing, modeling, and generating pipelines.

Future Direction

An interesting question was posed. Such that Could AMIHAN evolve into a global framework for urban air quality risk profiling? the answer is yes, but not in the rigid sense of a finished product. AMIHANs strength lies in its adaptability: Version 1 demonstrated how time-series forecasting could reveal pollutant trends in a single city, while Version 2 showed how metadata-driven modeling could profile structural risks across hundreds of stations. Together, these iterations suggest a way towards a modular system that can be applied in different geographies, datasets, and contexts. Each city, each dataset, becomes another way for AMIHAN to evolve, building towards a more comprehensive framework for understanding how urban design, traffic, and emissions shape air quality risk.

AMIHAN really began as an academic project, but developing it for Altair made it into an actual system; which is something I really value. What can you do outside of the classroom? Because ultimately, well be out of it sooner or later.

On a more personal note, I joined the Altair contest mostly for fun, if not last minute. Thank you, Ms. Renilda Layno for referring me to join this contest! It gave me a chance to revisit and optimize an old project and make my own playful reworks that worked for a larger narrative.

Explore

And my Zenodo entry really made me feel like a researcher so I really like that too. The concept of getting DOI labels is actually pretty exciting. I hope to publish to bigger journals soon! (https://doi.org/10.5281/zenodo.17827295).

Stay tuned if I win or subscribe to my newsletter for any future updates. :)

Co-created with Simonee Ezekiel (co-full stack dev), Regina Galfo (researcher), Nathan Mercado (researcher/data analytics dev), and Mark Ilagan (team lead, UI dev, researcher).

Getting started

24 hours to build it. 12 months to prove last years 2nd place was just the warm-up.

Last year, I joined Meralcos IDOL Hackathon 2024 with barely any knowledge outside Python, Data Analytics, Machine Learning, the likes. I was still proud of what we did before, and even more so that I won at my first hackathon! Albeit 2nd place, my previous team and I still developed a useful solutionSmartGrid. But I was so nervous all the time, everyone knew how to develop web applications, and I was stuck with Jupyter Notebook, .py scripts, Tableau, and a dream.

SmartGrid ran short in development capabilities. I barely had a grasp on APIs and algorithm implementations, so my smart meter grid overload predictive analytics was creative at the time, yes; but it couldve been better. The contenders were really amazing at the time too so it made sense to be in the standing where I was then. (Hi Nico, Dhan my podium batchmates) I was unprepared and honestly fresh out of a club.

This year I came back, sort of a way to see if I grew from who I was before So, this is the story of the 24-hour sprint that finally let me beat last years version of me.

For the past year, I grinded a lot. I started studying systems architecture, AI modeling, algorithm solving.

Actually, re-joining the hackathon this year wasnt in my bingo card. I didnt really have anyone in mind to team up with, nor did I have a solid idea of what I wanted to build. There was, however, this gut feeling that Ill be back. And thats when Simonee messaged me on Facebook asking if I was joining, because their team is looking for one more core developer.

Dont get me wrong, I love my team. But the first time we met, I felt so out of it. For one, I was a recurring participant, and a winner at that. Most would think its weird to re-join if youve already won. Worrying about how I would look like if I didnt get to the podium at all, or if I was going to be stuck in 2nd place, or below. Its valid. But I never really thought about it deeply... it was more of a; it is what it is thing. The second factor was that I was the only Mapuan in the team filled with UP students. It felt both an honor and a sort of horror. What if I underperform? What if Im treated like an outsider? What if they expect too much from me because I won, and now I cant deliver? The doubts were loud.

But soon enough, we got into our first meeting and the doubts just disappeared. They were all nice, they were all smart. And we all discussed like equals, efficiently. Which contributed to our easy delivery and project write-up for the qualifications for this years hackathon. When deliberation day came, we were all nervous of being accepted or not, it was so funny honestly. I thought that I guess this is a better fate than losing on stage (denial).

The Hackathon Proper

Moving on to the day of the hackathon proper was another thing. I hadnt been to the Meralco compound in A YEAR, so I got completely lost again when navigating their gates outside. I initially listened to my sisters advice about dropping myself off at SM Megamall and attempt walking, but my bag was so heavy (darn gaming laptop), I couldnt take it. So I had to book again, but this time an Angkas instead of Grab, so I can head to Ortigas Avenue faster (and cheaper). But in my haste I didnt even get to double-check the gate pinned! And it was hard to turn around in Ortigas Ave. so I still had to walk after all it was a stressful start.

Eventually I finally got to meet my team. Mark and Regina were already seated there, our other two teammates were running late since Monee was still commuting from Los Banos, and Nathan had just finished an exam. The hackathon started at 9 AM, and I arrived around 11 AM?

Everyone was already building and Im there still wiping sweat off my forehead. And get this, with my full duffel bag, I forgot a single thing so important too. My adapter!!! I also had to run around asking the IT department if we could have an extra socket so I can charge my laptop talk about a headstart.

The 24-hour sprint

Hour 0 to 2 (9 to 11 AM): Just got settled in.

Hour 3 to 7 (12 to 3 PM): Initializing repository and beginning the base of the React prototype set-up. The screens we needed based on the Figma UI design, talking with roaming employees, listening to their advice, doing extra research based on their suggestions to check out the regulations set by the Department of Energy (DOE). Setting up the pseudo-connections, actual connections, etc.

Hour 8 to 13 (4 PM to 8PM): We were still learning how to work around each other. GitHub branches, version controlling, me not understanding Mac, Monee and Nathan arrive, we add more features, Monee and I get to finally divide the primary development work.

Hour 14 to 19 (9 PM to 2 AM): Some hours in between, we were taking breaks, eating dinner and snacks, discussing what else needed to be done, etc. by 12 MN, Mark and Reg were prepping for the presentation by 9 AM. Also by this time, most of our UI and the prototype was done.

Except mine!!! Because systematically thinking about and actually executing the routing system that allows stop-overs whilst implementing a pricing system based on the distance, car make, hypothetical volt usage per charging stations (which also have their own types), was a lot. I based on existing routing APIs, but had trouble further working it out for our specific use-case. Which is probably why kuya Caloy was asking me how I plan to do it, haha.

It was also around this time that Mark managed to convince the rest of the team (except Monee who was passed out on the couch) to put on some moisturizing masks after we freshen up for the night. I couldnt be more grateful for it aside from his Chagee treat earlier. I think it was during this that I genuinely felt close with my team, it was a very fun experience! I dont think anyone else would even think of openly vlogging and doing a whole skincare routine during a hackathon hahaha.

Hour 20 to 24 (3 AM to 9 AM): Last stretch! I was getting really tired and I still havent accurate done the routine system. The problem was the existing EV charging stations from OpenChargeMap wasnt enough, I had to make fake parameters such as faster battery degradation just so that planning routes would actually suggest more stopping points. And we didnt really have an actual EV API to base on, so I went with a standard Tesla Model 3 2023, Long Range EV. And then now there werent enough compatible chargers, and its just a lot. Then even more chaos happened when we were all having problems with running the app on Expo Go, or having problems with merging our working branches on main due to merging conflicts.

Buuuuut, we managed to pull through.

Of course, the routing algorithm I pulled off isnt near perfect, if at all doing what we intended. It just did enough. Enough for us to pitch, and enough for me to understand that I grew, but I need to grow more.

We generated random sequences of charging stations alongside existing stations from OpenChargeMap so that we can exhibit cases where user, for example, wants to travel from Baguio to Manila and make sure that they can keep their electric vehicle adeptly charged. Ill elaborate on the algorithms and technicalities in its correct heading. For now, lets get on to judging!

Judging Hour

We got on that stage, I was thinking will they recognize me? Will people look at me and say, thats a person whos come back for another run. And that can be good, or bad. Nathan was our opener, and I was the product demo presenter. It wasnt bad, and I was proud of the product. But Id have to admit that we went faster than we intended to at the time, but that was mostly because of our limited allotment to present.

The chair of judges were:

• Ralph Menchavez: VP and Head, Commercial Strategy Management and Energy Solutions at Manila Electric Company. EV Adoption Program Manager.

• Erzil Kho: SAVP & Head, ICT Governance Head at MERALCO; focusing on Risk Management, Asset Contract, and Vendor Management and Process and Performance Management

• Jojo Reyes: Professional Electrical Engineer, MSEE, Vice President at MERALCO, Chairman of AESIEAP TWG on Smart Grid & Asset Mgmt, taking up PhD EEE at UP Diliman.

I had my share of experience with Sir Ralph and Sir Jo from my past run, and if I impressed them before, I needed to impress them again now. But I guess the biggest difference was that this time, I felt like I wasnt standing lonesome. Funny or not, Team Koryinti made it all feel vastly different.

After our presentation, you know the first thing Sir Ralph told us?

How much?

Which in startups, businesses, basically translates to: Id actually pay for this.

It was phenomenal. That was it. But it made the whole team lax and happy. And it was the fuel for me to really think of Revolt as not just a contest entry, but as a startup that I can add next to Clinivue (whose currently on hiatus). Suffice to say, I was also happy to know that they did recognize me again.

For the tech-heads what really is Revolt?

Revolt is a full-stack EV charging platform that works for everyone from someone with one home charger to nationwide charging networks.

Who Its For and What They Get

Solo / Private Owners

• List your charger in <5 minutes

• Set your own price per kWh and connection fee

• See every booking and exactly how much you earned

• Get paid automatically (you keep ~9798 %, we only take a tiny commission + 30 flat booking fee)

• Zero paperwork, zero subscriptions

Enterprises and Large Networks

• Manage hundreds of stations in one dashboard

• Role-based access (ops, finance, admins)

• Dynamic pricing rules, connector priority, fleet policies

• Full revenue split visibility and automated payouts

• Export everything to your existing BI tools

The Driver Experience

1. Enter destination Revolt pulls a real route (OpenRouteService)

2. App scans for chargers along the exact corridor

3. Smart optimizer picks the best stops based on:

   • Your cars real charge curve

   • Charger speed vs price

   • Your preference: fewer stops (longer charges) or more stops (faster ones)

   • Guaranteed minimum arrival battery % you set

4. See total trip time, total cost (energy + fees), and exact charging duration at each stop

5. Tap to reserve a specific connector for a 1530 min window

6. Pay once, get a QR code, scan on arrival charging starts

Everything is reserved, so no more charger hogging or arriving to a broken/unavailable station.

Business and Analytics Dashboard (Actually useful, but only current integration are usage line graphs per region)

• Live utilization graphs (by hour/day)

• Revenue breakdown: energy sold, connection fees, booking fees, our commission

• Repeat-driver tracking and churn signals

• Where should I put the next charger? recommendations based on unmet demand

• One-click export or API access for big operators

• Simple monthly payout PDF for small hosts

Tech Stack (Quick Overview)

• Mobile app: React Native + Expo

• Maps & routing: Mapbox + OpenRouteService

• Charger data: OpenChargeMap + our own curated list

• Backend: Node.js microservices (routing, reservations, payments, analytics)

• Payments: Secured gateway with automatic split payouts

• Everything designed to scale horizontally in Docker/K8s

Current Status and Whats Next

Built from scratch in a 24-hour hackathon and actually won 1st place. Its open-source: github.com/anneryeo/Revolt feel free to star, fork, or roast the code.

Whats in for Revolts future?

If I were to think of a roadmap if I want to develop Revolt more

• Short-term: better route projection, deterministic mode (no randomness), cleaner code

• Mid-term: fleet accounts, dynamic pricing, station-side mobile app for hosts

• Long-term: SSO, SLA dashboards, deep BI integrations for enterprises

I think this is a really great idea to pursue as a startup, something Ill have to consult with my team, and possibly in the future Sir Ralph. For now, this is our mini contribution to making the Philippines a little greener 🌱

Last years 2nd-place trophy is now my metaphorical phone stand. This years 1st-place trophy its out there to remind me, Never stay the same person for 365 days.

With Revolt, lets charge the future one perfectly reserved connector at a time 🌱

Anne Reyes (RYEO LABS) & Team Koryinti (Still not over Sir Ralphs How much?)

This was originally an idea I believed could shape my own future. Though currently smalldaresay, insignificantI believe this will become something larger over time. I want to document my journey into a safe, yet professional space. A place where I wont be afraid to share what Ive found even if it is incomplete. Where I can share concepts, even if I dont have all parts of the map discovered. All without being muddled deeply into whatever algorithm for exposure, or for content adjustment per platform.

Deeper into the future, Ryeo Labs will serve not only me.

At first, I thought the word Ryeo was uniquely mine. In usernames, it was always available. In searches, only my own profiles surfaced. Since 2019, it felt like Id found a word that belonged to me alone. But soon I found out as I officially began building Ryeo Labs, that its quite known originally in Korea and China; though still sparse. I was leaning on to the thought that maybe Ive made something completely mine, and that was exciting. But finding out its meaning from its origins helped in better solidifying the identity I wanted to attach to the name. It is bright, beautiful, and strong.

Writing this, preparing it for publication, I find myself sitting in solace beside my mother in the hospital. Its been the most difficult week of my life. And this project, Ryeo Labs, is helping me see myself beyond the shiny parts. I hope, one day, others can understand too. One day, theyll see too.

On June 30, my family survived a car accident. And in the same week, Im facing my midterms, building my thesis, managing Clinivue, and trying to generate income to stay afloat. Im exploring remote internship opportunitiessomething that could allow me to earn, learn, and grow in ways that feel aligned with my values.

Alongside that, Im performing tasks I never imagined doinghelping care for my parents in ways that feel both intimate and unfamiliar. Its hard. And yet, in all of this, I am learning. About responsibility. About quiet strength. Youll have to find the time to be vulnerable in the dark and still be able to hold on to that fire inside, to keep it burning, even if it feels like a fleeting candle; and all you can do is hunch deeply, desperately hoping it doesnt run out as the hot wax runs over your fingers.

Sometimes I believe I am Atlas. But Im luckier than him, I supposebecause I dont carry the weight alone. My siblings share it. Our big family behind our backs. And maybe thats the quiet truth: no one is built to bear everything. You just have to find someone, or something, that can be there when life is beating you left and right. Sometimes, itll be the people closest to you, sometimes itll be your dog, or cat, and sometimes itll just be.. you.

Soon, I will enter my third and last year of college.

I will have hard times. Maybe even harder ones. But what are humans if not proof of evolution? Of growth, adaptation, and resilience. Thingslike usare meant to change.

Ryeo Labs will evolve as I do. It may begin as scattered notes and unfinished thoughtsbut over time, I hope it becomes its own constellation of insights. Sometimes Ill write about breakthroughs. Sometimes about breakdowns.

If you're here, welcome to the first layer. It won't always be clear, but it will always be mine.

An inspiration:

How do you write like youre running out of time? How do you write like you need it to survive? (4:48, Non-Stop. Hamilton, 2015)

Because I do need it to survive, and I want history to have its eyes on me.

In Stillness,

Ryeo