Real-time alarm ingestion
High-volume alarm streams normalised across vendors into a common event schema.
AI intelligence system
NetCause
Not alarm detection. Failure hypothesis reduction.
A correlation engine that turns an alarm storm into a short ranked list of probable root causes by reasoning over network topology and fault propagation rather than alarm counts.
- Sector
- Telecommunications & Network Operations
- Year
- 2025
- Duration
- 8 months
- Team
- 6 people
- Platforms
- Web NOC console · API
- Status
- In production
11,000 to 3
Alarms to hypotheses
Worked example from a core failure
Sub-minute
Time to first hypothesis
From storm onset
Explained
Scoring basis
Coverage of the observed alarm set
Live
Topology model
Reconciled continuously against discovery
01 — The problem
A single core failure produced eleven thousand alarms in nine minutes. The NOC's tooling ranked by severity and volume, which meant the loudest downstream symptom sat at the top and the actual cause was buried on page forty.
Engineers had learned to ignore the tool and reason from topology diagrams by hand. That works when one senior engineer is on shift and fails completely at three in the morning.
02 — What we did
We modelled the network as a dependency graph and treated an alarm storm as evidence to be explained. The question stops being which alarm matters most and becomes which single failure best accounts for everything observed.
Fault propagation rules encode how a failure at one node manifests downstream. Candidate causes are scored on how much of the observed alarm set they explain and how little they leave unexplained, which collapses eleven thousand alarms into three hypotheses.
The loudest alarm is almost never the broken thing.
Interface
What it looks like in use
Two of the screens that carry the most weight in daily use, rebuilt here from the production design system.
Incident 9042 · storm11,204 ALARMS
CR-EDGE-14 · card failureEXPLAINS 94%
Fibre span 88 · degradationEXPLAINS 61%
Power feed B · brownoutEXPLAINS 22%
Unexplained alarms681
First hypothesis at 47s
Eleven thousand alarms, three hypothesesCandidates are ranked by how much of the observed alarm set each explains, and what each leaves unaccounted for.
Service impactP1
Enterprise voice · region 44,102 SUBS
Mobile backhaul · 12 sitesDEGRADED
Residential broadbandUNAFFECTED
3HYPOTHESES
47sTO FIRST
Impact in service termsEscalation is driven by the service map rather than by alarm volume, so the loudest symptom stops setting priority.
Capabilities
What the system does
Grouped by the job each set of capabilities exists to do, rather than by which team built it.
Ingestion and modelling
01 · Knowing the networkTopology modelling
A live dependency graph built from discovery, inventory and routing state rather than a static diagram.
Drift reconciliation
Continuous comparison between documented and observed topology, because the diagram is always slightly wrong.
Service mapping
Customer-facing services mapped onto infrastructure so impact is expressed in service terms.
Correlation and ranking
02 · The reasoning coreAlarm correlation
Alarms grouped into incidents by topological and temporal relationship instead of by text similarity.
Fault propagation modelling
Encoded rules for how a failure at a node manifests at its dependents, used to predict expected symptom sets.
Root-cause ranking
Hypotheses scored on explanatory coverage: how much of the observed set each accounts for, and what it leaves over.
Confidence and gaps
Unexplained alarms are surfaced explicitly rather than quietly dropped from the story.
Operations surface
03 · What the NOC seesAutomated incident summaries
A written incident narrative with affected services, probable cause and supporting alarms.
Impact assessment
Customer and service impact computed from the service map, not estimated from alarm counts.
Timeline reconstruction
The propagation sequence rendered in order so an engineer can verify the reasoning.
Post-incident export
A complete record suitable for review and regulatory reporting.
Architecture
How it is put together
Layer by layer, with the reason each one exists — because the reason is usually the interesting part.
01Alarm ingestion
Streaming pipeline handling burst loads an order of magnitude above steady state without dropping events.
- Kafka
- Flink
- Vendor adapters
02Topology store
Graph database holding the live dependency model with temporal versioning so past incidents are reasoned about against the topology of the time.
- Neo4j
- Temporal versioning
03Propagation engine
Rule and model hybrid that predicts expected symptom sets for candidate failures and compares them against observation.
- Rule engine
- Bayesian scoring
04Narrative layer
Structured incident facts rendered into readable summaries with every claim linked to its supporting alarms.
- Template + LLM
- Fact grounding
05Console
NOC workspace with live incident view, topology overlay and timeline reconstruction.
- React
- Cytoscape
- WebSocket
Technology
Streaming
- Kafka
- Apache Flink
- Protobuf
Graph
- Neo4j
- Cypher
- Temporal versioning
Backend
- Python
- FastAPI
- PostgreSQL
- Redis
Frontend
- React
- TypeScript
- Cytoscape.js
- WebSocket
Outcome
What changed
Measured against how the operation ran before, not against a benchmark chosen after the fact.
-
Storms became incidents. Engineers work a short hypothesis list instead of paging through alarm tables.
-
Junior engineers reason like senior ones. The topology knowledge that lived in a few heads is encoded in the model.
-
Unexplained signal is visible. The system says what it cannot account for instead of presenting a tidy incomplete story.
-
Impact is stated in service terms. Escalation decisions stopped depending on alarm volume.
How it ran
-
Months 1-2
Topology reconstruction
Built the dependency graph from discovery and measured how far documentation had drifted from reality.
-
Months 3-4
Ingestion at burst scale
Pipeline sized for storm conditions rather than steady state.
-
Months 5-6
Propagation and ranking
Encoded propagation rules and validated hypothesis ranking against a year of resolved incidents.
-
Months 7-8
NOC console
Live incident view, narrative summaries and post-incident export.
Related work
From the same practice
Manufacturing & Production Quality
LineTrace
From defect detection to defect causality.
A multimodal system that correlates line video, machine telemetry, batch records and operator actions to explain why a defect happened, not merely that it did..
2025 · 10 months
Oil & Gas · Asset Integrity
PipeIntegrity
From a single inspection to longitudinal asset integrity.
A vision system that detects and localises pipeline deterioration, then tracks each defect across inspection cycles so maintenance is prioritised by progression rather than by appearance..
2024 · 9 months
Pharmaceutical & Regulated Manufacturing
BatchResolve
From deviation to evidence, with the audit trail intact.
A deviation investigation assistant that assembles batch records, equipment telemetry, inspection imagery, SOPs and historical deviations into an evidence-linked case file a quality unit can defend to a regulator..
2025 · 11 months
Something similar?
Running into the same problem NetCause solved?
Tell us what you run. We will reply within two business days with what we would build for your situation — and, just as usefully, what we would leave out.