The Product Problem Behind Alarm Triage
What I learned building AlarmReady, a small AI prototype for solar alarm triage, and why the hard product problem is not automation but operational trust
A raw alarm is just a signal. It can tell you that something happened. It may show you an alarm code, timestamp, asset name, and severity. However, it does not automatically tell a monitoring engineer what should happen next. For example, should this be monitored, should someone verify it, should an existing work order be updated, should a new work order be created, or should the issue be escalated?
The answer usually depends on context outside the alarm itself: recent alarms on the same asset, related work records, site conditions, production impact, service-level constraints, safety relevance, and whether the issue has already been closed once before.
This is where many AI product ideas in operations take the wrong shortcut. The tempting move is to build a system that reads the alarm and directly recommends the action. But in operational software, especially where field work, safety, cost, and accountability are involved, the hard product problem is not simply generating a confident answer.
The harder problem is designing the trust boundary between messy signals, missing context, human judgment, and accountable action. This is the product question behind AlarmReady, a small public prototype I built for an AI product hackathon. The prototype explores whether AI can help solar monitoring teams structure the context around an alarm before a human decides what to do next.
The Tempting Shortcut
The obvious AI prototype would be an alarm-to-action recommender. The user pastes an alarm into a box. The model explains what it means. The product returns a recommended action. For a demo, that would look impressive. Unfortunately, it would also be the wrong starting point.
In solar operations, an alarm is rarely interpreted in isolation. The same alarm code can mean different things depending on the asset, recent alarm pattern, weather conditions, known site issues, related work orders, production impact, safety relevance, and what has already been tried.
The risk is not only that the AI might be wrong. The larger risk is that it might sound confident, while important context is missing. A model might recommend creating a new work order without knowing that one is already open for the same inverter. It might treat a repeated alarm as a fresh event, even though a related issue was closed recently without enough evidence. It might focus on the alarm code while missing the operational questions.
That distinction matters because operational decisions create consequences. They can trigger field work, consume technician time, affect safety exposure, change priorities, and shape the evidence available for later review. So I deliberately avoided designing AlarmReady as an “AI decides what to do” tool. The product goal is narrower, which is to help the user assemble and validate the context around the alarm before a decision is made.
AlarmReady uses an LLM to structure messy operational text, but it does not treat the LLM output as truth. Extracted information must be confirmed before it feeds the triage checks. The checks then surface the decision frame. The human still selects the final operational decision. In other words, the product does not try to remove judgment from the workflow. It tries to make the judgment point clearer.
Designing The Trust Boundary
Once I decided not to build AlarmReady as an “AI decides what to do” tool, the product question changed. The challenge was no longer how to generate the most confident recommendation from an alarm. It was how to design a workflow where messy operational context could be structured, uncertainty could be made visible, rules could constrain the decision space, and the human reviewer could still own the final operational decision.
The resulting architecture became deliberately staged:
System context input → LLM extraction → Human confirmation → Deterministic triage → Validation summary → Human decision → Optional decision brief → Feedback
Each step has a different job. The LLM turns messy operational context into structured input. Human confirmation prevents extracted information from being treated as truth too early. Deterministic triage keeps the core checks constrained and inspectable. The Validation Summary becomes the main decision-support layer. The Decision Brief is not the product’s centre of gravity, but a supporting artifact for documentation and handover after the decision path is clear.
The trust boundary is simple: the LLM is allowed to structure context, but not to own decision. It can extract alarm details, work-record signals, operating context, and relevant notes from messy inputs. However, the extracted context must be confirmed before it becomes usable. The deterministic triage layer can then surface constrained checks such as context level, related-work risk, and priority. The Validation Summary translates those checks into a compact decision frame. The human still decides whether to monitor, verify, update existing work, create new work, escalate, defer, or mark the alarm as not actionable.
This sequence is not only a workflow choice but a risk-control choice. Jumping from raw input to a recommendation can turn incomplete context into false confidence. Treating extracted information as truth can turn a parsing mistake into an operational assumption. Letting generated text own the triage logic can make the decision basis harder to inspect. Producing a polished brief too early can shift attention from the real question: what should the human decide next? The sequence is designed to slow the system down at the points where trust, evidence, and accountability matter most.
Four design principles followed from this boundary.
1. Context before action
Alarm triage should not begin with the question, “What should the AI recommend?” It should begin with, “What context is available or missing, and what decision is actually being made?” In solar operations, the alarm code is only one part of the picture. Recent alarms, related work records, site conditions, production impact, service-level constraints, and safety relevance can all change the meaning of the same alarm. Therefore, AlarmReady starts by assembling the system context before moving toward any decision frame.
2. Confirmation before computation
LLM extraction is useful because operational input is often messy. Unfortunately, extraction is not the same as truth. If the system extracts the wrong asset, misses an open work order, or misreads a note, downstream logic can become misleading. For that reason, AlarmReady requires human confirmation before the extracted context can feed deterministic triage. The product treats confirmation as part of the workflow, not as a cosmetic review step.
3. Deterministic checks before generated narrative
The core triage frame should be constrained and inspectable before any polished narrative is generated. AlarmReady uses deterministic checks to surface context-level, related-work/recurrence risk, and normalized priority. This makes the basis for the decision easier to inspect. The LLM can help structure input and later help express the decision clearly, but it should not be the hidden source of the triage logic. In operational software, explainability is not only about model transparency. It is also about making the decision basis visible enough for a human to challenge.
4. Human decision before documentation
A brief or note is useful only after the decision path is clear. Otherwise, the product risks optimizing for a well-written artifact instead of a better operational choice. That is why AlarmReady places the Validation Summary before the Human Decision, and the optional Decision Brief after it. The human reviewer still chooses whether to monitor, verify, update existing work, create new work, escalate, defer, or mark the alarm as not actionable. The system can support the decision, but it should not blur who made it.
These principles became the shape of AlarmReady. The prototype is intentionally small. It does not try to become a monitoring platform, CMMS, or autonomous dispatch layer. Instead, it focuses on one narrow decision moment: when a monitoring signal has appeared, some surrounding context is available, and a human needs to decide what should happen next. The product question is not, “Can AI generate an impressive answer?” but, “Can the system help the user reach a better-validated operational decision with less ambiguity and less handover loss?”
From System Context To Human Decision
AlarmReady tests one specific decision moment: after a monitoring signal appears, but before a team creates new work, updates existing work, escalates, or decides to wait. That moment is small but operationally important. It is where alarm data, recent history, work records, site context, and human judgment need to come together. I deliberately kept the prototype focused on this point because the goal was not to build a monitoring platform or an autonomous O&M assistant. The goal was to test whether a clearer validation layer could reduce ambiguity before an operational decision is made.
In the hackathon prototype, the user manually provides the current alarm, recent alarms, related work records, and operating context. That is not meant to be the ideal product workflow. I made the input explicit so the decision process could be tested in public without requiring access to real SCADA, monitoring, CMMS, or document systems. In a production version, much of this context would ideally be pulled from existing operational systems. The product challenge would then shift from manual data entry to source reliability, context freshness, asset mapping, permission boundaries, and deciding where human validation is still required.
The LLM layer is used for extraction, not authority. Operational context is often messy. An LLM is useful here because it can turn messy input into structured fields that are easier to inspect. However, AlarmReady does not allow extracted information to silently become the basis for triage. The user has to confirm the extracted alarm details, recent alarm signals, related work records, and operating context before the deterministic checks can run. The confirmation step keeps the system from treating a parsing mistake, a missing field, or an ambiguous note as an operational fact.
Once the confirmed context is available, AlarmReady runs deterministic triage checks. These checks are intentionally limited. They do not try to diagnose the root cause or decide on the final action. Their job is to make the operational situation easier to inspect. For example, is there enough context to act, or is there already an open or recently closed work order, or is the issue recurring, or is the priority being driven by severity, safety relevance, SLA pressure, production impact, or recurrence? By keeping this layer rule-based and constrained, the prototype makes the decision basis visible enough for a human reviewer to challenge.
The Validation Summary is the main decision-support artifact. It is not meant to be a polished report, but a compact decision frame showing what is known, what is uncertain, what risk signals are present, and what decision the human now needs to make. This matters because operators do not always need more text. They often need a clearer view of the next choice. By placing the summary before the human decision, AlarmReady keeps attention on validation and actionability rather than generating documentation too early.
After the Validation Summary, the reviewer still has to choose the operational decision. That choice remains explicit. AlarmReady can suggest a likely decision path, but the user still owns the selection. Only after that does the optional Decision Brief become useful. Its job is not to make the decision on behalf of the user. Its job is to document the decision path in a clearer form, illustrating the current issue, decision basis, requested action, and evidence or escalation trigger. In that sense, the brief is not the intelligence layer but the handover layer.
The final step is feedback, because the prototype is not trying to prove that the workflow is already correct. It is trying to learn where the decision-support frame helps and where it breaks down. A useful prototype should make disagreement easier to see: which triage signal felt useful, which part felt too simplistic, whether the suggested decision path matches operational reality, and whether the output would actually support handover. For this reason, AlarmReady asks for feedback after the decision flow, not before it. The goal is to learn from the user’s experience of moving through the workflow, not just from their first impression of the interface.
The clearest way to understand the prototype is not as a set of screens, but as a test of decision readiness. Can the system take a messy operational context, make the relevant signals easier to inspect, preserve human accountability, and produce a decision path that is useful before work is created or updated? To make that less abstract, I used a synthetic solar O&M scenario built around a Sungrow SG350HX inverter alarm with fault code 39 (low system insulation resistance). The interesting part of the scenario is not the alarm code itself. It is what happens when that alarm appears alongside recent alarm history, an already open work order, a previous close-out, and the site operating context.
When An Alarm Should Update Work, Not Create More Work
To test the workflow, I used a synthetic scenario around a Sungrow SG350HX string inverter showing fault code 39 (low system insulation resistance). I chose this scenario because it is specific enough to feel operational, but ambiguous enough to test the product boundary. The alarm appears during morning ramp-up after overnight rain. There is recent alarm activity on the same inverter, a small production underperformance compared with peer inverters, an already open work order for related string and MPPT inspection, and a recently closed DC connector inspection without complete evidence attached.
The alarm code alone does not answer the operational question. Fault code 39 may be safety-relevant and worth attention, but it does not automatically tell the reviewer whether to create new work, update existing work, verify, escalate, or wait for additional evidence. The decision depends on context, like whether the alarm is isolated or recurring, whether the site conditions make a transient event plausible, whether production impact is material, whether related work is already open, and whether a recent close-out actually contains enough evidence to trust that the issue was resolved. Without that context, the product can easily create the wrong kind of confidence: a clear recommendation built on an incomplete picture.
In this scenario, AlarmReady does not try to declare the root cause. Instead, it surfaces the decision signals around the alarm. The context level is high because the current alarm is connected with recent alarm history, related work records, and operating context. The related-work risk is present because an open work order already exists for the same inverter, and a recent close-out may be relevant but under-evidenced. The normalized priority is shaped not only by the alarm code but also by safety relevance, service-level sensitivity, recurrence risk, and the limited production impact. The work-order readiness signal is therefore not a simple “create new work order.” It points toward updating existing work and requesting clearer evidence before creating duplicate work.
The product judgment in this scenario is that the best next step is probably not to create another work item immediately. The more useful path is to update the existing work order with the new alarm context, request missing evidence, and verify whether the issue persists or repeats before opening duplicate work. That is a subtle but important distinction. AlarmReady is not trying to answer, “What is the fault?” It is trying to help answer, “What is the next accountable operational move, given what we know and what is still uncertain?”
This scenario also exposed the next product question. The decision-support logic may be useful, but the prototype form is still input-heavy. In the public hackathon version, manual input makes the trust boundary visible. However, in a real O&M environment, operators would not want another tool that asks them to re-enter context already sitting inside monitoring systems, SCADA, CMMS, ticket history, or internal documents. That became the bridge to the most useful external critique I received: the product should not become a standalone AI assistant layered on top of existing tools. It should behave more like a compact validation and decision layer around the context that operational systems already know.
What Real-World Feedback Changed
The Sungrow scenario helped validate the decision-support logic, but external critique sharpened the product shape. One reviewer from the solar O&M community pointed out that the workflow problem was relevant, but the prototype still needed to respect the reality of O&M work. O&M attention is scarce. Monitoring systems and SCADA platforms already contain deterministic intelligence, pre-loaded conditions, diagnostics, and ticket history. Many O&M systems are also starting to use AI agents to propagate changes automatically. Against that background, a prototype that mainly asks users to input context and then produces a long pre-work-order artifact risks adding friction instead of reducing it.
That critique sharpened the product direction. AlarmReady should not behave as a standalone AI assistant layered on top of existing operational tools. It should behave more like a compact validation and decision layer around context that operational systems already know or can retrieve. The product should not compete with SCADA diagnostics, CMMS history, or automation agents. It should help the human reviewer see where validation is still needed.
That changed the centre of gravity of the prototype. The most important artifact is no longer the generated Decision Brief. The more important artifact is the Validation Summary, which is a compact view of known context, uncertainty, related-work risk, priority drivers, and the decision that now requires human judgment.
This also reframed what the system should suggest. The highest-value suggestions are not generic “next best action,” but the actions that require human input, validation, or accountability, such as confirming whether this is linked to existing work, deciding whether remote verification is enough, requesting missing evidence, choosing whether to escalate, or documenting why the issue should be deferred or marked as not actionable. In other words, the product refinement was not “make the AI smarter,” but “make the human decision point sharper.”
What This Prototype Does Not Prove
AlarmReady is a public prototype, not production operational software. Its purpose is to test a workflow hypothesis: whether AI-assisted context structuring, deterministic triage checks, and an explicit human validation step can make alarm-to-action decisions clearer before work is created or updated. It does not prove operational impact, reduce truck rolls, improve response time, or validate safety outcomes. Those claims would require testing inside real O&M workflows with real system integrations, operator behaviour, and outcome tracking. At this stage, the prototype is useful because it makes the decision boundary visible enough to critique.
The largest production limitation is data integration. In the prototype, the user manually provides alarm details, recent alarms, related work records, and operating context. That makes the workflow visible and safe to test publicly, but it is not how this should work in a real O&M environment. In production, much of that context would need to come from monitoring systems, SCADA, CMMS, ticket history, diagnostic tools, and internal documentation. The hard product problem would shift from “can the user provide enough context?” to “can the system retrieve the right context, keep it fresh, map it to the correct asset, respect permission boundary, and know which parts still require human validation?”
The decision logic is also intentionally limited. AlarmReady’s deterministic triage checks can surface context level, related-work risk, recurrence risk, and normalized priority, but they are not a production-grade risk model. They do not replace OEM guidance, site-specific alarm logic, safety procedures, dispatch rules, or an operator’s judgment. The system does not diagnose the root cause, confirm whether an insulation fault exists, or decide that field work should happen. Its role is narrower: to make the decision basis earlier to inspect before the human reviewer chooses the next operational action.
The user experience still needs validation with real operator workflows. O&M attention is scarce, interrupt-driven, and often shared across alarms, tickets, calls, and field coordination. A useful validation layer cannot ask the user to read a long explanation every time an alarm appears. It needs to show the minimum decision-relevant signals first, then let the user drill into detail only when needed. That means the Validation Summary should become more compact, the default view should prioritize actionability and uncertainty, and the optional Decision Brief should remain secondary. The next UX question is not how much the system can explain, but how little it can show while still supporting a safe and accountable decision.
Even with these limitations, the prototype was useful because it clarified the product boundary. The next step is not simply to add more AI or generate a longer brief. It is to reduce operator burden, improve context integration, and make the human validation point sharper. AlarmReady’s value, if it has one, sits in the narrow space between existing system intelligence and accountable human action: surfacing what matters, showing what is uncertain, and helping the reviewer decide what needs validation before work is created, updated, escalated, or deferred.
The Product Lesson
AlarmReady is a small prototype built around solar alarm triage, but the pattern it exposed is broader than one inverter scenario or one O&M workflow. Many operational environments already have signals, dashboards, rules, diagnostics, tickets, and increasingly automation. The gap is not always the absence of data or intelligence. Often, the harder gap sits at the decision boundary: which signals matter now, what context is trustworthy, what is still uncertain, what action requires human validation, and how that decision should be documented before work moves forward.
That is where the judgment layer matters. The useful AI product is not always the one that produces more recommendations or pushes the workflow forward faster. In some operational moments, the more valuable product is the one that helps the human reviewer slow down just enough to validate the situation: what is known, what is inferred, what is missing, what conflicts with the existing ticket history, and what action now requires accountability. This does not make AI less useful. It places AI where it can support the workflow without pretending that uncertainty, responsibility, or operational judgment have disappeared.
For me, this is the trust boundary that operational AI products need to make explicit. The system can structure messy context, but it should not silently turn that context into truth. Rules can surface constrained checks, but they should not pretend to cover every site-specific procedure or edge case. A summary can make the decision frame easier to inspect, but it should not replace the human decision. A brief can document the path, but it should not disguise who made the call. The product architecture matters because it determines where confidence is created, where uncertainty is preserved, and where accountability remains visible.
A raw alarm is just a signal. A useful operational AI product should help turn that signal into a decision without pretending the decision has disappeared. It should surface context, preserve uncertainty, support validation, and make accountability easier to see. That is the lesson AlarmReady helped me clarify:
In operational systems, the best AI is not always the one that acts fastest. Sometimes it is the one that knows where to stop.