The problem taxonomy is the classification tree that organizes every analysis algorithm, metric, alarm, and AI insight in Kudzu Canopy NOC. Instead of presenting a flat list of KPIs, the platform groups them under operational concerns so you can navigate from a broad area of interest down to specific evidence.

Why it matters#

A modern LoRaWAN network can produce dozens of metrics across service quality, RF coverage, capacity, infrastructure health, and operational integrity. Without structure, those metrics become overwhelming. The problem taxonomy gives you a consistent navigation path: start with the operational concern you care about, drill into the specific sub-problem, inspect the alarms and KPIs, and then view the affected devices, gateways, or map cells. Every view that shows metrics — the Metrics Dashboard, Alarms, AI Insights, and Reports — uses this same tree.

How it works#

The hierarchy#

The taxonomy is a tree with five levels:

Category
 └── Sub-problem
      └── Analysis algorithm
           └── Metric (KPI)
                └── Alarm

Each level narrows the scope:

1. Category — a root-level operational concern (see the five categories below).
2. Sub-problem — a specific issue area within that category.
3. Analysis algorithm — the scheduled program that reads network data and computes results for the sub-problem.
4. Metric — a single computed value emitted by an algorithm, such as a count, ratio, or score with entity references.
5. Alarm — a threshold rule attached to a metric that fires when the value crosses a configured boundary.

The five root categories#

Tree diagram#

The full category and sub-problem tree currently shipped with the platform:

Problem Taxonomy
├── Quality of Service
│   ├── Uplink Delivery Failure
│   ├── Downlink Delivery Failure
│   ├── Join & Access Failure
│   ├── Device Inactivity & Traffic Drop-off
│   ├── Device Behavior Instability
│   └── Customer Specific
├── Coverage & RF Quality
│   ├── Weak Signal / Coverage Degradation
│   ├── Coverage Gaps
│   ├── Frame Integrity Issues
│   └── External RF Contention & Attribution
├── Capacity & Performance
│   ├── Airtime Imbalance
│   ├── Gateway Saturation
│   └── Capacity Forecasting
├── Infrastructure & Connectivity
│   ├── Gateway Availability
│   └── Low Network Redundancy
└── Compliance, Security & Operational Integrity
    ├── Duty Cycle Violation
    ├── ADR & Protocol Compliance
    └── Identity & Provisioning Issues

Each sub-problem is implemented by one or more analysis algorithms that compute metrics, and those metrics carry the alarms you see in the Alarms view.

Sub-problem reference#

The table below summarizes the operational concern that each sub-problem addresses.

How the taxonomy connects features#

The taxonomy is not just an organizational convenience — it is the structural backbone that ties the Metrics Dashboard, Alarms view, AI Insights, and Reports together:

• Metrics Dashboard groups KPI cards under their taxonomy categories and sub-problems. You can expand a category to see the algorithms and metrics beneath it.
• Alarms groups active and historical alarms by the same tree, so you can see all firing alarms for a particular operational concern at once.
• AI Insights reference taxonomy nodes when identifying problems and proposing solutions, making it easy to trace a recommendation back to the underlying metrics.
• Reports organize their findings along taxonomy lines, giving readers a structured summary of each operational area.

Where you see this#

• Action Center — AI-generated suggestions reference taxonomy categories.
• Investigation Views — diagnostic dashboards organized by analysis domain.

Related pages#

• KPIs and Analysis — how the metrics within the taxonomy are computed.
• Alarms and Criticality — how metrics become operational alarms.
• Glossary — definitions for taxonomy-related terms.