One Platform, Many Verticals: How the Same Node Serves Sports, Security, and Robotics
Most companies that serve multiple verticals build separate products for each. Separate codebases, separate teams, separate roadmaps. Each vertical adds cost proportional to complexity.
OZ serves multiple verticals with the same product. The architecture makes this possible because the platform was designed around configurable playbooks, not hardcoded use cases.
What stays the same#
Across every vertical OZ serves (sports, broadcasting, CCTV, robotics, defense), the following are identical:
Hardware: The same OZ VI Venue nodes with the same sealed enclosures, the same 4K PTZ cameras, the same robotic capture heads, the same on-venue GPU compute. Hardware doesn't know what sport it's watching or what facility it's monitoring.
Runtime: The same OZ Cortex inference runtime managing model pipelines, latency budgets, and resource allocation. The runtime executes whatever models and policies the playbook specifies.
Spatial API: The same structured data contracts: trajectories, events, zone activations, spatial context. Downstream consumers use the same endpoints regardless of what the cameras are observing.
Operational model: The same 24/7 NOC monitoring, the same deployment tooling, the same SLO framework, the same recovery procedures. Operations scale with fleet size, not with vertical count.
What changes#
Playbooks: Zone definitions change; a football pitch has different zones than a logistics corridor or a transit hub. Priority schemas change; tracking a striker is different from tracking a suspicious package. Capture policies change; broadcast close-ups have different framing rules than security surveillance.
Models: Some verticals need additional detection models. Sports needs player identification and ball tracking. Security needs anomaly detection and crowd density estimation. Robotics needs obstacle mapping and path prediction. These are model configuration changes within the same inference pipeline.
Governance rules: Different verticals have different data retention requirements, access controls, and compliance obligations. The governance framework is the same; the rules are configured per deployment.
The economics of platform generality#
When a product company enters a new vertical, the cost is roughly proportional to building a new product: new engineering, new QA, new support, new documentation.
When a platform company enters a new vertical, the cost is:
- Write new playbooks
- Train or configure detection models for the domain
- Adapt governance rules
- Deploy the same hardware with the new configuration
No new hardware design. No new runtime. No new API. No new operational model. The marginal cost of a new vertical is a fraction of the first vertical.
Each new vertical OZ enters reuses the full stack: same hardware, same runtime, same API. The R&D investment in the platform serves every vertical simultaneously.
Why sports had to come first#
This platform generality only works because the platform was proven in the hardest environment first. Sports demands the highest performance across every dimension: speed, latency, accuracy, concurrency, and reliability.
If OZ had started with CCTV (slower subjects, longer latency budgets, lower resolution requirements), the platform might not have been built to handle sports. By starting with sports, the platform is overqualified for every subsequent vertical.
Every new vertical OZ enters is easier than sports along at least three dimensions. The platform doesn't need to be re-engineered. It needs to be reconfigured.
The platform flywheel across verticals#
Each vertical contributes back to the platform:
- Sports contributes motion models and tracking accuracy
- CCTV contributes anomaly detection and crowd density patterns
- Robotics contributes spatial mapping and path prediction
- Defense contributes threat classification and perimeter models
These improvements flow back into the shared platform. A detection model refined for security improves anomaly detection in sports. A tracking algorithm refined for sports improves motion prediction for robotics.
The more verticals the platform serves, the richer the model library, the better the playbooks, and the more capable every deployment becomes, regardless of vertical. This is the compounding advantage of platform generality.