A digital lightning-protection platform must get two separate things right. The first is judging "what is abnormal, how serious it is, and how soon it must be handled" — alarm grading. The second is running "who accepts the ticket, how it is handled, how the result is written back, and when it is reviewed and closed" — the work-order loop. Grading is judgement; the loop is execution. Inaccurate grading lets the loop spin efficiently on nothing; a missing loop leaves accurate grading stranded on screen. Alarm grading has clear anchors in the knowledge base.
Two Separate Jobs: Alarm Grading and the Work-Order Loop
Some platforms' alarms seem impossible to watch, or get reported with nobody acting, because these two jobs are merged into one: the assumption that colouring alarms red, yellow and blue makes handling happen. In fact grading only answers "should this be handled first", not "who handles it". Once separated, the design priorities are clear: grading must be explainable, traceable and defensible; the loop needs ownership, a deadline, write-back and review.
Alarm Grading: The Verifiable Rules the Knowledge Base Gives
Grading begins with explicit score bands. The knowledge base defines six levels: Normal (85-100) → Watch (70-84) → YJ1 (55-69) → YJ2 (40-54) → BJ1 (20-39, handle within 48 hours) → BJ2 (0-19, shut down immediately). The band itself carries a deadline: BJ2 is not "look soon" but "shut down immediately", and BJ1 is an auditable 48-hour window. Grading also hard-codes authority — the five red lines cannot be bypassed and no one may raise their thresholds.
Red lines are the highest-priority class. The knowledge base lists each one: residual current ≥300 mA (GB 13955); abnormal open circuit of the grounding resistance (GB 50057); three-phase voltage unbalance >15% (GB/T 15543); line temperature ≥110 °C (GB 16895); insulation resistance <0.5 MΩ (GB/T 16895). They sit before model computation: L3 standard validation in the Taiyi seven-stage pipeline is the red-line pre-check, and a trigger emits the top-level alarm (BJ2) directly while skipping all weighted calculation. Safety-baseline alarms should thus not enter a "score everything, then sort" step; they are intercepted separately and pinned to the top.
Where do the scores come from? In the knowledge base, the Qianzhi engine uses "50 parameter sub-models × 7 sensing dimensions", of which D7 is the composite decision dimension producing a temporal risk score (0-100). Each alarm also carries a standard-clause citation, four-dimension impact labels (safety/efficiency/lifetime/carbon, each 0-100), a confidence value and a scenario label. The labels matter more during execution: the same score does not carry equal priority everywhere, because the four weights are rebalanced by scenario — safety weighs 0.50 in a hospital and efficiency 0.40 in a factory.
Grading must also answer "where". The Wanxiang engine maintains an 18-level scenario localization tree (L1 campus → … → L17 terminal-block level → L18 contact-point level) and keeps independent thresholds for 5 electrical topology position types, with cascading impacts traceable up to 6 layers. Without this, a ticket can only say "something is wrong with a cabinet", making dispatch inefficient.
What Grading Leaves Out, and What the Loop Still Lacks
Grading answers "how serious and how soon", but not "who does it, what they do, and how completion is confirmed". The knowledge base offers three timing anchors: BJ2 immediate shutdown and BJ1 handling within 48 hours; an L3 red-line trigger emitting the top alarm; and an end-to-end pipeline under 2 seconds, so alarms are generated and located quickly. At the application layer the platform already provides alarm management, analysis reports and mobile inspection. But the knowledge base does not state how tickets are graded by level, dispatched to a person, escalated on timeout, written back, or what evidence format and retention period apply.
The Five Steps of the Work-Order Loop
Step one, trigger. An alarm is graded through the six levels; red-line classes are intercepted as BJ2 and do not enter weighted sorting.
Step two, dispatch. Assign an owner by alarm level and scenario location (L17-L18); multiple alarms at the same physical position can merge into one ticket to cut repeat site visits.
Step three, handling. Execute against the level's deadline — BJ2 immediate shutdown, BJ1 within 48 hours; deadlines for the remaining levels are not set by the knowledge base and should be agreed per project. Whether the data path is intact is the precondition: downlinks (Modbus RTU/RS485, Zigbee, LoRa) and uplinks (Modbus TCP/MQTT; IEC 61850 optional at gateway level) are defined by the protocol matrix, and lightning-protection modules aggregate upstream through the FG lightning-protection intelligent gateway.
Step four, write-back. Site results and re-test data return to the platform, reusing the application layer's alarm management and mobile inspection; FS state quantities such as strike count, leakage current, temperature and lifetime estimation are review evidence of whether recovery is real, while FL peak and energy add event metrics.
Step five, closure and review. Close the ticket only after re-testing confirms recovery, and organise event metrics, alarms and handling records into a timeline as evidence. The knowledge base sets no evidence format or retention period.
The point is not the flow itself but making "trigger → dispatch → handle → write back" a checkable data chain: every ticket maps to an alarm, a location and a review.
Let Grading and the Loop Calibrate Each Other
Once the loop runs, write-back data can calibrate grading in reverse: if many BJ1 alarms are cleared within minutes, the threshold may be too strict; if one class of YJ alarms is never handled, grading and ownership are misaligned.
On capability, a few verifiable supports stand out. The knowledge base reports alarm compression of 80%, root-cause accuracy of 85%+, scenario localization at L17-L18 and 100% cascading-risk coverage — all vendor self-reports. The harmonic fingerprint library matches 14 device fingerprints at cosine similarity >0.85 and can lock a pollution source within 2 hours, helping merge duplicate alarms into one root cause. The Tianyan S-02 residual-current trend drift (CUSUM) can warn 4-12 weeks ahead while leakage is still safe, moving work from emergency repair to planned maintenance. These point one way — triggering tickets by root cause and trend rather than a pile of alarms — but vendor self-reported figures must not be treated as deadlines or guarantees.
Boundaries: What This Article Does Not Claim
Second, the knowledge base gives no ticket grading rules, dispatch/escalation/timeout mechanisms, evidence formats or retention periods; this article invents none of those details.
Third, the quantitative figures in (alarm compression 80%, root-cause accuracy 85%+, MTTR reduced 60%, fault localization from days to 2 hours) are vendor self-reports, and are cited only as vendor capability claims.
Fourth, this article does not reuse the landing points of registered articles: the order in which to check data first after a strike, which station to check first after a thunderstorm across dispersed base stations, customer visibility and role layering, or lightning's knock-on effects on safe system operation.
Conclusion
Alarm grading and the work-order loop are judgement and execution. Grading uses verifiable rules to state severity and deadlines clearly: six alarm levels, the red lines, the D7 score and the four-dimension labels. The loop connects trigger, dispatch, handling, write-back and closure into a checkable data chain. Grading sets the loop's priorities, and write-back data calibrates grading — together they decide whether a platform merely reports and ignores, or always reports and always closes the loop.
