See the signal. Understand the relationship. Predict the cascade. Act before the city breaks.
GHOSTNET is a real-time urban resilience and early-warning platform designed to understand how seemingly isolated infrastructure anomalies can propagate across Delhi's interconnected systems.
Instead of asking only:
"What is happening right now?"
GHOSTNET asks:
"Why is it happening, where will it spread, what will it affect, how confident are we, and what should operators do next?"
The platform combines:
- 12 specialized infrastructure micro-agents
- A 39-sector spatial city mesh
- Real-time telemetry ingestion
- Strict telemetry validation
- Cross-domain cascade reasoning
- Local LLM-powered intelligence
- Spatial risk propagation
- Citywide incident aggregation
- Real-time Socket.IO event streaming
- Historical replay
- Data integrity monitoring and recovery
- An operator-facing AI Assistant
- Interactive command-center visualization
Modern cities already have dashboards for individual systems.
Air-quality systems monitor pollution.
Traffic systems monitor congestion.
Power systems monitor load.
Emergency systems monitor incidents.
Hospitals monitor capacity.
But cities do not fail one subsystem at a time.
A pollution event can reduce visibility.
Reduced visibility can slow public transport.
Slower transport can increase road congestion.
Congestion can delay emergency response.
Delayed emergency response can increase healthcare pressure.
A local anomaly can therefore become a cross-domain urban failure.
Traditional monitoring systems often display these events independently.
GHOSTNET models the relationships between them.
+----------------------+
| URBAN SIGNALS |
| |
| Air · Rain · Traffic |
| Power · Transit · ER |
| Health · Social · NLP|
+----------+-----------+
|
v
+----------------------+
| 12 MICRO-AGENTS |
| |
| Domain intelligence |
+----------+-----------+
|
v
+-------------------------+
| 39-SECTOR CITY MESH |
| |
| Spatial relationships |
| + signal severity |
+------------+------------+
|
v
+----------------------+
| CASCADE ENGINE |
| |
| Risk propagation |
| Spatial decay |
| Cross-domain impact |
+----------+-----------+
|
+--------------+--------------+
| | |
v v v
Sector Cascade City Incident Prediction
| | |
+--------------+--------------+
|
v
+----------------------+
| GHOSTNET COMMAND UI |
| |
| MAP · NERVOUS SYSTEM |
| SIGNALS · CASCADES |
| REPLAY · AI ASSISTANT|
+----------------------+
The difference is not another dashboard.
The difference is treating the city as an interconnected system.
GHOSTNET follows the chain:
Signal
|
v
Micro-Agent
|
v
Validation
|
v
Spatial Context
|
v
Cross-Domain Interaction
|
v
Cascade Propagation
|
v
Prediction
|
v
Intervention
The platform combines five major intelligence layers:
REAL-TIME DATA
+
MULTI-AGENT INTELLIGENCE
+
SPATIAL COMPUTATION
+
TEMPORAL REPLAY
+
DECISION SUPPORT
GHOSTNET is composed of three major runtime layers.
┌─────────────────────────────┐
│ AUTONET / AI ENGINE │
│ │
│ Python + FastAPI │
│ 12 Micro-Agents │
│ Sector State Store │
│ Qwen 2.5 Cascade Reasoning │
└──────────────┬──────────────┘
│
│ Socket.IO
│ agent-signal
│ cascade-alert
│ cascade-clear
│ agent-comms
│ city-incident
v
┌─────────────────────────────┐
│ GHOSTNET BACKEND │
│ │
│ Node.js + Express │
│ Strict Validation Gate │
│ In-Memory State Store │
│ Socket.IO Event Router │
│ Data Integrity Layer │
└──────────────┬──────────────┘
│
│ Socket.IO
v
┌─────────────────────────────┐
│ COMMAND CENTER │
│ │
│ React + Vite │
│ GhostnetContext │
│ Cesium │
│ Recharts │
│ Interactive UI │
│ AI Assistant │
└─────────────────────────────┘
The three layers have deliberately separated responsibilities.
Responsible for:
- Generating and analyzing sector telemetry
- Domain-specific agent intelligence
- Maintaining sector state
- Spatial cascade calculations
- Cross-domain reasoning
- LLM-assisted cascade synthesis
- Producing structured events
Responsible for:
- Receiving telemetry
- Validating telemetry contracts
- Protecting state from malformed data
- Maintaining low-latency in-memory state
- Broadcasting validated events
- Managing real-time Socket.IO communication
- Handling data-integrity events
Responsible for:
- Visualizing the city
- Displaying live signals
- Showing agent health
- Showing cascades
- Displaying citywide incidents
- Visualizing spatial propagation
- Historical replay
- Data integrity monitoring
- AI-assisted operator interaction
GHOSTNET uses specialized micro-agents instead of treating the entire city as one generic AI agent.
| # | Agent | Domain | Primary Intelligence |
|---|---|---|---|
| 01 | smog_dispersion |
Environment | Pollution, visibility and atmospheric conditions |
| 02 | waterlogging_hydrology |
Environment | Rainfall, drainage and accumulation |
| 03 | thermal_stress |
Environment | Temperature anomalies and heat stress |
| 04 | transit_fleet |
Transit | Fleet speed, delay and bottlenecks |
| 05 | road_corridor |
Transit | Corridor congestion and road capacity |
| 06 | metro_transit |
Transit | Station inflow and passenger pressure |
| 07 | power_grid |
Infrastructure | Transformer and grid load |
| 08 | industrial_hazard |
Infrastructure | Industrial incidents and hazardous events |
| 09 | hospital_capacity |
Infrastructure | ICU and hospital capacity pressure |
| 10 | emergency_dispatch |
Civic | Emergency calls and dispatch pressure |
| 11 | social_panic |
Civic | Public sentiment and panic propagation |
| 12 | municipal_news |
Civic | Civic incidents, closures and disruption reports |
Each agent produces normalized intelligence that can participate in the larger city-wide model.
GHOSTNET models Delhi as a spatial network rather than a flat collection of locations.
Each sector acts as a node.
Signals belong to sectors.
Cascades propagate between sectors.
+-----------+
| SECTOR A |
+-----+-----+
|
+------------+------------+
| | |
v v v
+--------+ +--------+ +--------+
|SECTOR B| |SECTOR C| |SECTOR D|
+----+---+ +----+---+ +----+---+
| | |
+------------+------------+
|
v
+-----------+
| SECTOR E |
+-----------+
This gives every signal spatial context.
An anomaly near its source sector is not treated identically to an anomaly far away.
GHOSTNET models spatial propagation using a distance-decay relationship:
H(A -> B) = R_A * e^(-lambda * distance(A,B))
Where:
R_A
|
+-- risk generated by source signal A
distance(A,B)
|
+-- spatial distance between sectors
lambda
|
+-- spatial decay parameter
Signal severity is derived from health:
severity = 1 - healthScore / 100
Conceptually:
Source Severity
x
Agent Weight
x
Spatial Decay
=
Sector Contribution
Multiple agents can contribute to the same sector.
SMOG
|
v
+-----------+
RAIN -------->| SECTOR |<-------- POWER
+-----+-----+
|
v
TRANSIT
This creates a network-level risk model rather than a collection of isolated thresholds.
A sector becomes a candidate cascade node when accumulated propagated risk crosses the configured cascade threshold.
The cascade engine identifies:
- Primary sector
- Spatial spread
- Triggered agents
- Cascade score
- Confidence
- Predicted event
- Estimated time horizon
- Recommended interventions
Example:
{
"alertId": "ALT_2026_0819_1001",
"primarySectorId": "DEL_EAST_LN",
"primarySectorName": "Laxmi Nagar",
"district": "East Delhi",
"cascadeScore": 0.82,
"confidence": 91,
"predictedEvent": "Severe smog stagnation with transport slowdown",
"hoursUntil": 1.0,
"spatialSpread": [
"DEL_EAST_PV",
"DEL_NORTH_ISBT"
],
"triggeredAgents": [
"smog_dispersion",
"transit_fleet"
],
"recommendations": [
"Speed reduction on Vikas Marg",
"Deploy smog guns at Laxmi Nagar"
],
"timestamp": "2026-08-20T19:05:00Z"
}Every agent signal follows a common normalized envelope.
{
"sectorId": "DEL_EAST_LN",
"district": "East Delhi",
"agentId": "waterlogging_hydrology",
"domain": "environment",
"healthScore": 15,
"anomalyLevel": "critical",
"signal": "Underpass waterlogged at Vikas Marg",
"isLiveAnchor": false,
"location": {
"placeName": "Vikas Marg Underpass, Laxmi Nagar",
"lat": 28.6304,
"lng": 77.2777,
"radiusMeters": 300
},
"timestamp": "2026-08-11T12:00:00.000Z"
}The normalized signal can power:
+-- CITY MAP
|
Signal -----------+-- AGENT CARD
|
+-- SIGNAL FEED
|
+-- SPARKLINE
|
+-- CASCADE ENGINE
|
+-- REPLAY
|
+-- ANALYTICS
This shared contract prevents different UI surfaces from inventing independent interpretations of the same event.
GHOSTNET uses Socket.IO as its real-time event layer.
BACKEND
|
| Socket.IO
v
+--------------+
| useSocket() |
+------+-------+
|
+----------+----------+
| | |
v v v
SIGNAL CASCADE CITY INCIDENT
| | |
+----------+----------+
|
v
GhostnetContext
|
v
UI SYSTEM
Core events:
agent-signal
cascade-alert
cascade-clear
agent-comms
city-incident
city-incident-clear
data-integrity
| Event | Purpose |
|---|---|
agent-signal |
Live sector telemetry |
cascade-alert |
New sector-level cascade |
cascade-clear |
Resolution of a sector cascade |
agent-comms |
Cross-agent communication |
city-incident |
Backend-owned citywide incident |
city-incident-clear |
Resolution of citywide incident |
data-integrity |
Rejected or invalid telemetry notification |
The Node.js gateway acts as the central telemetry validation boundary.
Incoming Telemetry
|
v
+----------------------+
| STRICT VALIDATION |
| |
| Schema |
| Required Fields |
| Types |
| Agent Contract |
+----------+-----------+
|
+----+----+
| |
VALID INVALID
| |
v v
Store Reject
| |
v v
Broadcast data-integrity
The validation layer is intentionally placed before state mutation and event broadcast.
This means malformed telemetry cannot silently pollute the live city state.
The backend preserves payload fidelity for valid signals and relays them without changing the shared contract.
GHOSTNET includes a dedicated Data Integrity layer for demonstrating and monitoring telemetry validation.
The system distinguishes three failure categories:
INCOMPLETE
INVALID
INCONSISTENT
A required field is missing.
Example:
Missing required field: domain
A field exists but violates its schema or type constraints.
Examples:
healthScore > 100
pm25 contains an invalid string
The signal contradicts an established contract.
Example:
Agent domain does not match its registered domain
Malformed Telemetry
|
v
validateAgentSignal()
|
v
Validation Failure
|
+-------------------+
| |
v v
State NOT Mutated data-integrity
|
v
Socket.IO Event
|
v
Command Center
A rejected signal does not become live telemetry.
Therefore:
REJECTED TELEMETRY
and
LIVE TELEMETRY
are tracked independently.
The interface never artificially subtracts a rejected signal from the live telemetry count.
The controlled demonstration endpoint is:
POST /api/demo/data-integrityExample request:
{
"type": "incomplete",
"agentId": "smog_dispersion",
"sectorId": "DEL_EAST_LN"
}The endpoint intentionally constructs a malformed telemetry record, passes it through the same existing validation path used by normal telemetry, confirms rejection, and emits a data-integrity event.
It does not emit an agent-signal for the rejected record.
The command interface exposes:
- Current integrity status
- Rejected telemetry count
- Live telemetry count
- Validation reason
- Affected agent
- Affected sector
- Recovery state
- Latest validated telemetry
- Session-local validation events
- State-protection status
Possible system states include:
OPERATIONAL
DEGRADED
RESTORED
When a malformed signal is rejected:
SYSTEM STATUS
DEGRADED
REJECTED
1
LIVE TELEMETRY
468
When valid telemetry resumes:
SYSTEM STATUS
RESTORED
LIVE STATE SYNCHRONIZED
The rejected record never becomes part of the live state.
Sector cascades and citywide incidents are intentionally separate layers.
CITY
|
+--------------+--------------+
| | |
v v v
DISTRICT DISTRICT DISTRICT
| | |
CASCADE CASCADE CASCADE
| | |
AGENTS AGENTS AGENTS
A citywide incident aggregates high-level consequences:
CITYWIDE INCIDENT
|
+-- Severity
+-- Cascade Score
+-- Executive Summary
+-- Root Cause Domain
|
+-- Affected Areas
| +-- Primary Sector
| +-- Secondary Sectors
| +-- Impacted Domains
| +-- Failure Metrics
|
+-- Mitigation
+-- Immediate Directives
+-- Transit Rerouting
+-- Public Advisories
The important architectural boundary is:
Citywide incidents are backend-owned.
The frontend renders the event it receives.
It does not invent a city incident merely because sector-level risk exists.
Consider an apparently isolated event:
PM2.5 SPIKE
GHOSTNET can model the chain:
PM2.5
|
v
Visibility
|
v
Bus Speed
|
v
Road Congestion
|
+----------------+
| |
v v
Metro Inflow Emergency Calls
| |
v v
Station Stress Dispatch Load
| |
+-------+--------+
|
v
City Mobility Risk
|
v
Healthcare Pressure
Instead of simply displaying:
Risk Score = 87
the platform can explain the relationship:
Visibility degradation
->
Transit capacity degradation
->
Road congestion
->
Emergency response pressure
This makes the cascade understandable to an operator.
GHOSTNET exposes cross-agent interactions.
Example:
SMOG & DISPERSION
|
| visibility below threshold
v
BUS FLEET
|
| speed degradation detected
v
ARTERIAL CONGESTION
|
| corridor capacity collapsing
v
METRO TRANSIT
|
| passenger overflow
v
EMERGENCY DISPATCH
The operator can therefore understand not only that risk increased, but how one domain is influencing another.
The Nervous System treats the city as a living network.
Instead of asking:
"Which card is red?"
it asks:
"Where is the city's stress propagating?"
The visualization connects:
AGENT
|
v
SECTOR
|
v
DOMAIN
|
v
CASCADE
|
v
CITY
This exposes relationships that conventional card-based dashboards hide.
GHOSTNET also provides an operator-facing AI Assistant as an additional interaction layer on top of the command center.
The assistant is intended to make the system easier to interrogate without forcing an operator to manually navigate every dashboard surface.
Instead of searching through:
MAP
SIGNALS
SECTORS
CASCADES
AGENTS
CITY INCIDENTS
the operator can use the assistant as a conversational interface for understanding the current situation.
The assistant complements — rather than replaces — the underlying intelligence pipeline.
GHOSTNET STATE
|
+--------------+--------------+
| | |
Signals Cascades Incidents
| | |
+--------------+--------------+
|
v
AI ASSISTANT
|
v
Operator Explanation
The assistant fits the broader GHOSTNET philosophy:
WHAT happened?
|
v
WHERE is it?
|
v
WHY is it happening?
|
v
WHAT is it affecting?
|
v
WHAT happens next?
|
v
WHAT should the operator inspect?
The assistant is therefore an interaction layer over the existing city intelligence rather than a separate source of truth.
GHOSTNET is designed to answer:
"How did we get here?"
rather than only:
"What is happening now?"
Replay reconstructs the progression of signals over time.
T-38h
|
+-- weak anomaly
|
T-24h
|
+-- regional degradation
|
T-12h
|
+-- cross-domain interaction
|
T-06h
|
+-- cascade formation
|
T-01h
|
+-- critical city impact
Replay acceleration allows the evolution to be observed quickly:
1x
5x
10x
The same visualization layer can consume changing temporal state.
GHOSTNET intentionally separates live intelligence from historical reconstruction.
Backend
|
v
Socket.IO
|
v
Signals
|
v
Current City State
Historical Dataset
|
v
Replay Engine
|
v
Time-Controlled Signals
|
v
Same Visualization Layer
This allows the platform to use the same visualization concepts for both current operations and historical analysis.
Detection without action is incomplete.
GHOSTNET attaches recommendations to cascade events.
Example:
CASCADE DETECTED
PRIMARY
Connaught Place
CONFIDENCE
89%
TRIGGERED
Transit Fleet
Power Grid
Social Panic
IMMEDIATE DIRECTIVE
Deploy traffic response teams
TRANSIT
Reroute affected corridors
PUBLIC
Issue civic advisory
The platform therefore moves from:
OBSERVATION
to:
DECISION SUPPORT
The ultimate purpose is to increase warning time so that operators can intervene before a local anomaly becomes systemic.
GHOSTNET is designed as an operational command interface rather than a conventional analytics dashboard.
Core interfaces include:
- City Map
- Nervous System
- Signal Feed
- Sector Browser
- Sector Detail
- Cascade Intelligence
- City Incident Intelligence
- Agent Communication
- Historical Replay
- Data Integrity
- Schema Documentation
- AI Assistant
The interface is designed around the operational questions:
WHAT
WHERE
WHY
HOW
WHAT NEXT
src/
|
+-- assets/
|
+-- components/
| |
| +-- dashboard/
| | +-- AgentCard.jsx
| | +-- CascadeAlertTray.jsx
| | +-- CityCascadePanel.jsx
| | +-- CityIncidentDrawer.jsx
| | +-- DomainBreakdown.jsx
| | +-- JudgeDemoPanel.jsx
| | +-- SectorCascadePanel.jsx
| | +-- SignalFeed.jsx
| | +-- TopThreats.jsx
| |
| +-- sectors/
| | +-- DistrictSection.jsx
| | +-- SectorPill.jsx
| |
| +-- shared/
| +-- SeverityLegend.jsx
| +-- Sidebar.jsx
| +-- Topbar.jsx
|
+-- context/
| +-- GhostnetContext.jsx
| +-- ReplayContext.jsx
|
+-- hooks/
| +-- useMockStream.js
| +-- useReplayEngine.js
| +-- useSocket.js
| +-- useSparklineData.js
|
+-- lib/
| +-- citySeverity.js
| +-- replayData.js
| +-- schema.js
| +-- sectors.js
| +-- theme.js
|
+-- pages/
| +-- CascadeLog.jsx
| +-- Citymap.jsx
| +-- Dashboard.jsx
| +-- DataIntegrity.jsx
| +-- NervousSystem.jsx
| +-- Replay.jsx
| +-- SchemaDocs.jsx
| +-- SectorBrowser.jsx
| +-- SectorDetail.jsx
|
+-- App.css
+-- App.jsx
+-- index.css
+-- main.jsx
GhostnetContext acts as the frontend state boundary.
GhostnetContext
|
+----------------+----------------+
| | |
signals cascades cityIncident
| | |
v v v
sectors cascade UI city UI
|
v
feed / stats
Shared state includes:
- Signals
- Sectors
- Signal feed
- Cascades
- Cascade history
- City incidents
- City incident history
- Agent communications
- Cascade acknowledgements
- Backend connection state
- Data integrity state
- Network statistics
This gives the application a consistent source of truth.
A single backend signal can flow through the entire platform:
Backend
|
v
Socket.IO
|
v
useSocket
|
v
GhostnetContext
|
+----------+----------+----------+
| | | |
v v v v
Sector Agent Signal Map
State Card Feed
|
v
Sparkline
|
v
Cascade Intelligence
The same source data powers multiple surfaces instead of each component inventing its own interpretation.
GHOSTNET distinguishes signal provenance using:
isLiveAnchor
This allows the system to distinguish between:
LIVE DATA
and:
SIMULATED / SYNTHETIC / DERIVED DATA
This distinction is important for engineering integrity and demonstration transparency.
Individual agent signals use three primary states:
+---------------+
| NOMINAL |
| healthy |
+---------------+
+---------------+
| WARNING |
| degrading |
+---------------+
+---------------+
| CRITICAL |
| failing |
+---------------+
Cascade state is deliberately separate from individual signal severity.
A signal can be moderate while still contributing significantly to a larger cascade.
This prevents the platform from reducing intelligence to:
red = danger
green = safe
The backend acts as the central telemetry gateway between the Python/AI service and the React command center.
┌───────────────────────────────────────────┐
│ AUTONET AI SERVICE │
│ │
│ 39 Sectors × 12 Agents │
│ Telemetry + Cascade Reasoning │
└─────────────────────┬─────────────────────┘
│
│ Socket.IO / REST
v
┌───────────────────────────────────────────┐
│ GHOSTNET NODE.JS GATEWAY │
│ │
│ Strict Validation Gate │
│ ↓ │
│ In-Memory State Store │
│ ↓ │
│ Socket.IO Broadcast Engine │
└─────────────────────┬─────────────────────┘
│
│ Socket.IO
v
┌───────────────────────────────────────────┐
│ REACT COMMAND CENTER │
│ │
│ Map · Signals · Cascades · Replay │
│ Data Integrity · AI Assistant │
└───────────────────────────────────────────┘
- Atomic telemetry validation
- In-memory state management
- Socket.IO event routing
- Signal history
- Cascade state
- City incident state
- Agent communication history
- Data integrity events
- REST endpoints for state retrieval
- Development/test injection endpoints
The gateway uses in-memory data structures for low-latency state access.
sectors =
Map<sectorId, Map<agentId, signalPayload>>
activeCascades =
Map<primarySectorId, cascadeAlertPayload>
signals =
Array<signalPayload>
agentComms =
Array<commsPayload>
cascadeHistory =
Array<cascadeAlert | cascadeClear>
activeCityIncident =
{ current: null | cityIncidentPayload }The backend is intentionally optimized as a real-time gateway rather than a traditional persistence-heavy application.
The backend exposes REST endpoints for ingestion, state retrieval and development workflows.
POST /agent-signalIngests and validates an agent signal.
POST /cascade-alert
POST /cascade-clearCreates or clears sector-level cascades.
POST /agent-commsSends a cross-agent communication event.
POST /city-incident
POST /city-incident-clearCreates or clears a citywide incident.
POST /api/demo/data-integrityRuns the controlled data-integrity demonstration.
GET /health
GET /mesh/snapshot
GET /sectors/state
GET /sectors/state/:sectorId
GET /agent-signals
GET /cascades
GET /agent-comms
GET /history
GET /replay
GET /replay/datesGET /test
POST /test
GET /test-city-incident
POST /test-city-incidentThe intelligence layer is a Python-first, event-driven monitoring system.
The master FastAPI application manages:
- AI brain lifecycle
- Socket.IO connection
- Sector state
- Agent startup and shutdown
- Cascade engine execution
Each agent runs asynchronously and follows a common lifecycle.
Fetch
|
v
Compute
|
v
Store
|
v
Emit
The Cascade Engine reads sector state and performs structured risk synthesis.
The system uses a local Qwen 2.5 model served through llama-server for structured cascade reasoning.
External Data Sources
|
v
Data Fetchers
|
v
12 Micro-Agents
|
v
Health / Anomaly Calculation
|
v
SectorStateStore
|
v
Normalized agent-signal
|
v
Socket.IO
|
+-------------------+
| |
v v
GHOSTNET Backend Cascade Engine
|
v
Qwen 2.5
|
v
Cascade Reasoning
|
v
cascade-alert / clear
|
v
GHOSTNET UI
- React
- Vite
- Tailwind CSS
- Recharts
- Cesium
- Resium
- Socket.IO Client
- React Router
- Node.js
- Express
- Socket.IO
- Native JavaScript
Map-based state store - Node.js native test runner
- Python 3.11+
- FastAPI
python-socketioaiohttphttpx- Pydantic
- pandas
- openpyxl
- BeautifulSoup
- gtfs-kit
- PyTorch
- Transformers
- Local
llama-server - Qwen 2.5
GHOSTNET/
|
+-- frontend/
| |
| +-- src/
| | +-- components/
| | +-- context/
| | +-- hooks/
| | +-- lib/
| | +-- pages/
| | +-- App.jsx
| | +-- main.jsx
| |
| +-- package.json
| +-- vite.config.js
| +-- .env
|
+-- backend/
| |
| +-- src/
| | +-- agents/
| | +-- engine/
| | +-- lib/
| | +-- routes/
| | +-- socket/
| | +-- store/
| |
| +-- server.js
| +-- app.js
| +-- package.json
| +-- .env
| +-- test/
|
+-- intelligence/
| |
| +-- main.py
| +-- global_config.py
| +-- Agents/
| +-- Cascade_Engine/
| +-- config/
| +-- qwen2.5run.sh
| +-- pyproject.toml
|
+-- README.md
GHOSTNET is composed of multiple services.
For a complete local demonstration, start:
- The Python / AutoNet intelligence service
- The Node.js GHOSTNET backend
- The React frontend
- Node.js 18+
- npm
- Node.js 18+
- npm
- Python 3.11+
- pip
- Local model runtime /
llama-server - Qwen 2.5 model
cd backend
npm installCreate the backend environment file:
cp .env.example .envExample:
PORT=3001
HOST=0.0.0.0
NODE_ENV=development
ALLOWED_ORIGINS=*Start the backend:
npm run devor:
npm startThe backend should bind to:
http://localhost:3001
Socket.IO is exposed from the same server.
cd frontend
npm installCreate:
.env
Example:
VITE_BACKEND_URL=http://localhost:3001If Cesium is enabled, provide the corresponding Vite-exposed Cesium Ion environment variable required by the frontend implementation.
For Vite browser variables, use the VITE_ prefix.
Start the frontend:
npm run devThe Vite development server will provide the command-center interface.
cd intelligenceInstall the Python dependencies according to the project's pyproject.toml.
Configure the required environment variables in .env.
Typical configuration includes:
POLL_INTERVAL_SEC=
SOCKET_URL=
WAQI_TOKEN=
TOMTOM_API_KEY=
DELHI_TRANSIT_API_KEY=Start the local Qwen runtime using:
./qwen2.5run.shThen start the Python master service:
python main.pyThe local LLM service is expected to be available through the OpenAI-compatible endpoint used by the Cascade Engine.
The intended local runtime looks like:
Terminal 1
-----------
Qwen / AI Runtime
Terminal 2
-----------
Python AutoNet
|
v
Socket.IO
|
v
Terminal 3
-----------
Node.js GHOSTNET Backend
|
v
Port 3001
Terminal 4
-----------
React Frontend
|
v
Browser
Once all services are running:
AI Agents
|
v
Backend
|
v
Socket.IO
|
v
GhostnetContext
|
+---- Map
+---- Signals
+---- Cascades
+---- City Incidents
+---- Data Integrity
+---- AI Assistant
+---- Replay
The backend includes an integration/acceptance test suite using Node.js's native test runner and TAP assertions.
Run:
npm testThe acceptance suite validates the core operational contracts, including:
- Valid agent-signal ingestion
- State mutation for valid telemetry
- Socket.IO signal emission
- Cascade alert ingestion
- Cascade clear lifecycle
- Agent communication
- Malformed telemetry rejection
- Invalid metric/type rejection
- City incident lifecycle
- State querying
- WebSocket ingestion
- WebSocket validation rejection
- Data integrity demonstration
- Rejected telemetry not mutating live state
data-integrityevent emission- No
agent-signalemission for rejected telemetry - Normal telemetry continuing correctly after a data-integrity event
The latest backend acceptance run contains 13 passing acceptance cases, including the data-integrity cases.
The critical data-integrity contract is:
POST /api/demo/data-integrity
|
v
Construct malformed signal
|
v
validateAgentSignal()
|
v
REJECTED
|
+-----+-----+
| |
v v
No state data-integrity
mutation event
|
v
Frontend
After the rejection, a normal valid signal must still be able to update state normally.
This demonstrates that the validation gate is protective rather than destructive.
Every visualization should answer a question.
A risk without a location is incomplete.
A snapshot cannot fully explain a cascade.
Environmental, mobility, infrastructure and civic systems continuously influence one another.
Live, synthetic and derived signals should remain distinguishable.
Malformed data must not contaminate operational state.
Do not only say:
CRITICAL
Explain:
WHY
WHERE
HOW
WHAT NEXT
The strongest GHOSTNET demonstration is a narrative rather than a feature tour.
CITY STATUS
NOMINAL
Show:
- 39-sector spatial mesh
- Agent network
- Live command center
A signal arrives:
SMOG & DISPERSION
Health: 31
Status: CRITICAL
The audience sees the anomaly before hearing the explanation.
The source sector becomes active.
Nearby sectors begin receiving propagated risk.
Explain:
"The system is not just detecting the anomaly. It is evaluating where its effects can propagate."
Show the agent communication chain:
SMOG
|
v
TRANSIT
|
v
CONGESTION
|
v
METRO
The audience sees the relationship forming.
Open cascade intelligence:
CASCADE DETECTED
Confidence: 89%
Primary:
Connaught Place
Spread:
3 sectors
Triggered:
Transit
Power
Social
Use the AI Assistant to interrogate the situation conversationally.
The operator can move from manually inspecting multiple panels toward asking the system for contextual explanations of the current urban state.
Switch to Replay.
Increase speed:
10x
Watch the cascade form.
The audience now sees not only the emergency, but the sequence that produced it.
Trigger the controlled data-integrity demonstration.
MALFORMED TELEMETRY
|
v
VALIDATION GATE
|
v
REJECTED
|
v
STATE PROTECTED
Show:
REJECTED TELEMETRY
+
LIVE TELEMETRY
as separate values.
Then send valid telemetry and demonstrate:
DEGRADED
|
v
RESTORED
|
v
LIVE STATE SYNCHRONIZED
This proves that invalid telemetry is rejected without corrupting the operational state.
NORMAL CITY
|
v
ANOMALY
|
v
VALIDATION
|
v
SPATIAL PROPAGATION
|
v
CROSS-DOMAIN INTERACTION
|
v
CASCADE DETECTION
|
v
CITYWIDE IMPACT
|
v
AI EXPLANATION
|
v
INTERVENTION
The audience should never have to imagine the cascade.
They should be able to watch it happen.
The depth of GHOSTNET does not come from the number of cards on the screen.
It comes from the interaction between:
DATA
|
v
AGENTS
|
v
SECTORS
|
v
DOMAINS
|
v
CASCADE
|
v
PREDICTION
|
v
INTERVENTION
A city signal becomes meaningful when its context is understood.
A cascade becomes meaningful when its propagation is understood.
A prediction becomes valuable when it provides enough warning to act.
Delhi is not 39 separate sectors.
It is one interconnected system.
+-------------+
| ENVIRONMENT |
+------+------+
|
+--------v--------+
| MOBILITY |
+--------+--------+
|
+-----------v-----------+
| INFRASTRUCTURE |
+-----------+-----------+
|
+--------v--------+
| CIVIC |
+--------+--------+
|
+--------v--------+
| HEALTHCARE |
+-----------------+
The city becomes a graph.
The agents become nodes of intelligence.
The signals become observations.
The cascade becomes the prediction.
The operator gets something more valuable than another dashboard:
The ultimate metric is not:
Number of charts
It is not:
Number of AI agents
It is:
WARNING TIME
If GHOSTNET can identify a developing cross-domain failure before it becomes obvious to a human operator, the system has created operational value.
The desired progression is:
INCIDENT
^
|
DETECTED
|
TOO LATE
|
-------------------------
|
GHOSTNET
|
v
EARLY WARNING
|
v
INTERVENTION
|
v
FAILURE REDUCED
The architecture allows additional capabilities without replacing the core system.
Potential future extensions include:
Forecast Calibration
|
v
Prediction Accuracy
|
v
False Positive Analysis
|
v
Intervention Outcome Tracking
|
v
Model Feedback
|
v
Improved Cascade Prediction
The long-term objective is to move from:
DETECTION
to:
PREDICTION
and eventually:
PRESCRIPTION
A normal dashboard asks:
Which sensor is bad?
GHOSTNET asks:
Which relationships are becoming dangerous?
A normal alert asks:
What happened?
GHOSTNET asks:
What happened?
Where?
Why?
What is it affecting?
Where will it spread?
How confident are we?
What should operators do?
A normal historical chart shows:
PAST -> PRESENT
GHOSTNET attempts to reconstruct:
PAST
|
v
CAUSE
|
v
PROPAGATION
|
v
CASCADE
|
v
FAILURE
That is the core philosophy of the platform.
Built for the city that has not failed yet.