Network Effects in Physical Infrastructure: How Each Node Makes the System Smarter
Network effects are usually associated with software platforms (social networks, marketplaces, developer ecosystems). Physical infrastructure doesn't typically compound the same way.
OZ's architecture is designed so that it does.
The Venue Graph as compounding data asset#
Every OZ node, whether PanoNode or VI Venue, contributes spatial telemetry to the Venue Graph: player trajectories, game contexts, zone activations, incident patterns, equipment behavior, environmental conditions.
The Venue Graph is not a static database. It's a living corpus that grows with every match, every venue, and every season. More importantly, it improves with scale:
- More match data improves predictive camera cueing; the system learns where players will be, not just where they are
- More venue data accelerates commissioning; deployment playbooks encode installation learnings from every previous venue
- More operational data reduces recovery time; failure patterns from one venue inform automated responses at every venue
- More seasons capture temporal patterns: lighting changes, weather effects, seasonal calibration requirements
A competitor starting today has zero Venue Graph data. They must operate for years across many venues to accumulate the equivalent. This data compounds and cannot be purchased, downloaded, or synthesized.
The playbook flywheel#
OZ capture policies are codified in playbooks: zone definitions, priority schemas, capture policies, governance rules. Every deployment refines these playbooks:
The 10th football venue deploys faster than the 1st because the playbook has been tested at 9 venues. The 100th venue deploys faster still because the playbook has absorbed edge cases from 99 different venue geometries, lighting conditions, and operational contexts.
This is deployment leverage: each venue makes the next one cheaper and faster. The cost curve bends downward with scale. For the 1st venue, commissioning takes days. For the 50th venue with a similar profile, it takes hours.
Playbook refinement isn't automatic; it's the result of deliberate operational learning. Every commissioning, every recovery, every calibration is reviewed and encoded. This is the "scar tissue from real operations" that cannot be replicated except by operating at the same scale.
API consumer network effects#
The Spatial API creates a classic platform network effect: every new consumer that builds on OZ spatial data makes the platform more valuable for every other consumer.
When an analytics company integrates with the Spatial API, their product becomes dependent on OZ data contracts. When a coaching tool integrates, it creates a second dependency. When a fan engagement product integrates, a third. Each integration creates switching costs, and leaving OZ means re-integrating every downstream consumer.
But the effect goes further: more consumers means more usage data, which informs better API design, which attracts more consumers. The schema evolves based on real integration patterns, not theoretical requirements.
The three loops#
OZ's network effects operate through three reinforcing loops:
- Data Compound: More nodes → richer Venue Graph → better AI models → better capture quality → more demand → more nodes
- Operational Leverage: More deployments → refined playbooks → faster commissioning → lower cost per deployment → more deployments
- Platform Stickiness: More nodes → more API consumers → higher switching costs → stronger retention → more nodes
All three loops feed back into each other. A richer Venue Graph attracts more API consumers. More consumers justify more deployments. More deployments refine playbooks further.
Why this matters for defensibility#
Pure software network effects can be disrupted by a better product; a new social network can attract users away from an incumbent. Physical infrastructure network effects are harder to disrupt because they require physical deployment to match.
A competitor can build better software. They cannot build years of Venue Graph data. They cannot build hundreds of refined deployment playbooks. They cannot build a fleet of physically installed nodes. They cannot build an ecosystem of integrated API consumers.
The compounding is the defense.