GridWalk

80% usage of Jac
Side Menu
Graph
Dashboard
Detailed Description

A power failure forces engineers to decide under immense pressure who keeps electricity; often choosing between critical facilities like a hospital and non-critical ones like street lights. Realizing that human decision-making under such stress can be slow, our three-member team set out to build a simulator that automates this process. We wanted to create a system that could handle a sudden substation capacity loss, make a load-shedding decision in seconds, and transparently explain its reasoning.

How We Built It

We modeled the simulated power grid as a mathematical graph where power sources and load destinations act as nodes, and the connecting power lines act as edges. Sources supply a specific power limit (denoted inline as $P_{max}$ in kW), while loads consume power based on priority tiers: Tier 1 (critical), Tier 2 (essential), and Tier 3 (non-critical). The core grid logic is governed by the absolute constraint that total supplied power cannot exceed capacity:

$$\sum P_{supplied} \le P_{max}$$

We built the core engine, walkers, and AI planner in Jac, ensuring at least 80% of the project code utilized it. To coordinate our three distinct roles—the Engine, the Brain, and the Face—we relied heavily on GitHub for version control, branch merging, and synchronization. While the core logic ran in Jac, we utilized React.js and Node.js alongside an orange and white UI color scheme to construct the dashboard, providing a clear visual of the grid, the event log, and the fault injection buttons.

Challenges Faced

Our primary challenge was ensuring the AI didn't make dangerous or physically impossible decisions. If an AI handles a power grid, it cannot hallucinate a solution. We solved this by implementing a strict architectural boundary: the AI planner only proposes a recovery plan, but a deterministic code validator must approve it before any grid state changes actually occur.

Engineering the retry loop was particularly complex. If the validator rejects a plan, it must send the exact failure reason back to the AI planner for a retry. We also had to design a labeled fallback rule to safely step in and generate a plan if the AI exhausted all its retry attempts without finding a valid solution. Ensuring the system gracefully reported a total failure instead of pretending a broken grid had recovered required careful state management across our walkers.

What we Learned

This project reinforced that the most effective AI systems in critical infrastructure are bounded by strict mathematical constraints. We learned that while AI is incredibly powerful for proposing complex optimizations, deterministic code must always be the final decision-maker. Additionally, building the dashboard taught me how to effectively translate complex background operations into readable, real-time metrics for users, clearly showing the percentage of critical demand still served and the exact kW shed during a fault.