Slashing 40% Carbon on a 250 kW Grid Limit: How We Built an Autonomous, Bedrock-Powered EV Fleet Orchestrator
By Taksh Pal — Frontend Architect, UI/UX & Systems Integration Lead Team AWSsome Builds | Track 03: Waste & Energy — AWS Sustainability Hackathon
"The hardest problem in fleet electrification isn't buying 40 electric delivery vans. It’s plugging them in at 18:00 without blowing up the local substation or waiting two years for a million-dollar transformer upgrade."
- The Multi-Million-Dollar Bottleneck Nobody Talks About Every logistics giant wants to electrify their last-mile delivery fleet. It sounds clean on paper: swap diesel vans for electric ones, install a row of DC fast chargers, and pat yourself on the back for Scope 1 emissions reduction.
Then reality strikes the depot manager.
When 40 delivery vans roll back into the terminal between 17:00 and 19:00, drivers plug them in immediately. In an unmanaged depot, this creates a violent 482.6 kW power demand spike.
Here is the problem: the local utility connection is capped at a strict 250 kW transformer limit.
f you trip that 250 kW ceiling, you face catastrophic utility penalties, circuit breaker trips, and stranded delivery vans in the morning. If you request a substation upgrade, the utility hands you a ₹4.5 Crore ($500k+) quote and an 18-to-24 month lead time.
To make matters worse, that 18:00–21:00 arrival window coincides with the dirtiest, most carbon-intensive, and most expensive power on the regional grid.
We asked ourselves a contrarian question:
What if intelligent mathematical orchestration and generative AI could eliminate the need for physical grid reinforcement entirely?
That vision became DECARB-EV (Depot Connection Sizing & Carbon-Aware Dispatch Planner).
2. Our Core Principle: The Mathematical Safety Boundary
From Day 1, our team established an unbreakable rule:
"Never let a Large Language Model do physics or safety-critical math."
LLMs are creative and adaptive, but they hallucinate. You cannot allow a probabilistic model to schedule kilowatts on physical hardware where a 5 kW hallucination can start an electrical fire or strand 10 delivery routes.
We separated our architecture into three distinct layers:
Plain text
┌────────────────────────────────────────────────────────────────────────┐│ THE THREE-TIER SAFETY BOUNDARY │├────────────────────────────────────────────────────────────────────────┤│ 1. REASONING & ORCHESTRATION LAYER: Amazon Bedrock (Claude 3.5 Sonnet) ││ Translates messy unstructured driver rosters & hardware disruptions ││ into structured solver parameters. Explains tradeoffs in plain English.│├────────────────────────────────────────────────────────────────────────┤│ 2. DETERMINISTIC SOLVER LAYER: Google OR-Tools CP-SAT ││ Formulates a multi-interval Mixed-Integer Linear Program (MILP). ││ Solves for global carbon minimum + cost over 96 discrete intervals. │├────────────────────────────────────────────────────────────────────────┤│ 3. INDEPENDENT CERTIFICATION LAYER: Deterministic Safety Validator ││ Zero LLM involvement. Checks 4 hard physical invariants: ││ ✓ Transformer peak ≤ 250 kW (100% compliance) ││ ✓ No charger bay concurrent overlap ││ ✓ All battery SOCs reach ≥ 90% before morning shift │└────────────────────────────────────────────────────────────────────────┘
The AI agent proposes. The mathematical solver optimizes. The deterministic validator proves. The human operator clicks Approve.
3. What I Built: Engineering the Mission-Control Cockpit
As Member 4 (Frontend UI/UX & Systems Integration Lead), my responsibility was turning complex discrete optimization algorithms and AWS telemetry streams into a zero-cognitive-overload operations console that a depot manager could run during a hectic night shift.
Here is what went into the engineering of the DECARB-EV Enterprise Dashboard:
A. The 96-Interval Canvas Load Curve & Carbon Envelope
Depot managers don't want raw CSVs; they need to see their transformer margin in real time.
- Built a high-performance HTML5 Canvas Scrubber rendering 96 quarter-hour intervals (18:00 to 07:00).
- Visualizes the baseline power curve (red spike over 482 kW) versus the optimized schedule (flat-topped neatly at 250 kW) alongside live grid carbon intensity ($\text{gCO}_2\text{e/kWh}$) and dynamic time-of-use tariffs.
B. The 10-Bay DC Fast Charger Telemetry Grid
- Designed real-time interactive bays displaying active kW delivery, vehicle ID, battery SOC progress arcs, and temperature status.
- When a hardware fault occurs (e.g., Inverter fault on Charger C04), the UI immediately pulses amber and highlights orphaned vehicles.
C. The Bedrock Human-in-the-Loop (HITL) Decision Card
- Fleet operators must understand why the AI made a decision before signing off on it.
- Built an interactive approval drawer that renders Claude 3.5 Sonnet's plain-English operational rationale:> "Charger C04 faulted at 21:15. Diverting Vans V08 and V14 to Chargers C01 and C07 during the 01:30–04:00 clean wind window. Net impact: +₹140 electricity cost, 0 kg extra CO2e, 100% departure readiness maintained."
- One-click [Approve & Dispatch] triggers a live commit to Amazon DynamoDB and publishes an execution event to Amazon EventBridge.
D. Claude Unstructured Roster Ingestion
- Drivers frequently submit rosters as messy text or WhatsApp messages:
"Van 4 arr 17:30 bat 22% need 85% by 6am".
- Built an ingestion modal powered by Amazon Bedrock that converts messy text into structured JSON vehicle schemas in under 800 milliseconds, with a confidence score and human-override flags.
E. Zero-Latency Production Bundle
- Engineered the frontend in React 19, TypeScript, and Vite, with curated HSL dark-mode glassmorphic styling.
- Compiled the static bundle directly into the FastAPI backend service so the entire application can boot with zero external Node runtime dependencies on AWS EC2.
4. When Disaster Strikes: The 21:15 Disruption Test
A system is only as good as its behavior when things break. During our live demonstration, we injected a hardware failure: Charger C04 trips offline at 21:15, stranding 4 vans assigned to that bay.
Here is what happened under the hood across AWS:
Plain text
1. FAULT DETECTED ──> Hardware sensor sends MQTT trip to Amazon EventBridge.2. AGENT ACTIVATED ─> Amazon Bedrock (Claude 3.5 Sonnet) parses the failure event.3. SOLVER RE-RUN ───> Re-evaluates remaining 9 healthy chargers with OR-Tools CP-SAT.4. VALIDATION ──────> Deterministic validator confirms zero transformer overload.5. HITL COCKPIT ────> Operator inspects delta in UI and clicks "Approve".6. DISPATCH ────────> Plan committed to DynamoDB; CloudWatch metrics updated.
Total time from hardware trip to validated, approved schedule: < 0.8 seconds. Zero missed departures. Zero transformer overloads.
5. The AWS Cloud Architecture
Our backend interfaces with real AWS cloud infrastructure in
us-east-1 :plaintext
┌───────────────────────────┐│ AWS CLOUD RUNTIME ││ Account 6005586110 │└─────────────┬─────────────┘│┌───────────────────────┼───────────────────────┐▼ ▼ ▼┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐│ Amazon DynamoDB│ │ Amazon Bedrock │ │ Amazon EventBridge ││ 4 Live Tables: │ │ Claude 3.5 Sonnet │ │ Disruption & Tariff││ • FleetState (40) │ │ Agent Reasoning │ │ Event Routing Bus ││ • ChargerState (10)│ │ & Roster Ingestion │ └────────────────────┘│ • Schedules (34) │ └────────────────────┘ ││ • Disruptions (4) │ ▼└────────────────────┘ ┌────────────────────┐│ │ Amazon CloudWatch │└───────────────────┬────────────────┤ Operational Alarms │▼ │ & Carbon Dashboard │┌────────────────────┐ └────────────────────┘│ Amazon EC2 ││ t3.small Instance││ (Live Public App) │└────────────────────┘
- Amazon DynamoDB: Stores fleet state, charger telemetry, and versioned schedule state machines using Pay-Per-Request (On-Demand) capacity.
- Amazon Bedrock: Powers autonomous operational re-planning and unstructured logistics parsing using Anthropic Claude 3.5 Sonnet.
- Amazon EventBridge: Decouples event generation (charger tripping, late arrivals, carbon forecast spikes) from scheduler dispatch.
- Amazon CloudWatch: Monitors operational metrics, peak kW demand, and triggers automated alerts if load ever approaches 245 kW.
- AWS CDK (Python): Enables 1-command deployment (
./deploy_aws.sh) of the entire infrastructure.
6. The Hard Numbers: Verified Impact
We benchmarked DECARB-EV against typical industry-standard unmanaged charging across a full 40-van, 10-charger overnight operational cycle:
Metric | Baseline (Unmanaged) | DECARB-EV Optimized | Net Impact |
|---|---|---|---|
Grid Carbon ($\text{kg CO}_2\text{e}$) | 1,517.6 kg | 906.8 kg | 🌱 -40.3% (610.9 kg avoided) |
Electricity Cost | ₹19,918 | ₹8,008 | 💰 -59.8% (₹11,910 saved/night) |
Peak Transformer Demand | 482.6 kW (OVERLOAD) | 250.0 kW (SAFE) | ⚡ -48.2% peak shaved (Within limit) |
Departure Punctuality | Infeasible (Trips grid) | 100.0% | 40 / 40 Vans ready by 06:00 |
Capital Expenditure Avoided | ₹4.5 Crore upgrade | ₹0.00 | Software replaces hardware upgrade |
Across an annual 365-day operational cycle for a single delivery depot, that translates to:
- ~223 metric tonnes of $\text{CO}_2\text{e}$ abated.
- ₹43.4 Lakhs (~$52,000 USD) saved on utility bills.
- Immediate fleet electrification without waiting 24 months for utility approval.
7. What We Learned & What's Next
- AI belongs in the orchestration loop, not the calculation loop. By pairing Amazon Bedrock for contextual reasoning with Google OR-Tools for mathematical optimization, we built a system that is both intelligent and physically safe.
- Operations teams need explainability. Nobody trusts a black-box AI schedule. Providing plain-English rationale and deltas in the UI transformed skepticism into immediate buy-in.
- Software-defined infrastructure is the fastest path to decarbonization. Before spending millions digging trenches for bigger power cables, algorithmic efficiency can unlock 48% more headroom on existing assets.
🌐 Explore the Project
- GitHub Repository: github.com/sarthakv162/DECARB-EV
- Team: AWSsome Builds
- Riddhima (Member 1): Mathematical Optimization & Operations Research
- Roopanshu (Member 2): Backend Systems & Agentic Orchestration
- Sarthak Verma (Member 3 & Lead): Cloud Infrastructure & DevOps
- Taksh Pal (Member 4): Fleet Operations UI/UX & Systems Integration
If you’re excited about the intersection of Generative AI, operations research, and sustainable cloud computing, give the repo a star or drop your thoughts in the comments below! 🚀
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article