PipeGuard

A pipeline compressor turbine wears out silently and then fails suddenly. Operators service on a calendar or after the breakdown, so they either waste crew time or lose gas flow. A maintenance team needs more than a risk score. They need to know which unit needs attention, why the recommendation changed, and what to do next within the crews they actually have. We framed the product around that decision, not around a model output.

I built the manager dashboard (fleet, weekly plan, decision log and impact), the technician's phone page, and the voice agent that closes the loop: it phones the on-call technician about a unit at risk, and their spoken answer becomes a constraint that re-plans the week. I also shaped and delivered the pitch. The prediction engine and the backend were built by my teammates.

The call is not decoration, so the agent is wired into the system rather than just prompted. Four authenticated server tools run mid-call against our API: submit availability (which re-plans the week), file a field report, record a feedback verdict, and read a unit's status. Our server mints a short-lived signed URL per call and injects the unit, station, remaining-life range and reason as variables, so the agent only speaks facts we pass in and cannot invent numbers or engineering instructions.

It confirms unclear answers back before acting ("So Friday, correct?"), says it is an automated dispatcher assistant when asked, and declines off-topic requests. The browser never sees an API key, tool endpoints require a bearer secret, webhooks are signature-verified, and every action lands in the decision log. If the voice service is down, a one-click simulated call replays a recorded conversation through the same code path.

PipeGuard recommends; people decide. A manager approves every work order, and the system is read-only: it never writes to a control system. A broken sensor triggers an instrument check, never a crew call. A unit must stay in the danger zone for three readings in a row before an alert, and units with no feasible slot are flagged "needs manager decision" instead of failing silently.

To avoid alarm fatigue, calls go only to top-priority units, with a daily cap per technician and no repeat call for the same unit within a window. If nobody answers, a backup technician is rung after 30 seconds and then the manager is alerted. If the technician is only free after the unit may already have failed, the agent says so honestly and the manager is alerted in the app.

I chose the model inside the agent with a frozen test suite instead of a leaderboard: 26 tests, including eight demo-critical tool-call cases run twice, seven held-out tests worded differently from anything in the prompt, a prompt-injection test and three full simulated calls with mocked tools. Five candidate models were run against it, and the protocol was written before the final run so a test could not be bent until a model passed.

A failing test exposed a real agent bug (an unasked verdict after a work note). I fixed it in the prompt, not by loosening the test, then removed every test phrase from the prompt so passing meant something. Gemini 3.8 Flash passed 16 of 16 critical runs at about half the cost of the nearest finalist, with a median reply time of 1.2 seconds on real calls. Each test ran only once or twice and the caller was a synthetic voice, so I report it as good evidence, not proof.

The predictive engine was built on the public NASA C-MAPSS turbine dataset, used as a stand-in because operators do not publish turbine sensor data. It predicts remaining life as a range and was cross-fitted so every demo turbine is scored by a model that never saw it. I integrated its outputs into a visible risk signal, a manager approval step and a decision record, so each recommendation is inspectable.

The result is a working decision flow: detect a unit at risk, propose a maintenance change, phone the technician, re-plan from their answer and keep the decision trail. In simulation it caught 96 of 100 failures at least 14 days early with no false alarms, at $4.12M against $6.74M for a fixed schedule. The data, technicians and dollar figures are all simulated for the hackathon. It is deployed with 343 automated tests passing across the backend, engine and dashboard.