Hey Claude create a BLOG_POST for the current state of the GLOBAL_SCYTHE!
● Create blog_post_scythe_globe_rf_drills.md +276
● Verify blog post creation (shell)
│ wc -l /home/spectrcyde/NerfEngine/blog_post_scythe_globe_rf_drills.md && echo “—” && head -5 /home/spectrcyde/NerfEngine/blog_post_scythe_globe_rf_drills.md
└ 7 lines…
● Created /home/spectrcyde/NerfEngine/blog_post_scythe_globe_rf_drills.md (275 lines).
Post covers:
- Passive Intelligence Architecture — explains all 7 background monitors, their poll intervals, endpoints, and why the INTENT monitor is the highest-value (it’s the only one with lat/lon,
painting the heat field automatically every 45s) - Phantom IX Deep Dive — the Φ_ix formula, detection pipeline, and the three real-world classes it catches (hyperscaler edge abstraction, CDN mesh overlays, botnet C2 hiding in legit infra)
- All 5 RF DRILL Scenarios — C2 Relay, Synchronized Burst, Phantom Emergence, EW Sweep, and RECON_EXFIL — each with the exact timing, strobe types, and the tactical pattern recognition lesson
it teaches - Live Sensor Integration paths for four hardware classes:
- SDR (RTL-SDR/HackRF/USRP) → sdr_stream.py → cluster_swarm_engine
- PCAP/network tap → pcap_ingest.py + live ws_ingest.py worker
- ATAK/TAK Server → tak_cot_relay.py → CoT → recon entities on globe
- KiwiSDR → KiwiSDRClient.py → remote multi-node RF correlation
- Full architecture diagram tying everything together The closing section makes the design philosophy explicit: drills and live data use identical rendering primitives so operators train on the exact visual language they’ll see from real sensors.
# SCYTHE Intelligence Globe: Passive Sensor Fusion, RF DRILLs, and the Path to Live Sensor Integration
**Date:** April 8, 2026
**Author:** SCYTHE Engineering
---
There is a meaningful difference between a system that *displays* data and one that *watches* for you.
The SCYTHE Intelligence Globe crossed that line. What started as a Cesium-based operator dashboard has evolved into a fully passive, self-updating intelligence surface — seven concurrent background monitors polling the live signal environment, a GPU-accelerated shader field rendering energy anomalies in real time, and a structured simulation framework (RF DRILLs) that lets operators train against realistic coordination scenarios before they encounter them in the wild.
This post covers how it works, what the RF DRILL scenarios teach, and — most importantly — what a full live sensor integration looks like when real hardware feeds the system.
---
## The Passive Intelligence Architecture
The original SCYTHE globe had a panel of active-click buttons. Every data pull was operator-initiated. That design has a fundamental flaw: intelligence that requires attention to arrive is intelligence that arrives too late.
The current architecture runs seven background monitors from page load, each staggered by two seconds to avoid burst-loading the API server:
| Monitor | Endpoint | Poll Interval | What It Watches |
|---------|----------|---------------|-----------------|
| PHANTOM | `/api/infrastructure/phantom-ix` | 45 s | Network convergence nodes with no physical IX anchor |
| IX HEAT | `/api/infrastructure/ix/heatmap` | 60 s | Internet Exchange point tier escalation and density trends |
| TIMING | `/api/signals/timing` | 45 s | Propagation patterns and intent scoring from signal timing |
| SLOPE | `/api/killchain/slope` | 60 s | Kill chain stage transitions and IMMINENT escalation |
| DRIFT | `/api/signals/fingerprint-drift` | 60 s | Behavioral fingerprint mutation (SNAPPING / OSCILLATING patterns) |
| INTENT | `/api/intent/field` | 45 s | Geo-located intent clusters with FORMING / COVERT classification |
| REPLAY | `/api/infrastructure/ix-conflict-replay` | 120 s | Historic IX conflict lane escalation |
Each monitor follows the same structural contract: a `Map` keyed by a stable identifier (cell key, IX name, cluster ID), delta-only alerting so quiet polls produce no noise, and a badge counter that displays `9+` rather than overflowing the button bar. The INTENT monitor is the highest-value of the seven — it is the only one with lat/lon data, so it silently calls `injectHeatPoint()` on every poll for any cluster scoring above `0.25`, continuously painting the globe's thermal field without a single operator interaction.
The result is an intelligence surface that is already informed by the time an operator looks at it.
---
## Phantom IX: Detecting Infrastructure That Should Not Exist
The most architecturally unusual concept in the system is Phantom IX detection.
A traditional Internet Exchange Point is a physical location: a data centre, a switching fabric, a peering agreement documented in PeeringDB. When traffic behaves as if it is transiting an IX — high edge convergence, strong temporal synchronisation, repeated multi-ASN convergence — but there is no cable alignment, no documented IX within geographic range, and no physical anchor, that behavioral signature is classified as a **Phantom IX node**.
The detection pipeline in `cluster_swarm_engine.py` runs a three-tier analysis per convergence cell:
```
Network observation stream
↓
ASN adjacency graph (bidirectional BFS, 32-ASN radius)
↓
15 submarine cable alignments + 12 documented IX points
↓
For each grid cell:
- inbound_edge_count > threshold
- geographic_variance (σ_geo) is low
- temporal_sync (τ) is high
- repeat_recurrence (R) across time windows
↓
Φ_ix = (C_in / σ_geo) * τ * R
↓
High Φ_ix → phantom_ix_snapshot() → globe.renderPhantomIX()
```
On the globe, confirmed Phantom IX nodes render as inward-pulsing volumetric ghost spheres (STROBE_TYPE.PHANTOM, type 9.0 in the shader). The `phantom_pull` value — how strongly the node is attracting flows — drives the attractor direction vector written into the GPU buffer. The visual language is intentional: an outward pulse is a transmission; an inward pulse is a collection point.
What generates Phantom IX behavior in the real world? Three classes:
1. **Hyperscaler edge abstractions** — Cloudflare Anycast, AWS Global Accelerator, and Google Cloud Anycast ingress all route traffic through internal fabric without exposing IX peering. From the outside, traffic appears to converge at a non-physical location.
2. **CDN mesh overlays** — Large CDN operators maintain hundreds of PoPs that do not appear in BGP routing tables as IX infrastructure. Convergence toward these points looks anomalous until you know the provider.
3. **Botnet command relay hiding in legitimate infrastructure** — C2 traffic routed through compromised cloud tenants can produce the same convergence signature. This is the adversarial case the detection is specifically tuned for.
The passive PHANTOM monitor means that if any of these patterns emerge in the data, the operator sees a badge increment and a new pulsing node on the globe — no action required.
---
## RF DRILLs: Training Against Coordination Scenarios
The RF DRILL system (accessible via the 🔴 RF DRILL button) is a structured simulation framework that renders five distinct radio coordination scenarios on the live globe using the same rendering primitives as real data. Each scenario runs a sequenced timeline using the `_at(ms, fn)` scheduler, firing recon entity creation, strobe injections, path arcs, phantom promotions, and kill chain graphs at calibrated intervals.
Pressing RF DRILL once selects a random scenario from the pool. Pressing it again triggers `_simStop()` and clears all simulation state. The globe immediately returns to its live passive-monitor state.
### Scenario 1 — C2 Relay Chain
A Command-and-Control relay scenario between two geographically distant cities. Three relay nodes are interpolated along the great-circle path between endpoints. The scenario exercises:
- UAV swarm deployment from the origin city
- Sequential STROBE_TYPE.C2 emissions along the relay chain
- Path arc rendering with `cable_alignment: { aligned: false }` (the arcs follow no physical submarine cable)
- Kill chain promotion to `FULL_SPECTRUM_COORDINATION` at scenario conclusion
The pedagogical point: legitimate traffic follows cables. A relay chain that crosses an ocean without aligning to any documented cable is a behavioral anomaly before a single packet is decoded.
### Scenario 2 — Synchronized Burst
Six emitters placed in a precise ring formation (~47 km radius) around a city fire simultaneously at T+4.2s. The scenario demonstrates:
- `STROBE_TYPE.CLUSTER` for the center aggregation node
- Six simultaneous `STROBE_TYPE.RF` directional cone emissions (each with a bearing set to point outward from center)
- A second anomaly pulse ring at T+8.5s with staggered 110ms per emitter
- Phantom IX promotion at the ring center: `confidence: 0.82, label: 'CONFIRMED_PHANTOM', type: 'SYNC_EMITTER_NODE'`
Synchronized emissions from a distributed ring have a very small natural-cause explanation space. The pattern maps cleanly to coordinated EW or network injection operations where multiple nodes act on a shared timing signal.
### Scenario 3 — Phantom Emergence (Open Ocean)
Three convergence nodes appear at positions offset from an open-ocean location (North Atlantic, Mid-Pacific, or Indian Ocean), each emitting `STROBE_TYPE.NETWORK` pulses. At T+5.2s, a `STROBE_TYPE.PHANTOM` strobe fires at the ocean coordinates and a Phantom IX entity is promoted with `type: 'HYPERSCALER_EDGE'`. A UAV recon swarm launches from the nearest coastal city at T+7.8s. Kill chain: `RF_NETWORK_COUPLING`.
This scenario models hyperscaler edge abstraction leakage — traffic appearing to converge at an ocean midpoint corresponds to a PoP routing through a submarine cable repeater site or a CDN edge node not visible in BGP.
### Scenario 4 — EW Sweep
A single electronic warfare jammer platform (rendered as a 1-UAV swarm) sweeps a 310 km corridor in seven steps at 2.2-second intervals. Each step produces a `STROBE_TYPE.INTERFERENCE` strobe (type 6.0: "non-physical motion distortion") with a secondary `STROBE_TYPE.ANOMALY` jitter pulse nearby. The sweep concludes with a `STROBE_TYPE.CONFLICT` culmination strobe at the far end of the corridor.
BARRAGE_JAMMER profile identification: the corridor shape and interference expansion pattern are the training target here. An operator who has watched this scenario recognises the expanding interference band from live data.
### Scenario 5 — RECON_EXFIL
The most complex scenario. Six phases over 27 seconds:
1. **Deploy** — 4 recon UAVs leave a randomly selected city hub
2. **Collect** — 4 collection nodes light up at cardinal positions ~245 km from hub, each emitting `STROBE_TYPE.ANOMALY` at low altitude (800m — ground-level collection)
3. **Converge** — UAVs return; `STROBE_TYPE.C2` pulse at hub signals data inbound
4. **Burst** — Three escalating `STROBE_TYPE.CLUSTER` pulses at the hub (energies: 1.7 → 1.9 → 2.0) simulate data aggregation
5. **Exfil Arcs** — `renderPathArcs()` fans two synthetic path arcs to distinct remote endpoints, with `cable_alignment: { aligned: false }` and random destination ASNs
6. **Kill Chain** — `FULL_SPECTRUM_COORDINATION` at 93% confidence, with all four collection node positions passed as nearby clusters
RECON_EXFIL is the scenario most directly analogous to the drone-based signals collection operations that motivated the SCYTHE platform architecture. Watching it run on the live globe against real geographic labels makes the pattern recognition intuitive in a way that a flat diagram does not.
---
## Plugging Real Sensors into SCYTHE
The RF DRILL system uses the same API primitives as live data. That is by design. The path from simulation to live sensor data is a matter of what drives the same function calls.
Here is the integration architecture for four classes of real sensors:
### Software-Defined Radio (SDR) — RTL-SDR / HackRF / USRP
The `sdr_stream.py` and `sdr_websocket_manager.py` modules in the SCYTHE backend already handle raw IQ stream capture. The integration path from SDR to globe:
```
RTL-SDR / HackRF → sdr_stream.py (IQ capture + demodulation)
↓
rf_integrated_processor.py (signal classification)
↓ POST /api/signals/ingest
rf_scythe_api_server.py → cluster_swarm_engine.py
↓ SocketIO edge_event
Globe passive TIMING monitor picks up → injectStrobe()
```
The `ai_signal_classifier.py` module applies ML classification to detected signals before they reach the graph engine. A trained model on your frequency bands means the TIMING monitor badge reflects real-world RF activity on your antenna.
Connection to the drill: the same `injectStrobe()` calls the TIMING monitor triggers — with `STROBE_TYPE.RF` and a computed bearing from direction-finding — are what `_drillEWSweep()` uses. A live EW sweep on real hardware produces the same visual output on the globe as Scenario 4.
### Wi-Fi / Network Tap — PCAP Ingest
The PCAP pipeline is fully live:
```
tcpdump / Wireshark → .pcap file
↓ POST /api/pcap/upload
pcap_ingest.py → SessionData extraction
↓
cluster_swarm_engine.py → ASN resolution + phantom IX scoring
↓
Globe PHANTOM monitor next poll → renderPhantomIX()
```
For live tap integration (continuous capture rather than upload):
```python
# ws_ingest.py live worker
async def live_pcap_worker(interface: str):
cap = pyshark.LiveCapture(interface=interface)
for packet in cap.sniff_continuously():
session_data = extract_session(packet)
await cluster_swarm_engine.ingest_live_event(session_data)
```
The `ws_ingest.py` module already implements this worker pattern. Pointing it at a real network interface on a monitoring box produces live Phantom IX candidates without any further code changes.
### ATAK / TAK Server — CoT Relay
The `tak_cot_relay.py` module accepts Cursor-on-Target (CoT) XML from ATAK clients and translates it into SCYTHE recon entities:
```
ATAK client (GPS + sensor reports)
↓ CoT XML multicast / TCP
tak_cot_relay.py → parse_cot_event()
↓ POST /api/recon/entities
cluster_swarm_engine.py → recon entity pipeline
↓ SocketIO recon_entity_update
Globe SSE stream → _reconEntityPipeline() → globe entity
```
A field team with ATAK on their devices automatically populates the globe as recon entities. If those devices are also running SDR collection apps, their signal reports flow through the same pathway. The RECON_EXFIL drill is the direct simulation of this: collection nodes at cardinal positions, UAVs returning to hub, exfil arcs to remote endpoints.
### KiwiSDR / WebSDR — Remote RF Nodes
`KiwiSDRClient.py` implements the WebSocket client for the KiwiSDR network. Each KiwiSDR node is a web-accessible SDR receiver at a fixed geographic location — dozens are publicly accessible globally:
```
KiwiSDR network (global fixed nodes)
↓ WebSocket stream
KiwiSDRClient.py → signal event extraction
↓
rf_scythe_api_server.py /api/signals/kiwi_ingest
↓
cluster_swarm_engine.py → geographic signal correlation
↓
Globe TIMING + PHANTOM monitors
```
Running 8-10 KiwiSDR nodes simultaneously, each at a different longitude, produces the multi-node convergence patterns that Phantom IX detection is designed to find. If the same signal appears at coordinated timing across nodes in different ASNs — that is Scenario 2 (Synchronized Burst) in live data.
---
## The Kill Chain as Ground Truth
Every RF DRILL scenario concludes with `renderKillChainGraph()`. This is not cosmetic. The Kill Chain graph represents the system's confidence that what it observed constitutes a coordinated action — UAV deployment, C2 relay establishment, data collection and exfiltration, electronic warfare sweep.
In live operation, the kill chain score is derived from `cluster_swarm_engine.get_killchain_slope()` — the SLOPE passive monitor. When that monitor's badge increments and the stage field reads `IMMINENT`, the system has seen enough behavioral evidence to promote a kill chain without operator instruction.
The drill scenarios teach operators to recognise the visual and feed-message sequence that leads to that promotion. C2 Relay reaches `FULL_SPECTRUM_COORDINATION` at T+14s. RECON_EXFIL reaches it at T+27s. An operator who has watched both scenarios recognises the arc pattern, the strobe escalation, and the feed message cadence when they appear in live data — and knows how much time they have.
---
## Architecture Summary
```
┌─────────────────────────────────────────────────────────────────┐
│ SCYTHE Intelligence Globe │
│ cesium-hypergraph-globe.html │
├─────────────────────────────────────────────────────────────────┤
│ 7 Passive Monitors (background, staggered, delta-only alerts) │
│ 5 RF DRILL Scenarios (C2 Relay / Sync Burst / Phantom / │
│ EW Sweep / RECON_EXFIL) │
│ GPU Shader Field (10 STROBE_TYPE variants, 16-float buffer) │
│ Kill Chain Graph (SLOPE monitor → renderKillChainGraph) │
└───────────────────────────┬─────────────────────────────────────┘
│ HTTP + SocketIO
┌───────────────────────────▼─────────────────────────────────────┐
│ rf_scythe_api_server.py (port 8080) │
│ cluster_swarm_engine.py (data engine) │
├─────────────────────────────────────────────────────────────────┤
│ ASN resolution (pyasn + MaxMind, 10K LRU cache) │
│ Phantom IX scoring (Φ_ix = C_in/σ_geo × τ × R) │
│ Fingerprint drift detection (behavior / drift_mag) │
│ Intent field (geo-located, lat/lon centroid from event history)│
└──────┬──────────┬──────────────┬────────────────────┬───────────┘
│ │ │ │
SDR stream PCAP ingest CoT relay KiwiSDR nodes
(IQ capture) (tcpdump/ (ATAK clients) (global fixed
Wireshark) receivers)
```
---
## What the Drills Are Really For
An RF DRILL is not a toy. It is a procedure for teaching pattern recognition to human operators before the pattern appears in live data.
The SCYTHE globe renders real signals and simulated signals with identical visual primitives — the same shader, the same strobe types, the same arc geometries, the same kill chain graph. An operator who has run all five drill scenarios has seen the visual fingerprint of C2 relay establishment, synchronized multi-emitter bursts, open-ocean phantom convergence, EW corridor sweeps, and UAV-based collection exfiltration — against the actual globe, with actual geography, at actual scale.
When those patterns appear in the passive monitors without a drill running, the operator already knows what they mean.
That is the design goal: a system quiet enough that operators can focus, and specific enough that when it speaks, they already know the language.
---
*SCYTHE is an open intelligence platform. Sensor integrations, scenario contributions, and backend extensions are welcome.*
**[Source Repository]** | **[API Reference]** | **[Sensor Integration Guide]**