> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vangrid.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Inside Vangrid's Sovereign Spatial Data Pipeline
> Understand how Vangrid moves data from edge nodes through cryptographic signing to your API requests, maintaining sovereignty at every step.
The Vangrid data pipeline is the governed path that every observation travels from physical capture to your application. At each stage, the pipeline enforces sovereignty controls, preserves cryptographic integrity, and filters for quality — so what arrives in your API response is not just spatially accurate, but verifiably so. Understanding the pipeline helps you predict latency, interpret response fields, and design your system to take full advantage of Vangrid's guarantees.
## Pipeline stages
Edge nodes continuously capture spatial observations from their environment. Sensors operate independently and asynchronously — there is no central clock or coordinated capture event. Each node records its observations with a local timestamp derived from a hardware clock synchronized to GPS time, ensuring sub-second accuracy across the network.
Raw sensor data is processed entirely on the node. The node runs local inference to extract spatial features — object positions, geometries, classifications, velocities — and produces a structured feature payload. Raw frames and sensor streams are discarded on-device after processing. Nothing leaves the node until this step is complete.
Edge compute is the mechanism behind Vangrid's privacy guarantee: because raw data never leaves the hardware, it cannot be intercepted, subpoenaed, or leaked in transit.
After extracting features, the node signs the payload with its private key. The resulting `provenance_hash` encodes:
* The node's unique identifier
* The capture timestamp
* A hash of the feature payload content
The signature is generated on-device using hardware-backed key storage. Any modification to the payload after signing — in transit, at rest, or in your own systems — produces a hash mismatch that you can detect with standard cryptographic verification.
Signed payloads from multiple nodes covering the same area of interest are ingested by Vangrid's aggregation layer. The aggregator:
* Groups observations by spatial overlap and temporal proximity
* Cross-corroborates observations from independent nodes to compute `ground_truth_score`
* Detects and flags conflicting observations rather than silently resolving them
* Merges compatible multi-view observations into unified feature records where appropriate
Aggregation adds latency proportional to the number of nodes contributing to a response. Real-time queries use a shorter aggregation window; historical queries use a larger one.
The aggregated, scored response is returned to your application as structured JSON over HTTPS. The response body contains a `features` array, each element carrying geometry, timestamps, quality scores, provenance, and any domain-specific fields relevant to your query type.
## What "sovereign" means
In the context of the Vangrid pipeline, **sovereign** means that data does not transit infrastructure outside your designated boundary without explicit, auditable consent.
Sovereignty operates at three levels:
* **Node-level** — Raw sensor data stays on the node. It does not traverse any network.
* **Infrastructure-level** — Signed feature payloads are routed only through Vangrid infrastructure within your configured sovereignty boundary. No third-party cloud provider or transit network touches your data without your authorization.
* **API-level** — Your API responses are delivered over TLS. Vangrid does not log or store query content beyond what is required for billing and provenance records.
For defense and government deployments, Vangrid supports nation-state grade sovereignty controls including air-gapped delivery modes, region-locked infrastructure, and custom key management integration. Contact [hello@vangrid.io](mailto:hello@vangrid.io) for details on these configurations.
Standard enterprise accounts operate within a single-region sovereignty boundary by default. Cross-region access requires explicit configuration and is audited in your account's provenance log.
## Latency characteristics
Real-time queries return observations captured within the last few seconds to minutes, depending on node density and AOI size. The aggregation window is short — Vangrid does not wait for all possible contributing nodes before returning a response. You receive a partial but fast result, with `node_count` and `ground_truth_score` reflecting the nodes that responded within the window.
Typical p50 latency for a real-time query over a small urban AOI is under 500ms from request to first byte. Larger AOIs or lower-density regions will be slower.
Historical queries retrieve observations from Vangrid's provenance archive. Because the data is already aggregated and stored, historical queries are not subject to node response latency — but they do incur retrieval and decryption overhead.
Historical responses include the full set of contributing nodes and their individual signed payloads, giving you a richer audit trail than real-time queries. Typical latency for historical queries is 1–5 seconds depending on archive depth and result size.
For applications that need continuous updates — fleet tracking, infrastructure monitoring, real-time situational awareness — Vangrid supports streaming subscriptions via WebSocket. Observations matching your AOI and filter criteria are pushed to your connection as they are aggregated, with latency comparable to real-time queries.
## Response data format
Every Vangrid API response is a GeoJSON-compatible JSON object. The top-level structure includes a `features` array where each element represents one spatial observation.
```json theme={null}
{
"query_id": "qry_01j9z3kfm8x2v4n7",
"timestamp": "2026-05-22T14:32:07.412Z",
"aoi": {
"type": "Polygon",
"coordinates": [[[-122.4194, 37.7749], [-122.4094, 37.7749], [-122.4094, 37.7849], [-122.4194, 37.7849], [-122.4194, 37.7749]]]
},
"node_count": 14,
"features": [
{
"feature_id": "feat_7d3a9c2e",
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [-122.4142, 37.7799, 12.4]
},
"properties": {
"classification": "vehicle.truck",
"velocity_mps": 4.2,
"heading_deg": 273.1,
"captured_at": "2026-05-22T14:32:05.198Z",
"ground_truth_score": 0.94,
"provenance_hash": "sha256:a3f8c1d9e4b27056f3a8c9d1e4b270a3f8c1d9e4b27056f3a8c9d1e4b270",
"sensor_modalities": ["camera", "lidar"],
"node_count": 3
}
}
]
}
```
Key response fields:
| Field | Type | Description |
| -------------------- | ---------------- | ----------------------------------------------------------------------------------------------------- |
| `query_id` | string | Unique identifier for this query, used in audit logs and support. |
| `node_count` | integer | Total number of nodes that contributed to this response. |
| `feature_id` | string | Unique identifier for this observation. |
| `geometry` | GeoJSON geometry | Position and shape of the observed feature. Coordinates are `[longitude, latitude, altitude_meters]`. |
| `classification` | string | Hierarchical object classification (e.g., `vehicle.truck`, `person.pedestrian`). |
| `captured_at` | ISO 8601 string | Timestamp of the original sensor capture on the node. |
| `ground_truth_score` | float | Confidence score from 0.0 to 1.0 based on multi-node corroboration. |
| `provenance_hash` | string | Cryptographic signature of this observation. |
| `sensor_modalities` | array | Sensor types that contributed to this feature. |
## How Vangrid differs from cloud-only alternatives
Cloud-only spatial platforms funnel raw data into a central processing cluster before returning results. This design introduces several limitations that Vangrid's pipeline avoids:
| | Cloud-only platforms | Vangrid |
| ----------------------- | -------------------------------------------- | ------------------------------------------ |
| **Privacy** | Raw data transits and is stored in the cloud | Raw data never leaves the edge node |
| **Provenance** | No per-observation cryptographic proof | Every feature carries a `provenance_hash` |
| **Sovereignty** | Data crosses arbitrary cloud regions | Data stays within your configured boundary |
| **Latency** | Round-trip to central cluster | Aggregation happens close to the edge |
| **Infrastructure cost** | You pay for cloud compute and storage | Vangrid absorbs node and compute costs |
When comparing Vangrid to a cloud-only alternative, ask the vendor: "Can you prove that a specific observation was not altered between capture and delivery?" With Vangrid, the `provenance_hash` answers that question without requiring you to trust any intermediary.