Delivery and SLA
One company is responsible for the whole delivery, start to finish.
How much data, and how fast
Start with how much data the machines make.
Each machine produces roughly one terabyte per hour while operating, about 2.2 Gbps, eight terabytes per shift, and the volumes compound at fleet scale.
| Scale | Data per day | Data per month | Rate while running |
|---|---|---|---|
| One machine, one shift | 8 TB | ~240 TB | ~2.2 Gbps while operating |
| Busy site, one shift | ~472 TB | ~14.2 PB | ~131 Gbps at full concurrency |
| Busy site, three shifts | ~1,416 TB | ~42.5 PB | ~131 Gbps at full concurrency |
| Fleet of 120 to 150 machines | ~1,920 to 3,000 TB | ~58 to 90 PB | Multi-hundred-Gbps class |
Full-concurrency planning values. Actual duty cycle, compression, and concurrency are measured per site, and each Site Deployment Plan sets the capacity tier from observed behavior: required tier equals data per day divided by the allowable delivery window, times engineering headroom. Dense sites enter the 100G-and-above class; final provisioning may be 100G, 200G, 400G, or aggregated equivalents.
Work out how much data your sites will make.
Set the size and schedule of a site to see the daily and monthly volume, and what the whole program produces.
Site data volume planner
Planning figures only, based on an illustrative rate of about 1 TB per machine per hour of operation. Actual rates depend on sensor set, capture settings, and duty cycle.
Why a fast connection alone is not enough
Delivering one high-density shift of roughly 472 TB requires an average payload rate near 131 Gbps in an 8-hour window, 87 Gbps in 12 hours, or 44 Gbps in 24 hours, before protocol overhead, headroom, retransmission, maintenance, failures, and backlog recovery.
Buffering prevents data loss during an impairment. It does not correct a persistent transport-capacity deficit. At roughly 59 TB generated per hour, a two-hour interruption accumulates about 118 TB of backlog and a full shift about 472 TB, and recovery is arithmetic: catch-up time equals outage duration times generation rate divided by spare capacity. A site generating 80 Gbps on 100 Gbps of transport needs roughly eight hours to drain a two-hour outage while production continues. A link run near saturation has poor recovery characteristics, so deliberate headroom is an engineering requirement, not padding.
Each Site Deployment Plan therefore engineers five things explicitly: a Data Delivery SLA measured from data creation to acceptance at the ingest destination, a local buffer sized in hours and terabytes from measured P95 and P99 generation, a maximum backlog age, a recovery drain-rate requirement, and end-to-end delivery telemetry. Connectivity is one component. Data delivery is the outcome, and the pipeline is engineered and observed as a single system.
Check whether a circuit keeps up with a site.
Enter a daily volume and a circuit speed to see how long a day of data takes to move, and whether a backlog builds up.
Transport sizing and backlog
Illustrative planning arithmetic. Effective throughput accounts for protocol overhead and real-world utilization, and assumes a dedicated path with no public internet transit on the data path.
One company to call
OSI is the single point of accountability from site demarcation to destination handoff. Availability and restoration targets, service credits, and chronic-outage termination rights apply to the managed service as a whole, whichever underlying component fails. There is no multi-party fault isolation and no gap between what was promised and who owes the remedy.
What we promise
What we promise, in plain terms.
Availability targets
Stated per service element; protected paths carry the highest tier
Engineered availability
Where a specific link cannot meet the standard target as engineered, its real value is stated in the Site Deployment Plan and approved by you before it binds
Engineered restoration
Tower-dependent or access-constrained paths may carry a stated restoration target, approved the same way
Service credits
Applied against the affected service allocation; credits from one root cause do not stack
Chronic outage
Repeated failure creates a termination right
Data Delivery SLA
Each site's Deployment Plan states the maximum time from data creation to acceptance at the ingest destination, with buffer, backlog-age, and drain-rate engineering behind it
No promises we cannot keep
You approve the real numbers before they bind.
Every site follows the same sequence: survey, then a Site Deployment Plan stating the engineered values for that site, then your authorized approval, then installation, then acceptance. Nothing is discovered after signature, because the approval gate sits before it.
- 01
Survey
- 02
Site Deployment Plan
- 03
Your approval
- 04
Installation
- 05
Acceptance
What happens when something breaks
Degraded connectivity becomes a queue-depth problem rather than an operations problem: the network can have a bad day without the site having one.