NetSense AI
A network-operations prototype connecting telemetry anomalies to the evidence and incident context engineers need to investigate them.
Investigating a network anomaly means connecting pieces that live in different places.
Network-operations exposure during my Tata Teleservices internship helped shape this problem framing; NetSense itself is an independently built prototype using synthetic/demo telemetry, not Tata production data.
The product hypothesis
The idea is that surfacing anomaly scoring directly beside link context could reduce manual dashboard correlation.
Note: This is a product hypothesis, not a measured productivity result.
How detection works
The current detection system is deterministic and rule-based — not a trained model. Telemetry (latency, packet loss, jitter, bandwidth) sampled every 30 minutes across 6 links, with a 48-hour trailing window and a 12-hour forecast/context horizon, on synthetic/demo data.
| Telemetry Metric | Weight | Sampling Window |
|---|---|---|
| Latency | 40% | 30m intervals |
| Packet Loss | 30% | 30m intervals |
| Jitter | 15% | 30m intervals |
| Bandwidth Utilization | 15% | 30m intervals |
Weighted score vs. threshold 0.22 — below is healthy/no strong live signal, at/above is attention/anomalous. A deterministic cutoff, not a learned boundary.
Computed vs. authored
- Latency
- Packet loss
- Jitter
- Bandwidth
- Anomaly score
- Health state
- Prediction label
- Confidence
- Fault label
- Incident severity
- Engineer assignment
No telemetry-to-fault classifier, no dynamic assignment algorithm, no autonomous incident creation or remediation today.
The failure
“A healthy score sat next to an active high-severity incident.”
Incident INC-395, Bengaluru–Hyderabad Core corridor: live anomaly score ≈ 0.16 (healthy/no strong live signal) while the linked incident record showed active, investigating, high severity, fault label “BGP Peer Dampening.”
The score wasn’t simply wrong — 0.16 was genuinely below threshold at that instant. A single point-in-time score can look healthy while the corridor is oscillating or intermittently unstable over time — a temporal blind spot, not a bad threshold. Kept visible rather than tuned away.
Evaluation
Six designed telemetry profiles — bifurcation, loss degradation, saturation, stable, recovering, oscillation — a designed evaluation set, not a production benchmark.
For scenarios where the expected t=0 state was resolvable (of the six profiles tested). This is rule-based detection agreement, not ML accuracy.
The oscillation profile scored ≈ 0.16 and classified healthy despite intermittent instability — the same failure pattern as INC-395.
Consistency audit: 10 consistent, 2 flagged, 1 N/A of 13 records (7 predictions, 6 incidents). Kept separate from detection-agreement.
Rolling-window, variance-aware temporal scoring
Rolling-window, variance-aware temporal scoring — weighing recent behavior, variance and oscillation rather than a single snapshot. Future work; not yet implemented.
Real-user testing
Real-world testing was conducted with the prototype in a confidential network-operations setting, using company data. The underlying data, organization-specific findings, and detailed user feedback cannot be disclosed under an NDA.
Confidential real-world validation
Real prototype use in a live network-operations context provided feedback that informed the product framing. Detailed evidence from that testing is not publicly disclosed.
Public evaluation
The public case study instead uses synthetic/demo telemetry, so the detection behavior, evaluation scenarios, and limitations here can be inspected and reproduced by anyone reading this page.
Value & limitations
Potential value — reduced investigation friction, less context switching, better decision context — is a hypothesis, not a measured MTTR or productivity result.