AlarmReady

Inspiration

A raw alarm is just a signal. It may show a code, timestamp, asset, and severity, but it rarely answers the operational question: what should happen next? That decision may depend on:

• recent alarms on the same asset
• open or recently closed work orders
• production impact
• operating conditions
• safety or SLA relevance
• missing evidence

The obvious AI approach would be to paste an alarm into a model and ask for the next action. I deliberately avoided that. In operational workflows, the main risk is not only that AI may be wrong. It may sound confident while important context is missing. AlarmReady, therefore, focuses on supporting human validation rather than automating the decision.

What it does

AlarmReady supports one narrow workflow moment: after an alarm appears, but before work is created, updated, escalated, or deferred.

The architecture is: System context input → LLM extraction → human confirmation → deterministic triage → Validation Summary → Human Decision → optional Decision Brief → feedback

The prototype accepts:

• current alarm
• recent alarms
• related work records
• operating context

The LLM converts messy text into structured fields. The user must confirm the extracted information before the triage logic can run. Deterministic checks then surface:

• context completeness
• related-work and recurrence risk
• priority drivers

The main output is a Validation Summary showing what is known, what is uncertain, and what decision now requires human judgment. The user then selects the final action. An optional Decision Brief documents the issue, decision basis, requested action, and evidence or escalation trigger. AlarmReady does not diagnose faults, dispatch technicians, or modify work orders automatically.

How we built it

AlarmReady was built with:

• Next.js and TypeScript
• OpenAI API for structured extraction and generated text
• deterministic TypeScript rules for triage
• a curated Sungrow fault-code reference
• Supabase for privacy-safe feedback storage
• Vercel for deployment
• Novus/Pendo for instrumentation and UX review

The architecture separates responsibilities:

• the LLM structures messy context
• deterministic rules surface constrained checks
• the human confirms the data and owns the decision

The application also invalidates downstream outputs when confirmed input changes. This prevents stale triage results or decision artifacts from remaining visible after the underlying context has been edited. For public testing, users are instructed to use synthetic or non-confidential data only. Raw operational inputs are not stored in the feedback database.

Challenges we ran into

1. Defining where the AI should stop The easiest implementation would have been to let the model diagnose the alarm and recommend an action directly. The harder design choice was to limit the LLM to extraction and communication support, while keeping triage constrained and the final decision human-owned.

2. Preventing false confidence Extracted information is not automatically reliable. I had to design confirmation states, stale-data handling, and downstream invalidation so that parsing errors could not silently influence the decision flow.

3. Reducing cognitive load An early version emphasized a long Pre-WO Diagnostic Brief. Feedback from a solar O&M practitioner highlighted that operator attention is limited and that existing systems already contain diagnostics, rules, and ticket history. This changed the product direction. The Validation Summary became the primary artifact, while the longer Decision Brief became optional.

4. Representing production reality The public prototype relies on manual input because it is not connected to live SCADA, monitoring, CMMS, or document systems. In production, the harder problem would be retrieving the right context, keeping it fresh, mapping it to the correct asset, respecting permissions, and knowing where human validation is still necessary.

5. Testing without usage data The app is publicly deployed, but it has not yet received visitors. This means I cannot claim user adoption, workflow validation, or measurable operational impact. So far, the strongest evidence comes from the working prototype, external critique, and the product refinements made in response.

Accomplishments that we're proud of

• Built and deployed a working end-to-end prototype
• Created a clear separation between LLM extraction, deterministic checks, and human decision-making
• Added confirmation and stale-state controls so unverified data cannot drive triage
• Refined the product after feedback from a solar O&M practitioner
• Shifted the main artifact from a long AI-generated brief to a compact Validation Summary
• Added privacy-safe feedback collection without storing raw operational data
• Created a realistic synthetic inverter scenario that tests duplicate-work risk and evidence gaps
• Documented the product reasoning through a long-form case study and demo video

What we learned

The project changed my view of where AI can add value in operational software. Many operational systems already have signals, rules, diagnostics, tickets, and automation. The gap is not always missing intelligence. Often, the harder gap sits between existing system context and accountable human action:

• what is known
• what is inferred
• what is missing
• what requires validation
• who owns the decision
• what evidence should be recorded

The most useful AI product is not always the one that acts fastest. Sometimes it is the one that slows the workflow down at the exact point where uncertainty, judgment, and accountability matter.

What's next for AlarmReady

The next step is not to add more AI. It is to test whether the Validation Summary is useful to real operators, reduce manual input through better context integration, and learn where the workflow feels helpful, unrealistic, or burdensome.

The main open questions are:

• Which context should be retrieved automatically?
• Which information still requires human confirmation?
• Are the triage signals operationally meaningful?
• Does the workflow reduce duplicate work or improve handover?
• Can the summary remain useful while becoming much more compact?

AlarmReady is still a product hypothesis. Its current value is that it makes the trust boundary visible enough to test and critique.

Built With

• codex
• next.js
• supabase
• vercel