When something breaks in a telecom network, the network tells everyone. A single damaged link can set off alarms on dozens of devices, and each of those alarms can trigger more. Operations engineers then face a wall of alerts and have to work out which one matters.
AI can help sort that wall, but it learns from labeled examples, and good labels are harder to make than they sound. Network alarm classification and incident ticket classification are the work of marking which alarms belong together, which one is the cause, and how each incident was resolved. This post explains what that labeling involves and why it needs people who know how networks behave.
Network alarms are different from the free-text notes people write. They are structured, frequent, and generated automatically. Each one typically carries a time, the device that raised it, an alarm type, and a severity level set by the equipment.
That structure is useful, but it hides the real question. An alarm says that a device noticed a problem. It does not say why. The label has to supply the missing part: what the alarm means in the context of everything else that was happening.
A single fault can spread. If a cable is cut, equipment on both sides loses its connection and reports it. Devices further away notice that traffic has stopped flowing and raise their own alarms. Services that depended on the link report errors. A single cause can produce a flood of alerts in a matter of seconds.
Annotators have to separate the root cause from the symptoms. This is a skill that comes from understanding how failures travel through a network. A junior reviewer may label the loudest alarm as the cause, when the real cause is a quiet one that appeared first.
For this reason, alarm correlation labeling is one of the most valuable and difficult tasks in telecom operations data. It teaches a model to point to the one alarm engineers should look at first.
Raw alarms need to be grouped into incidents before they can be classified. Annotators decide which alarms belong to the same event.
Several choices need written rules:
Without rules, two annotators group the same alarms differently, and the model learns blurry boundaries. Overlapping incidents are especially tricky, because alarms from two causes can interleave and look like one big event.
To tell cause from symptom, annotators need to know how the network is connected. A map showing which device feeds which is essential, because the alarm that comes from the device closest to the fault is often the real source.
Labeling without topology is guesswork. A project should supply the network map along with the alarms, keep it up to date, and record which version applied at the time of each incident. Networks change, and a map from last year may mislead.
Equipment assigns its own severity to each alarm, such as minor, major, or critical. That rating reflects how bad the device thinks the problem is, not how many customers are affected.
A critical alarm on a spare link with no traffic may matter less than a minor alarm on a busy one. Useful labels capture real impact separately from the reported level: which services were affected, and how badly.
Not every alarm marks a real fault. Some devices flap, switching between up and down many times in a short period. Some alarms appear briefly and clear on their own. Others come from planned maintenance, when engineers intentionally take equipment offline.
Labels should capture these categories:
A model that cannot tell planned work from a real fault will raise needless alerts every time maintenance happens.
Networks combine equipment from many manufacturers, and each uses its own alarm names and codes. The same fault may appear under different names depending on the device.
Projects usually map these onto a common set of categories. Annotators need a reference table, and they should keep the original alarm code in the data along with the common label. Where no mapping exists, an "unmapped" label is better than forcing a poor fit.
Alarms often lead to incident tickets, and tickets record what engineers found and did. Linking the two gives the model a way to learn from outcomes.
Tickets are imperfect. Some are closed with little detail, some carry a cause that was later revised, and some cover several incidents. Annotators should record how confident they are in a ticket's stated cause, and flag tickets where the resolution does not match the alarm pattern.
People who have worked in network operations read alarm streams differently. They know how failures spread, recognize the patterns of flapping and planned work, and understand which devices sit upstream of others. They can look at a flood of alerts and find the one that started it.
They also write the rules that keep a large team consistent: grouping windows, cause-and-symptom definitions, and the handling of unclear incidents. This matches Globik's approach of using verified domain experts for work that depends on judgment. For telecom operations AI training data, that experience is what makes the labels worth learning from.
Before an alarm labeling project starts, a team can settle five things:
Alarm and ticket AI works when labels group alarms into incidents, separate cause from symptom, use network topology, and distinguish real faults from planned work. If you are building AI for network operations, you can discuss your network data with our team. Strong network alarm classification starts with people who know how networks fail.
It is the labeling of network alarms so AI can group them into incidents and identify the root cause.
Failures spread through connected equipment, and each affected device raises its own alert.
Annotators need to know which devices feed others to tell the cause from its symptoms.
Equipment ratings show how bad a device thinks a problem is, not how many customers are affected.
They know how faults spread and can find the alarm that started an incident.
