AWS Builder Center

Builder Center

RE-VOLVE: Prioritizing Vehicle Inspections with Data

RE-VOLVE: Prioritizing Vehicle Inspections with Data

How I built a vehicle inspection dashboard as a student, what went wrong when the build passed but the data didn’t show up, and how AWS fits into the roadmap.

Shruti

RE-VOLVE

How I built a rule-based vehicle inspection prioritization tool, what broke along the way, and how AWS fits in.
RE-VOLVE dashboard showing 117 vehicle records, 47 flagged for review, an age distribution chart by inspection band, and a fuel mix donut chart.


Why I built this

Cities need cleaner air, but the data that could help is scattered: vehicle age in one sheet, fuel type in another, pollution-check status somewhere else. Transport authorities and fleet managers end up eyeballing spreadsheets to decide which vehicles deserve a closer look.
I’m a B.Tech Computer Science & Design student, and I wanted to see if I could pull this into one place. That became RE-VOLVE, a vehicle intelligence platform that scores vehicles for inspection priority, shows regional patterns on a dashboard, and lets you simulate retirement scenarios.
One thing I decided early: RE-VOLVE does not declare a vehicle “polluting.” Real emissions claims need real inspection measurements. This tool only helps decide which vehicles to look at first.

What RE-VOLVE does

  1. Inspection-priority scoring: Uses vehicle age, fuel type, emission standard, fitness status and PUC status.
  1. Dataset management: Import vehicle records, normalize them, store them in PostgreSQL.
  1. Analytics dashboard: Distributions and regional patterns at a glance.
  1. Retirement scenario simulation: “What if we retire vehicles older than X years?” and see how the population changes.
How the scoring works RE-VOLVE calculates an inspection-priority score from a vehicle’s age, fuel type, applicable emission standard, fitness status, and pollution-under-control (PUC) status. Older vehicles, older emission standards, and expired PUC or fitness certificates push a vehicle’s score up, so it shows up higher in the inspection queue.
I deliberately started with transparent rules instead of ML. A scoring formula you can explain beats a model you can’t validate.

Architecture

Stack: Next.js (App Router), React, TypeScript, Tailwind CSS, PostgreSQL on Supabase, Drizzle ORM, and Recharts.
AWS Integration:
  • Amazon SageMaker: For developing, training, and deploying machine learning models to support vehicle assessment and inspection-priority prediction.
  • AWS Application Deployment: For deploying and hosting the RE-VOLVE web application on AWS, making the platform accessible through a live URL.
The system combines rule-based vehicle scoring, environmental intelligence dashboards, and data import/export workflows, with planned machine learning capabilities through Amazon SageMaker and cloud-based application deployment on AWS.
Architecture diagram of RE-VOLVE. A user’s browser sends requests to a Next.js and React frontend, which calls Next.js API routes for vehicle scoring and data import. The backend reads and writes to a Supabase PostgreSQL database through Drizzle ORM. A dashed AWS section shows planned Amazon SageMaker for ML predictions and AWS hosting for deployment.


The bug that taught me the most

One of the biggest lessons I learned while building RE-VOLVE was that a successful build does not mean a working application.
At one point, my Next.js production build completed successfully, and the dashboard page loaded without any compilation errors. But the dashboard was still empty and displayed an error saying it could not load the dataset.
My first assumption was that something was wrong with the database. I had connected Supabase and created the required tables —  vehicle_records ,  import_batches , and  assessments  — but the  vehicle_records  table contained zero records.
As I investigated further, I discovered that the problem was not just about having a database. Multiple layers of the application needed to work together: database connectivity, API routes, dataset initialization, and frontend data fetching.
How I investigated it:
  • Step 1: Checked the database. I opened Supabase Table Editor and verified that the expected tables existed. However, the vehicle records table was empty, so the dashboard had no vehicle data to display.
  • Step 2: Tested the API directly. Instead of relying only on the dashboard error message, I opened the statistics endpoint directly. The terminal revealed a  404  response for  /api/vehicles/stats . This helped me identify a backend routing issue rather than assuming the frontend was responsible.
  • Step 3: Investigated the database query. After the API route issue was addressed, the endpoint returned another error: the query  SELECT COUNT(*) FROM vehicle_records  failed. This narrowed the investigation to the database query and connection layer.
  • Step 4: Found the authentication problem. The deeper PostgreSQL error was  28P01: password authentication failed . This indicated that the database credentials or connection configuration needed correction. Changing the connection string format alone was not enough to prove that authentication was working.
The project also had an automatic initialization function,  src/lib/ensure-data.ts , intended to populate an empty database with approximately 1,100 synthetic vehicle records. That made it important to verify whether the initialization function actually executed and inserted records, rather than assuming that creating the tables had initialized the dataset.
The key lesson: A successful build verifies compilation, not runtime correctness. Database connectivity, schema creation, data initialization, API responses, and frontend rendering must each be tested independently.
This debugging experience changed how I approach full-stack development. Instead of treating an empty dashboard as a single UI problem, I learned to trace the complete data flow from PostgreSQL to the API and finally to the frontend — checking the actual error at each layer before deciding what to fix.

Rule-Based Scoring vs. Machine Learning

RE-VOLVE currently uses a rule-based scoring system to support vehicle assessment and inspection prioritization. It does not yet use a trained machine learning model, and its scores should be treated as decision-support indicators rather than definitive proof of a vehicle's emissions or legal eligibility for scrapping.
For future development, RE-VOLVE aims to integrate Amazon SageMaker AI to experiment with machine learning models trained on reliable, labelled vehicle inspection and emissions datasets. Model development would require proper training and testing datasets, leakage prevention, and validation against real-world inspection outcomes to evaluate predictive performance and reliability.
Rather than training a model on scores generated by the existing rules, the goal is to assess whether machine learning can identify meaningful patterns in real-world vehicle data. This approach prioritizes transparency, evidence-based decisions, and responsible use of AI in environmental assessment.

What's Next

  • Verified Data Integration: Incorporate reliable vehicle inspection and emissions datasets to strengthen assessment accuracy.
  • AWS Integration: Explore Amazon S3 for secure dataset storage, with appropriate encryption and access controls, wherever required.
  • Quality & Reliability: Add automated tests, API health checks, and robust error handling.
  • Responsible ML Development: Use Amazon SageMaker AI to train and evaluate a baseline machine learning model when sufficient labelled real-world data is available.
  • Transparent Environmental Assessment: Compare vehicle retirement scenarios using clearly documented assumptions and validated data, without presenting estimates as definitive environmental outcomes.

See the code:-

Final Thoughts

RE-VOLVE taught me that building a data-driven product is not just about developing features, but about ensuring consistency across every layer of the system and being transparent about what the system can and cannot claim. Although it began as a prototype, RE-VOLVE has evolved into a foundation for more reliable, data-driven vehicle assessment and responsible environmental decision-making. By integrating Amazon SageMaker AI and deploying the application on AWS, the project aims to combine scalable cloud infrastructure with intelligent vehicle assessment while maintaining transparency, reliability, and evidence-based environmental insights.
RE-VOLVE uses rule-based vehicle assessments for inspection prioritization, with Amazon SageMaker AI supporting machine learning capabilities and AWS providing the cloud deployment infrastructure.
# amazon-sagemaker# sustainability# machine-learning# data-analytics# student-builders
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article