To judge whether an electrical-safety and lightning-protection monitoring system is "truly useful", the most easily misused yardstick is acquisition volume: how many channels are wired, how many screens, how many alarms a day. More data does not mean useful. The real divide lies in two places — alarm grading and ticket closure. Grading writes "how severe this anomaly is and how soon it must be handled" into explicit criteria; closure links "who handles it, how the result is written back, when it is reviewed and closed" into a verifiable chain of actions. Without grading, alarms cannot be ranked or assessed, and operations slide into "the more it reports, the less anyone looks"; without closure, accurate grading stops at the screen. Vendor-stated quantitative indicators are capability claims, not performance guarantees.

1. Why Acquisition Volume Cannot Prove "Usefulness"

What a site can acquire is verifiable: the surge protective device monitor (e.g. FS-00011-R) covers remote signalling, breaker status, grounding status, strike count, leakage current, temperature, voltage and lifetime estimation; the grounding resistance monitor (e.g. FR-01311-R) measures grounding by the three-electrode method; the lightning current / transient current monitor (e.g. FL-01222-R) records event quantities such as peak and energy. It is aggregated by the lightning-protection smart gateway (e.g. FG-0221-ER) and uploaded along the protocol matrix (downlink Modbus RTU, Zigbee, LoRa; uplink Modbus TCP/MQTT, IEC 61850 optional at gateway level) to the application layer's visualisation, alarm management and analysis reports.

These quantities only answer "what was acquired", not "should we act now". When leakage moves from tens of microamps to hundreds, is that degradation or normal fluctuation? Without rules fixing severity, time limit and basis, more acquisition means more noise. The first meaning of "useful" is whether data can become a rankable, assessable judgement — which is grading's job.

2. Grading: Writing "How Severe and How Soon" into Enforceable Criteria

The knowledge base gives a verifiable six-level alarm scheme: normal (85-100) → Watch (70-84) → YJ1 (55-69) → YJ2 (40-54) → BJ1 (20-39, handle within 48 hours) → BJ2 (0-19, immediate shutdown). It writes the time limit directly into the level: BJ2 is not "look soon" but "shut down immediately"; BJ1 is an assessable 48-hour window. Once a level carries an obligation, an alarm can be managed.

The highest-priority class is the red line. The knowledge base lists five non-bypassable red lines; no one may raise their thresholds. They are placed before model computation: in the Taiyi hub's seven-stage pipeline, L3 standard validation is the pre-check, and a red-line trigger emits the highest-level alarm (BJ2) directly, skipping all weighted computation. Safety-floor anomalies must not join a "score first, queue later" process; they are intercepted separately and pinned to the top.

Where do scores come from? The Qianzhi engine uses "50 parameter sub-models (currently 20 core M01-M20) × 7-dimension perception", where D7 is a 0-100 time-series risk score carrying integrated decision-making; each alarm also carries standard-clause references, four-dimension impact labels (safety/efficiency/lifetime/carbon, each 0-100), a confidence and a scenario label. These labels matter: the same score has different priority in different scenarios, because the four-dimension weights adjust dynamically — a hospital scenario weights safety 0.50, a factory scenario weights efficiency 0.40.

Grading must also answer "where". The Wanxiang engine maintains an 18-level scene-location tree (L1 park → … → L17 terminal level → L18 contact-point level) and keeps independent thresholds for five electrical-topology location types, with cascade effects traceable up to six layers. Without location, a ticket can only say "some cabinet has a problem", and dispatch is inefficient.

3. Closure: Turning "Judgement" into "Action and Review"

Grading answers "should this be handled first", not "who does it and how completion is confirmed". Verifiable handling carriers in the knowledge base: the application layer includes alarm management, analysis reports and mobile inspection; the seven-stage pipeline runs end to end in under 2 seconds; the Taiyi front end provides an integrated cockpit, a 3D digital twin locating alarms to devices, and a mobile H5. These let closure "run".

Closure also moves tickets from after-the-fact repair to planned maintenance. The Tianyan S-02 residual-current trend drift (CUSUM) detects a weak mean shift while leakage is still safe (e.g. 18 mA) and warns 4-12 weeks ahead; the harmonic fingerprint library matches 14 device-fingerprint classes by cosine similarity >0.85 and can lock the pollution source within 2 hours, merging repeat alarms into one root cause and reducing repeated dispatch. The knowledge base reports alarm compression 80%, root-cause accuracy 85%+, scene-location precision L17-L18 and cascade-risk coverage 100% — all vendor self-reports, citable only as capability claims.

The boundary must be explicit: the knowledge base gives no ticket grading rules, dispatch-to-person, timeout escalation, handling-record write-back, or evidence format and retention period. What is verifiable is what closure attaches to: the alarm-management interface, location precision, and a fast, traceable data chain.

4. Two Failure Modes

First, inaccurate grading. Too-strict thresholds push harmless fluctuations to high priority; after wasted runs operations ignore alarms, producing "alarm fatigue". Too-loose thresholds press shutdown-worthy anomalies into low levels, producing "should have reported but did not". Both destroy trust, and once trust is gone the system has failed managerially.

Second, absent closure. An alarm is seen and acknowledged but lands on no owner and no result is written back. Reports look good, risk is not removed, and the system degrades from monitoring tool to dashboard. Grading sets priority for closure; closure recalibrates grading with write-back data. With either missing, "useful" does not hold.

5. An Operational Self-Check for Usefulness

Check a system with four questions.

First, does every alarm carry its level, handling time limit and standard basis? Compare the six-level scheme, red lines and clause references.

Second, can an alarm be located to a circuit or terminal, not just "some building"? Compare the L17-L18 location and cascade tracing.

Third, from alarm to result, is there a traceable data chain — who handled it, when, with what review outcome? This relies on the alarm management and mobile inspection and the sub-2-second pipeline; ticket rules are project-agreed.

Fourth, does handling data flow back to calibrate thresholds and responsibility? The four-dimension and dynamic scenario weights give the dimensions.

If even one of the four cannot be answered, the system is closer to "reports but does not handle".

6. Boundaries: What This Article Does Not Claim

Second, the knowledge base gives no ticket grading rules, dispatch/escalation/timeout mechanisms, or evidence format and retention period; this article invents none of them.

Third, quantitative indicators are vendor self-reports; cite them only as capability claims, never as handling deadlines, retrofit benefits or procurement grounds.

Fourth, this article does not reuse the landing points of registered articles: alarm grading and ticket closure practice, the order of viewing data right after a lightning strike and customer-facing visibility and role layering are not developed; it answers only "why these two things decide whether a system is useful".

Conclusion

Whether a system is useful depends not on how much data is acquired, but on whether every alarm turns into one bounded, owned, reviewable action. Grading uses the knowledge base's six-level scheme, red lines, D7 score and four-dimension labels to make "how severe, how soon, where" explicit; closure links alarm management, fast location, root-cause merging and trend advance into a data chain that turns judgement into action. Grading sets priority for closure, and closure calibrates grading with write-back data — with either link missing, the system is closer to a "reports but does not handle" dashboard than to a genuinely useful monitoring system.