Enabling AI-assisted network investigation at scale
My role
Team
Analytics
Tools
Cursor, Claude, Nokia LLM
Problem
Appraoch
The initial ask was broad: make subscriber-level network experience visible across 4G and 5G networks.
I worked with product managers, RAN engineers, and architects to define what visibility needed to enable, what engineers needed to understand, which subscriber and network data could support those decisions.
I explored different investigation models. Some concepts started from the map, while others began with subscriber lists or network data. These explorations helped us compare how each starting point shaped the rest of the workflow.
We also learned that the underlying AI capabilities were still being developed. Rather than designing the first release around unavailable technology, we separated the roadmap into an observability foundation first, followed by AI-assisted investigation once the platform was ready.
Solution
We designed Subscriber Observability as a continuous investigation: define the scope, identify affected subscribers, locate the issue in time and place, review relevant sessions, and compare the supporting network signals.
I built working prototypes in Cursor and Claude, wired up with Mapbox and Recharts, so product and engineering could test the whole workflow with real interactions instead of clicking through mockups.
Subscribers became the starting point of the investigation.
For telecom operators, observability gets useful when teams can see which subscribers, accounts, or service areas need attention. The experience surfaces impact and severity first, then leads into the network evidence behind it.
Let engineers define the investigation scope
Engineers needed to cut through a large network fast: by time range, region, subscriber type, service, KPI category, or network layer. Global filters and session history narrow things down to the moments and conditions that actually matter.
Put the issue in network context
Service issues are spatial. The map connects subscriber impact with cells, sites, and surrounding coverage, so engineers can tell whether an issue is isolated, clustered, or part of a wider service area.

Connected signals into evidence
Poor experience rarely comes down to one metric. The product brings throughput, signal quality, reliability, mobility, packet behavior, and serving cells into one investigation path, so engineers can compare patterns and move toward a likely cause.
AI-assisted workflow
This is one of the prototypes I build during exploration in React using Cursor, translating the designs into reusable components and connected product flows. Components included responsive behaviour, functional states and real interactions.
Explorations
Map-first investigation
We explored starting from problematic areas on the map and correlating KPIs with subscriber experience. It provided strong network context, but made it harder to see who was affected, so the map became supporting evidence rather than the entry point.
Cell and KPI-first
We explored letting engineers select a cell, compare subscriber KPIs, and then drill into individual sessions. This still required them to manually find patterns and determine who was affected, so we moved toward a flow that surfaced subscriber impact earlier.

