Inspiration

We've all seen it: a road gets freshly paved, and three weeks later a crew tears it right back open to reach a pipe underneath. Cities plan their water, drainage, fiber, and repaving work in separate silos, so the same street gets dug up over and over. It wastes money and closes roads for no real reason. We kept thinking: what if someone coordinated all of it before any of the work went out to bid? That's InfraSync.

What it does

InfraSync takes all the projects a city already plans to build across its streets and turns them into one coordinated schedule. It automatically spots "dig once" opportunities, meaning two jobs that could share a single trench instead of digging twice, and shows exactly how much money and how many road-closure days that saves. In our demo district, coordinating the water main and fiber conduit on one avenue saves an estimated $115,000 on a single pair.

Then it handles the real world. You describe a disruption in plain English, like "a water main rupture on 7th Avenue forces a 14-day emergency closure," and InfraSync re-plans the whole schedule in seconds, shows you the before and after, and writes a plain-English explanation of what changed and why. Nothing is decided behind your back: a human reviews every proposal and approves it.

The whole idea is a clean split of labor. The planner decides, the AI explains, and a person stays in control.

How we built it

  • The schedule is built by a constraint solver (Google OR-Tools). We give it the hard rules a city can't break, like crew limits, funding windows, pavement moratoriums, and "don't close two parallel streets at once," and it finds a schedule that respects every one of them. Because it's a solver and not a guess, the plan is provably valid every time.
  • The explanations come from NVIDIA's Nemotron model, running on Nebius Token Factory. When you type a disruption, Nemotron reads it, turns it into a rule the solver understands, and then narrates the result using only the solver's real numbers, so it never makes figures up.
  • The app is a React front end with a live map and a timeline, talking to a Python and FastAPI back end.

Challenges we ran into

  • We came into this as near-beginners, so a lot of it was learning React, TypeScript, Python, and how constraint solvers even work, all while building.
  • Teaching the solver judgment. It shouldn't blindly merge every pair of jobs, so we modeled co-trenching as a real decision: it takes an obvious win but declines a merge that isn't worth the hassle.
  • Keeping the AI honest. Nemotron is a reasoning model, and it kept "thinking" until it ran out of room and returned nothing. We fixed it by turning its reasoning mode off and feeding it only the solver's facts, so every sentence it writes is grounded.
  • Keeping the front end and back end speaking the exact same language as the project grew.

Accomplishments that we're proud of

  • It actually works, end to end: a real solver, a real AI explanation, and a real human approval step, not a mockup.
  • The AI never invents a number. Every figure on screen comes straight from the solver.
  • As two people pretty new to this, we shipped something we'd genuinely want a city to use.

What we learned

  • The most useful AI systems know when not to use AI. Let deterministic code be exact where it has to be, and let the model do the messy, human part: reading plain English and explaining decisions.
  • How a constraint solver turns real-world rules into a provable schedule.
  • How to call an open model through Nebius Token Factory, and the very real gotchas (reasoning modes, token budgets) that decide whether it works at all.
  • How to actually work as a team: branches, pull requests, and scoping ruthlessly against a deadline.

What's next for InfraSync

  • Real city data and geometry, so "dig once" pairs are detected from actual maps instead of being hand-labeled.
  • Live, cited engineering rules (which utilities can legally share a trench) so the recommendations stand up to a real engineer.
  • Deployment, multi-user plans, and bigger districts.
  • Most importantly, validating it against a real infrastructure owner. Today it runs on one honest, synthetic district. The next step is proving the savings on real portfolios.

Built With

Share this project:

Updates

Submission history