Purpose
This document describes the Orion Edge AI-RAN Intelligence Platform — what it does, how it works, what it depends on, and what the critical path to delivery looks like. It follows the Nexus Use Case Template UCT-3.1 structure.
Field Classification
| Marker | Meaning |
|---|---|
| [M] | MANDATORY — requires confirmed information from client or domain research. Cannot be invented. |
| [D] | DERIVED — UV proposes based on experience. Client confirms or corrects. |
Section 01 — Overview [M]
| Field | Value |
|---|---|
| Use Case ID | UC-OE |
| Client Reference [M] | CodeZero / Orion Edge Internal |
| System Name [M] | Orion Edge |
| Domain [M] | Telecommunications — AI-RAN Intelligence |
| One-Line Description [M] | Multi-sprint AI-driven RAN intelligence platform spanning telemetry baseline through agentic closed-loop orchestration and path intelligence. |
| Status [M] | Production (Sprint 1–8 complete) |
| Target Delivery [M] | Phased delivery — Sprint 1 through Sprint 8 delivered Q4 2025 – Q1 2026 |
Summary [M]
Orion Edge is an AI-driven RAN intelligence platform built for edge deployment on NVIDIA Nano ZGX GB10-class hardware. It evolves across eight sprints from foundational QoS telemetry baseline through traffic classification, congestion forecasting, policy recommendation, security-resilience fusion, agentic LLM orchestration, SD-RAN intent synthesis, and path intelligence.
The platform ingests real-world 5G telemetry datasets (OTA srsRAN, TRACTOR, TelecomTS), applies ML models for inference, and produces deterministic policy recommendations governed by audit-traced verification loops. Every recommendation passes through deterministic governance before acceptance — the LLM proposes, Orion verifies.
The system is designed as a cohesive, modular platform where each sprint adds capability without rewriting prior work, culminating in an edge-deployable AI-RAN PoC with full observability, security gating, and agentic orchestration.
Section 02 — Actors [M]
| Role [M] | Description [M] | Access Level [D] | Frequency [D] |
|---|---|---|---|
| RAN Operator | Monitors network health, reviews policy recommendations, acts on alerts | Full dashboard + API access | Continuous / real-time |
| Security Analyst | Reviews threat-adjusted risk scores, MITRE/FiGHT mappings, security gate decisions | Security dashboard + /security/evaluate endpoint |
On-alert + periodic review |
| Network Planner | Uses what-if simulation and forecasting to plan capacity and resource allocation | Policy + forecasting dashboards | Weekly / on-demand |
| Platform Engineer | Deploys, maintains, and monitors the Orion Edge stack (API, observability, LLM gateway) | Full system access including Grafana, Prometheus, Docker | Daily |
| AI/ML Engineer | Trains and evaluates models, reviews model governance artifacts, extends sprint capabilities | Source code + model artifacts + training pipelines | Per-sprint / as needed |
Section 03 — User Stories [M/D]
Actor: RAN Operator
- P1 [M]: As a RAN Operator, I want to view real-time QoS inference results, so that I can identify RF degradation early.
- P1 [M]: As a RAN Operator, I want deterministic policy recommendations with audit traces, so that I can trust and act on system suggestions.
- P1 [M]: As a RAN Operator, I want security-gated recommendations, so that threat context is factored before any action is taken.
- P2 [D]: As a RAN Operator, I want to run what-if simulations, so that I can evaluate policy impact before commitment.
Actor: Security Analyst
- P1 [M]: As a Security Analyst, I want threat-adjusted risk scores with MITRE/FiGHT mapping, so that I can prioritize response actions.
- P2 [D]: As a Security Analyst, I want to see security gate pass/fail decisions in the audit trail, so that I can review gating logic.
Actor: Network Planner
- P1 [M]: As a Network Planner, I want congestion forecasting with risk scores, so that I can plan capacity proactively.
- P2 [D]: As a Network Planner, I want path-health attribution (RAN/transport/upstream), so that I can isolate degradation sources.
Actor: Platform Engineer
- P1 [M]: As a Platform Engineer, I want Prometheus metrics and Grafana dashboards, so that I can monitor platform health.
- P1 [M]: As a Platform Engineer, I want the system deployable on Nano ZGX GB10 edge hardware, so that it runs at the edge without cloud dependency.
- P2 [D]: As a Platform Engineer, I want local LLM gateway fallback, so that agentic capabilities work offline.
Actor: AI/ML Engineer
- P1 [M]: As an AI/ML Engineer, I want model metadata and governance artifacts, so that I can audit model lineage and performance.
- P2 [D]: As an AI/ML Engineer, I want Makefile-driven training and simulation pipelines, so that I can reproduce results deterministically.
Section 04 — System Flows [M/D]
Flow: QoS Inference [M]
Trigger [M]: Client sends RF telemetry payload to /infer/qos.
| # | Step [M] | Actor [M] | Input [M] | Output [D] | Decision [M] |
|---|---|---|---|---|---|
| 1 | Submit telemetry | RAN Operator / System | rssi, sinr, rsrp, distance_m |
— | — |
| 2 | Validate contract | Inference Service | Pydantic request model | Validation pass/fail | Reject if invalid |
| 3 | Run QoS model | Inference Service | Feature vector | Throughput prediction + risk class | — |
| 4 | Return response | Inference Service | — | JSON with prediction + metadata | — |
Result [M]: QoS prediction returned with risk classification (Low/Medium/High).
Exceptions [D]: Invalid payload → 422 with validation errors. Model load failure → 500 with health check degradation.
SLA [D]: < 200ms p95 latency for single inference.
Volume [M]: Continuous — up to hundreds of requests/minute per cell site.
Flow: Policy Recommendation [M]
Trigger [M]: Client sends context payload to /policy/recommend.
| # | Step [M] | Actor [M] | Input [M] | Output [D] | Decision [M] |
|---|---|---|---|---|---|
| 1 | Submit context | RAN Operator / System | QoS metrics + forecast risk + security context | — | — |
| 2 | Deterministic policy engine | Policy Service | Feature context | Candidate recommendation | — |
| 3 | Security gate evaluation | Security Service | Threat context + MITRE mapping | Gate pass/fail | Block if threat level exceeds threshold |
| 4 | Return recommendation | Policy Service | — | Action + rationale + audit trace | — |
Result [M]: Deterministic policy recommendation with full audit trace.
Exceptions [D]: Security gate block → recommendation rejected with reason. Missing forecast data → degraded recommendation with flag.
SLA [D]: < 500ms for deterministic path; < 5s if LLM agent loop is invoked.
Volume [M]: Event-driven — triggered by threshold crossings or operator request.
Flow: Agentic Recommendation (Sprint 6) [M]
Trigger [M]: Client sends context to /agent/recommend.
| # | Step [M] | Actor [M] | Input [M] | Output [D] | Decision [M] |
|---|---|---|---|---|---|
| 1 | Submit context | RAN Operator / System | Network state + policy context | — | — |
| 2 | LLM proposal generation | Agent Service | Context prompt | LLM-generated proposal | — |
| 3 | Deterministic Orion verification | Verification Loop | LLM proposal | Verified/rejected proposal | Reject if governance rules violated |
| 4 | Return verified recommendation | Agent Service | — | Verified action + LLM rationale + audit trace | — |
Result [M]: LLM-proposed, deterministically-verified recommendation with full provenance.
Exceptions [D]: LLM unreachable → fallback to offline/deterministic mode. Verification loop rejection → logged with reason, no action emitted.
SLA [D]: < 10s end-to-end with LLM; < 500ms in offline fallback.
Volume [M]: On-demand — triggered by complex scenarios requiring reasoning.
Section 05 — Data Model [M/D]
Entities
| Entity [M] | Description [M] | Key Fields [M] | States [D] | Relationships [D] |
|---|---|---|---|---|
| RF Telemetry Record | Single observation of radio conditions | rssi, sinr, rsrp, distance_m, timestamp |
Raw → Processed → Inferred | Input to QoS Model |
| Traffic Record | Labeled network traffic observation | source_file, traffic_class, feature vector |
Raw → Classified | Input to Traffic Model |
| Forecast Record | Time-series congestion observation | timestamp, kpi_value, risk_score |
Raw → Forecast → Policy-input | Feeds Policy Engine |
| Policy Recommendation | Deterministic action suggestion | recommendation_id, action, rationale, risk_score, gate_status |
Proposed → Gated → Accepted/Rejected | Linked to Audit Trace |
| Security Evaluation | Threat-adjusted risk assessment | threat_id, mitre_mapping, risk_adjustment, gate_decision |
Evaluated → Gated | Gates Policy Recommendation |
| Agent Proposal | LLM-generated action proposal | proposal_id, llm_source, verified, fallback_mode |
Proposed → Verified → Accepted/Rejected | Wraps Policy Recommendation |
| Audit Trace | Immutable record of every decision | trace_id, timestamp, source, decision, rationale |
Created (append-only) | Links all entities |
| Path Health Record | Synthetic path stability observation | path_id, attribution (ran_likely, transport_likely, upstream_likely, mixed_uncertain) |
Observed → Attributed | Input to root-cause analysis |
Business Rules [M/D]
| ID | Rule [M] | Trigger [D] | On Violation [D] |
|---|---|---|---|
| BR-01 | Every recommendation must pass deterministic governance before acceptance | Policy recommendation generated | Recommendation blocked, audit trace logged |
| BR-02 | Security gate must evaluate MITRE/FiGHT threat context before policy emission | Pre-recommendation | Recommendation held pending security clearance |
| BR-03 | LLM proposals must be verified by deterministic Orion loop — LLM never acts autonomously | Agent recommendation flow | Proposal rejected, fallback to deterministic mode |
| BR-04 | All decisions must produce an immutable audit trace | Any inference/recommendation/evaluation | System error — trace failure escalated |
| BR-05 | SD-RAN intents are concept-only — no live actuation | Intent synthesis | Intent tagged concept_only, no downstream execution |
| BR-06 | Model artifacts must include governance metadata (MAE, R², split strategy) | Model training | Model not promoted without metadata |
Section 06 — Screens [D]
| Screen [D] | Actor [M] | Purpose [D] | Key Elements [D] |
|---|---|---|---|
| Sprint 3 — Forecasting Dashboard | RAN Operator, Network Planner | Visualize congestion forecasts and risk scores | Time-series chart, risk score gauge, anomaly bands |
| Sprint 4 — Policy Dashboard | RAN Operator | Review and simulate policy recommendations | Recommendation cards, what-if simulator, KPI impact |
| Sprint 5 — Security Resilience | Security Analyst | Review threat-adjusted risk and MITRE mappings | Risk fusion panel, MITRE mapping table, gate status |
| Sprint 6 — Agent Dashboard | RAN Operator | Monitor agentic proposals and verification results | LLM proposal log, verification status, fallback indicator |
| Sprint 7 — SD-RAN Intent | Network Planner | Explore SD-RAN + SD-WAN + SASE intent synthesis | Intent mapping view, concept-only badge, intent graph |
| Sprint 8 — Path Intelligence | Network Planner | Root-cause attribution for path degradation | Path health chart, attribution breakdown, stability score |
All screens are Streamlit pages located in src/dashboard/pages/.
Section 07 — Integrations [M]
| System [M] | Direction [M] | Data [M] | Format [D] | Frequency [M] | Fallback [D] |
|---|---|---|---|---|---|
| Prometheus | Out | Platform + model metrics | /metrics endpoint (OpenMetrics) |
Continuous scrape (15s) | Metrics buffer; alert on scrape failure |
| Grafana | Out (via Prometheus) | Dashboard visualization | JSON dashboard definitions | Continuous | Static dashboard export |
| Local LLM Gateway (vLLM) | Both | LLM prompts + completions | OpenAI-compatible REST API | On-demand (agent flow) | Offline deterministic fallback |
| NVIDIA NIM (optional) | Both | LLM inference via hosted NIM endpoint | REST API | On-demand | Fallback to local LLM or offline mode |
| Streamlit Dashboard | In (reads API) | All inference + recommendation results | REST JSON | User-driven | Cached last-known state |
| OTA/TRACTOR/TelecomTS Datasets | In | Raw telemetry for training | CSV / trace files | One-time ingestion per sprint | Re-ingestion from source |
Section 08 — Infrastructure [D]
| Layer | Choice [D] | Reason [D] |
|---|---|---|
| Hosting | NVIDIA Nano ZGX GB10 (edge) | Edge-first design — no cloud dependency for core inference |
| Runtime | Python 3.10+ (3.12 venv), Flask API | Lightweight, portable, ARM64-compatible |
| Database | File-based (CSV, JSONL, joblib artifacts) | No RDBMS needed — telemetry is processed in-pipeline, traces are append-only JSONL |
| Frontend | Streamlit + Plotly | Rapid operator dashboard with interactive visualization |
| Observability | Prometheus + Grafana (Docker Compose) | Industry-standard metrics stack, isolated from app runtime |
| LLM Serving | vLLM (local) or NVIDIA NIM (remote) | OpenAI-compatible API; local-first with optional cloud scale-out |
| Container Runtime | Docker + Docker Compose | Observability stack and LLM gateway isolation |
Constraints [M]
- Edge deployment: Must run on ARM64/aarch64 Nano ZGX GB10-class hardware.
- No cloud dependency for core inference: All QoS/traffic/forecast/policy inference must run locally.
- Deterministic governance: LLM never acts autonomously — all proposals verified deterministically.
- Concept-only actuation: SD-RAN intents and path intelligence are concept-phase — no live RAN actuation.
Environments [D]
| Environment | Purpose |
|---|---|
| Development | Local edge device — build, train, test, iterate |
| Demo / UAT | Same device — simulation replays and operator walkthrough |
| Production (edge) | Deployed on Nano ZGX GB10 — continuous inference and monitoring |
Section 09 — Critical Path [D]
| # | Item [D] | Depends On | Duration [D] | Blocker Risk [D] |
|---|---|---|---|---|
| 1 | Sprint 1: QoS telemetry baseline + ingestion pipeline | — | 2 weeks | Low — dataset publicly available |
| 2 | Sprint 2: Traffic classification (TRACTOR dataset) | #1 (pipeline foundation) | 2 weeks | Low — dataset available, pipeline reusable |
| 3 | Sprint 3: Forecasting + observability stack | #2 (feature pipeline maturity) | 2 weeks | Low — TelecomTS available |
| 4 | Sprint 4: Policy recommendation + what-if simulation | #3 (forecast risk scores feed policy) | 2 weeks | Low — deterministic logic |
| 5 | Sprint 5: Security fusion + MITRE gating | #4 (policy engine must exist to gate) | 2 weeks | Low — threat mapping is derived |
| 6 | Sprint 6: Agentic LLM orchestration + verification loop | #5 (full pipeline feeds agent context) | 3 weeks | Medium — LLM serving dependency |
| 7 | Sprint 7: SD-RAN intent synthesis | #6 (agent framework reuse) | 2 weeks | Low — concept-only |
| 8 | Sprint 8: Path intelligence | #7 (platform maturity) | 2 weeks | Low — synthetic telemetry |
Parallel Work (off critical path) [D]
| Item | Can Start After | Duration |
|---|---|---|
| Grafana dashboard definitions | Sprint 3 | Ongoing |
| Streamlit page development | Sprint 3 | Per-sprint incremental |
| Local LLM gateway setup | Sprint 5 | 1 week |
| Documentation and README | Sprint 1 | Ongoing |
Milestones [D]
| Milestone | Reached When | Target Date |
|---|---|---|
| M1: Core inference operational | QoS + Traffic + Forecast endpoints live with real data | Sprint 3 completion |
| M2: Policy + Security pipeline | Deterministic recommendation with security gating | Sprint 5 completion |
| M3: Agentic loop verified | LLM proposal + deterministic verification end-to-end | Sprint 6 completion |
| M4: Full platform complete | All 8 sprints delivered, all smoke tests passing | Sprint 8 completion ✅ |
Section 10 — What Is Needed [M]
| # | Item [M] | From [M] | Blocking [M] | Status [M] |
|---|---|---|---|---|
| 1 | OTA_dataset_5G_srsRAN dataset | CCI NextG Testbed (GitHub) | Yes — Sprint 1 | ✅ Received |
| 2 | TRACTOR 5G traffic dataset | GENESYS Lab | Yes — Sprint 2 | ✅ Received |
| 3 | TelecomTS observability dataset | Academic source | Yes — Sprint 3 | ✅ Received |
| 4 | Nano ZGX GB10 hardware access | CodeZero lab | Yes — edge deployment | ✅ Received |
| 5 | vLLM / LLM serving runtime | Open-source (vLLM) | Yes — Sprint 6 agent flow | ✅ Received |
| 6 | NVIDIA NIM endpoint (optional) | NVIDIA | No — fallback exists | ⏳ Optional |
Section 11 — Acceptance Criteria [M/D]
Definition of Done [D]
| Criterion [D] | Verified By [D] |
|---|---|
| All P1 stories implemented across 8 sprints | Sprint smoke tests (make smoke-sprint*) |
| Business rules enforced (BR-01 through BR-06) | Contract tests + audit trace verification |
| All inference endpoints operational | pytest test suite (30+ tests) |
| Deterministic simulation replays pass | make simulate-sprint* |
| Observability stack operational | Prometheus scrape + Grafana dashboard load |
| Security gate logic verified | test_sprint5_* test suite |
| Agent fallback modes work (offline, local_llm) | test_agent_offline_fallback.py, test_agent_recommend_* |
| Model governance metadata present | Metadata JSON in all artifacts/ directories |
Success Metrics (30/60/90 days) [M]
| Metric [M] | Target [M] | Measured By [D] |
|---|---|---|
| Inference endpoint availability | > 99% uptime on edge device | Prometheus up metric |
| QoS model MAE | ≤ 15.0 Mbps | Model metadata artifact |
| Forecast Event AUC | ≥ 0.90 | Model metadata artifact |
| Policy recommendation determinism | 100% reproducible given same input | Simulation replay comparison |
| Security gate enforcement | 0 unverified recommendations emitted | Audit trace analysis |
| Agent verification loop | 100% LLM proposals pass deterministic check before emission | Audit trace analysis |
| Test suite pass rate | 100% on all contract + smoke tests | pytest CI output |
Section 12 — Risks [D]
| # | Risk [D] | Likelihood [D] | Impact [D] | Mitigation [D] |
|---|---|---|---|---|
| R1 | QoS model limited by RF-only features (low R²) | Confirmed | Medium — baseline only | Transparent governance; stronger signal in Sprint 2+ datasets |
| R2 | LLM serving resource constraints on edge hardware | Medium | High — agent flow blocked | Offline deterministic fallback; local LLM gateway option |
| R3 | Dataset drift between synthetic and production telemetry | Medium | Medium — model degradation | Concept-phase acknowledgment; retraining pipeline available |
| R4 | SD-RAN / path intelligence remain concept-only | Low | Low — by design | Explicit concept_only tagging; no live actuation |
| R5 | Large raw datasets not version-controlled | Medium | Medium — reproducibility gap | Re-ingestion scripts; Makefile pipeline targets |
Open Questions [M]
| # | Question [M] | Impacts [D] | Resolution [M] |
|---|---|---|---|
| Q1 | When will live RAN actuation be in scope? | SD-RAN intent synthesis (Sprint 7) moves from concept to production | Pending — roadmap decision |
| Q2 | Will NIM-hosted endpoints replace local LLM gateway? | Sprint 6 agent architecture and deployment model | Pending — NVIDIA NIM availability and cost |
| Q3 | What production telemetry sources will replace academic datasets? | All model retraining and validation | Pending — operator partnership |
Section 13 — Cooperator Brief [D]
| Field | Value |
|---|---|
| Scope [D] | Multi-sprint AI-RAN intelligence platform: 8 inference endpoints, operator dashboard, observability stack, agentic orchestration layer, all edge-deployable |
| Stack [D] | Python 3.12, Flask, scikit-learn, Pandas/NumPy, Streamlit, Plotly, Prometheus, Grafana, Docker Compose, vLLM (optional) |
| Timeline [D] | 8 sprints delivered — all complete as of March 2026 |
| Dependencies [D] | Three public 5G datasets (OTA, TRACTOR, TelecomTS); Nano ZGX GB10 hardware; Python 3.10+ environment |
| Interfaces [D] | 8 REST endpoints (Flask), 1 metrics endpoint (Prometheus), 6 Streamlit dashboard pages, Docker Compose observability stack |
| Quality Bar [D] | 30+ pytest tests covering contracts, determinism, metrics, security gating, and agent fallback; Makefile-driven CI; model governance metadata for all artifacts |
| Handover [D] | Complete source code (src/), model artifacts (.joblib + metadata JSON), training/simulation scripts, Streamlit dashboard, Grafana dashboards, Docker Compose profiles, comprehensive README |
Section 14 — Proposed Unified Architecture (Phase 2)
> Status: Proposed — under review. This section captures the target architecture for the next phase of Orion Edge deployment, integrating Atlas, NeXus, Chameleon, and deltaPrism into a unified sovereign stack.
Layer 1 — Hardware + Infrastructure
Target Deployment: HP Z4R
| Spec | Value |
|---|---|
| RAM | 256GB DDR5 ECC |
| CPU | 24C / 48T Intel |
| GPU | NVIDIA RTX A6000 |
| Storage | Local NVMe scratch |
| Cooling | Immersion cooled in Oleon Qloe dielectric fluid |
| Enclosure | GRC Micro tank |
Edge Compute Characteristics:
- High sustained GPU utilisation
- No thermal throttling
- Sovereign local inference
- High-throughput telemetry processing
- Edge-native low-latency AI operations
Layer 2 — Orion Edge Runtime
Orion remains the core AI-RAN and observability intelligence engine.
AI-RAN Intelligence
| Capability | Description |
|---|---|
| QoS inference | Real-time quality-of-service scoring |
| Throughput prediction | Capacity headroom forecasting |
| Traffic state classification | Multi-class radio state identification |
| Forecast modelling | Short-horizon RAN congestion forecasting |
| Congestion anticipation | Proactive threshold-based alerting |
Observability Intelligence
| Capability | Description |
|---|---|
| ASN telemetry ingestion | Autonomous System Number path telemetry collection |
| BGP path analysis | Route stability and path attribution |
| RTT and latency analysis | Round-trip time baselines and anomaly detection |
| Path attribution | Root-cause correlation to specific BGP transitions |
| Transport fault modelling | End-to-end path failure characterisation |
| Radio-layer correlation | Correlating RAN events with transport-layer observations |
Deterministic Governance
| Control | Description |
|---|---|
| Policy simulation | Before/after policy impact modelling |
| Weighted scoring | Multi-factor recommendation confidence |
| Rollback logic | Revert path on negative outcome |
| Accept / reject / defer | Gated decision states for operator approval |
| Audit trace generation | Every decision logged with full input context |
Security Intelligence
| Capability | Description |
|---|---|
| Anomaly detection | Statistical and ML-based deviation detection |
| Threat-adjusted risk scoring | MITRE FiGHT-informed risk weighting |
| MITRE FiGHT mapping | Tactic and technique attribution for telecom threats |
| Resilience scoring | Network-wide resilience quantification |
| Security-aware gating | Security posture gates in recommendation pipeline |
Layer 3 — Atlas Sovereign Intelligence Layer
Atlas becomes the sovereign reasoning and orchestration layer overlaid on Orion.
3.1 Telecom Reasoning
Atlas provides causal reasoning over Orion's model outputs:
- "Why is latency increasing?"
- "Is this degradation RAN or transport related?"
- "Which ASN transition is likely causing instability?"
- "Why did congestion risk spike?"
- "What is the likely root cause of packet loss?"
3.2 Recommendation Generation
Atlas translates inference results into actionable operator recommendations:
- Path steering recommendations
- SD-WAN policy recommendations
- Capacity scaling proposals
- Security-aware mitigation recommendations
- Traffic engineering proposals
3.3 Deterministic Governance
All Atlas recommendations pass through Orion's existing governance philosophy:
| Control | Description |
|---|---|
| Deterministic rules | Hard rule checks before output |
| Threshold checks | Confidence and value range gates |
| Explainability scoring | Attribution required before output |
| Audit logging | Every recommendation logged with inputs |
| Confidence gates | Low-confidence outputs flagged, not suppressed |
| Orion verification | Atlas proposals verified by Orion deterministic engine |
Atlas must never operate as uncontrolled autonomous AI.
3.4 Executive Narrative Generation
Atlas provides the executive storytelling layer:
- Network health summaries
- Path degradation reports
- Incident summaries
- Capacity planning narratives
- Security posture reports
- AI-RAN operational briefings
Layer 4 — CodeZero Sovereign Stack
NeXus (Orchestration + Anomaly Intelligence + Form Flow Layer)
> Formerly: Wormwood. Now unified under the NeXus brand.
NeXus becomes the orchestration backbone, the deterministic anomaly detection engine, and the operator form flow handler for Orion.
Orchestration Responsibilities:
- Workflow orchestration
- Agent chaining
- Event routing
- Deterministic rule execution
- Approval pipelines
- State management
- Form flows (operator confirmations, policy override requests, incident acknowledgements)
NeXus Rule Intelligence — Anomaly Detection Rule Domains:
| Domain | Example Rules |
|---|---|
| BGP / ASN | Route flapping, unexpected ASN transitions, prefix instability, path-length anomalies, suspicious upstream changes |
| RTT / Latency | p95 latency spikes, jitter instability, asymmetric latency patterns, RTT variance escalation |
| Packet Loss | Burst packet loss, sustained loss thresholds, loss correlated to ASN changes, transport instability detection |
| RAN | SINR degradation, RSRP instability, throughput collapse, congestion-risk escalation |
| Security | Threat-adjusted anomaly escalation, MITRE FiGHT correlation, suspicious routing patterns, resilience degradation |
Example NeXus Workflows:
*Workflow 1 — ASN Path Instability:*
ASN path instability detected -> NeXus rule triggered -> Orion performs attribution -> Atlas generates reasoning -> Operator receives governed recommendation
*Workflow 2 — Congestion Risk Spike:*
Congestion risk spike -> Forecast confidence > threshold -> NeXus approval chain -> Atlas proposal generated -> Orion deterministic verification
Chameleon / Grafana (Presentation Layer)
Interim Dashboard: Grafana
Grafana is used as the operator and executive dashboard layer until ChameleonBI is production-ready. This applies to all real-time telemetry views, RAN health monitoring, security posture dashboards, and latency analytics.
| Dashboard | Tool | Notes |
|---|---|---|
| AI-RAN health views | Grafana | Interim |
| ASN path visualisation | Grafana | Interim |
| Latency heatmaps | Grafana | Interim |
| Forecast dashboards | Grafana | Interim |
| Security posture dashboards | Grafana | Interim |
| Board-level reporting | Grafana | Interim |
| White-label / multi-tenant | Chameleon | Target state (pending ChameleonBI) |
Target State: Chameleon
Once ChameleonBI is available, Chameleon replaces Grafana as the white-label telecom presentation layer:
- Carrier-specific branding (e.g. Vodafone)
- MSP deployment
- Sovereign deployments
- Executive interface
- Multi-tenant operator dashboards
deltaPrism (Governance + Lineage Layer)
deltaPrism provides immutable audit and governance for every Orion decision and Atlas proposal.
Audit Trails — per event record:
- Telemetry inputs
- Triggered rules
- Model outputs
- Recommendation rationale
- Deterministic verification result
- Operator actions
Model Governance:
- Model versions and inference artefacts
- Dataset lineage
- Threshold evolution
- Simulation evidence
Security and Compliance:
- Telecom governance evidence
- Sovereign AI traceability
- Explainability requirements
- Operational auditability
Reference: https://codezerogroup.com/orion
Architecture Summary
| Layer | Component | Role |
|---|---|---|
| L1 — Hardware | HP Z4R + GRC Micro (Qloe immersion) | Sovereign edge compute, RTX A6000 |
| L2 — AI Runtime | Orion Edge Runtime | AI-RAN, observability, governance, security intelligence |
| L3 — Intelligence | Atlas | Telecom reasoning, recommendations, governance, narrative |
| L4 — Orchestration | NeXus (Wormwood) | Workflow, event routing, anomaly rule engine, form flows |
| L4 — UI | Grafana (interim) → Chameleon | Operator + executive dashboards (Grafana until ChameleonBI ready) |
| L4 — Audit | deltaPrism | Immutable audit, lineage, model governance, compliance |
Classification Summary
| Section | Classification | Notes |
|---|---|---|
| 01 Overview | Mandatory | Cannot proceed without this |
| 02 Actors | Mandatory | Must know who uses it |
| 03 User Stories | Mixed | P1 mandatory, rest derived |
| 04 System Flows | Mixed | Triggers/steps mandatory, error handling derived |
| 05 Data Model | Mixed | Entities mandatory, lifecycle/validation derived |
| 06 Screens | Derived | UV proposes entirely |
| 07 Integrations | Mandatory | Must know what connects to what |
| 08 Infrastructure | Derived | UV proposes unless hard constraints exist |
| 09 Critical Path | Derived | UV calculates from dependencies |
| 10 What Is Needed | Mandatory | Blocker list |
| 11 Acceptance | Mixed | Success metrics mandatory, criteria derived |
| 12 Risks | Derived | UV identifies from analysis |
| 13 Cooperator Brief | Derived | Internal UV document |
Version History
| Version | Date | Changes |
|---|---|---|
| UC-OE-1.1 | 2026-05-06 | Added Section 14 — Proposed Unified Architecture (Phase 2). HP Z4R + RTX A6000 target, Atlas telecom reasoning layer, NeXus anomaly rule engine (BGP/RTT/RAN/Security domains), Chameleon telecom UI, deltaPrism audit. Reference: codezerogroup.com/orion. |
| UC-OE-1.0 | 2026-05-03 | Initial Orion Edge use case document — all 13 sections completed from project repo analysis |
*Uued Viljapuuaiad OU — Nexus Platform Documentation*
*Use Case Document: Orion Edge · UC-OE-1.0 · 2026-05-03*