ArcFlow
Company
Managed Services
Markets
  • News
  • LOG IN
  • GET STARTED

OZ brings Visual Intelligence to physical venues, a managed edge layer that lets real-world environments see, understand, and act in real time.

Talk to us

ArcFlow

  • World Models
  • Sensors

Managed Services

  • OZ VI Venue 1
  • Case Studies

Markets

  • Sports
  • Broadcasting
  • Robotics

Company

  • About
  • Technology
  • Careers
  • Contact

Ready to see it live?

Talk to the OZ team about deploying at your venues, from a single pilot match to a full regional rollout.

Schedule a deployment review

© 2026 OZ. All rights reserved.

LinkedIn
  1. Home
  2. Blog
  3. Twelve Venues, Four Months: Why Deployment Starts in Software

Twelve Venues, Four Months: Why Deployment Starts in Software

Article January 14, 2026

Share this post

A federation manager once asked Sunil Kashyap how many people he would need to plan fifty venues. The answer surprised her: the same team that planned the first five. Not because those people work harder, but because the playbook, not the person, is the unit of scale. In OZ Designer, the scene planning tool where every deployment begins, a venue template refined by nine previous installations carries forward to the tenth. Capture policies validated in ghost-mode simulation transfer between stadiums. A director's production style, encoded as rules-as-data, executes consistently at every ground in the fleet. The result: a Nordic federation deploying across twelve venues in four months starts not with an engineer walking a gantry, but with a laptop running a simulation of matches that have not happened yet.

Why Deployment Starts in Software#

"Every deployment risk that matters can be identified before hardware ships," Sunil says. "Sight line obstructions. Mounting surface limitations. Coverage gaps between camera positions. Zone overlaps that create ambiguous AI decisions. All of these are spatial problems, and spatial problems can be solved in a spatial planning tool."

OZ Designer is that tool. It is where the deployment team builds a digital scene model of each venue (the pitch dimensions, the stand geometry, the gantry positions, the lighting rig locations, the cable routing paths) and then designs the capture strategy within that model.

The workflow has four phases, each designed to eliminate the variance that makes traditional multi-venue deployments unpredictable.

Phase One: The Venue Template#

The deployment team begins with a venue template. OZ Designer ships with templates for standard venue configurations: football pitches with four-stand layouts, single-stand community grounds, indoor arenas, athletics tracks with infields. The template provides the baseline geometry. The team adjusts dimensions, stand heights, and structural details to match the specific venue from architectural drawings and survey photographs.

"The template is not a rough sketch," Sunil explains. "It is a calibrated 3D environment model. Camera fields of view are calculated against the actual geometry. Sight lines are computed, not estimated. When the team places a camera position in the model, OZ Designer shows exactly what that camera will see, including blind spots, overlap zones with adjacent cameras, and areas where the optical zoom cannot reach sufficient detail."

For a federation deploying across twelve venues, this changes the entire planning cadence. Five or six venues may share a similar template with site-specific adjustments. The standard decisions (how many cameras, where the primary wide shot lives, where the close-up gimbals point) are made once and carried forward. Each venue plan inherits the template intelligence and only requires adaptation for its unique structural characteristics.

For league managers planning multi-venue rollouts: the venue template system means your deployment team does not redesign from scratch at every venue. Standard configurations carry forward. Site-specific adjustments take hours, not weeks. A twelve-venue deployment planned in OZ Designer takes a fraction of the time that twelve independent venue surveys would require.

Phase Two: Zones and Capture Policies#

Once the venue geometry is modeled, the team defines zones, spatial regions that the AI uses to understand what is happening on the pitch and where to point cameras.

"Zones are the vocabulary of production intent," Sunil says. "The penalty area is a zone. The technical area is a zone. The tunnel entrance is a zone. Each zone carries a capture policy, a set of rules that tells the AI how to behave when specific conditions are met within that zone."

A capture policy might specify: when the ball enters the penalty area, prioritize the close-up gimbal on the player nearest to the ball. When a goal is scored, hold the wide shot for three seconds, then cut to the scorer. When play stops, show the tactical overview. These are not hard-coded behaviors; they are rules-as-data, defined in OZ Designer's visual policy editor and attached to specific zones.

"Production directors understand this immediately," Sunil says. "It is the same logic they carry in their heads during a live match: 'when X happens, I want to see Y.' The difference is that in OZ Designer, that logic is written down, version-controlled, and executable. The AI reads the playbook and executes the director's intent. The director does not need to make the same decisions four hundred times per match."

For a production director at Sky or ESPN, the implication is direct: the playbook encodes your production style. A director who prefers tight close-ups on ball carriers will define different capture policies than one who prefers wide tactical shots. Both are valid. Both are expressible. And once defined, the playbook executes consistently, at every match, at every venue, without the variance that comes from different camera operators interpreting the same brief differently.

Phase Three: Ghost Mode#

This is the phase that changes the risk profile of deployment entirely.

"Ghost mode runs your playbook against real match data in simulation," Sunil says. "You take recorded match footage and spatial tracking data from a previous match (it can be from the same venue or a different one with similar geometry), and OZ Designer simulates what your camera system would have done if it had been deployed with your current configuration."

The production team sees: which cameras would have been selected at each moment, how the AI would have framed each shot, where the close-up gimbals would have pointed, where the coverage gaps would have appeared, and where the zone boundaries would have created ambiguous decisions.

"Ghost mode is where playbooks get refined," Sunil explains. "A director watches the simulated production and says, 'I would not have cut there.' Or, 'The close-up should have held longer on the ball carrier.' Or, 'There is a dead zone between camera three and camera four when play moves to the far side.' Every one of those observations becomes a playbook adjustment. And every adjustment is tested against the same match data, immediately, without waiting for a live match."

For production professionals accustomed to learning by doing, refining camera positions across a full season of live matches, ghost mode compresses the learning cycle from months to hours. The playbook that goes live at the first match of the season has already been tested against dozens of simulated matches. The deployment team arrives at the venue with a validated configuration, not a hypothesis.

Sunil Kashyap

Sunil Kashyap

Head of OZ Studio Tech Stack

Platform & Product

“Ghost mode compresses a season of learning into a single afternoon. The playbook that goes live has already been tested against dozens of simulated matches.”

Phase Four: Deployment Handoff#

The scene model is complete. The playbook is validated. The deployment team has a version-controlled, peer-reviewed specification for every camera position, every zone boundary, every capture policy, and every production rule.

"This specification pushes directly into the OZ VI Venue node as structured parameters," Sunil says. "There is no manual translation step. There is no engineer at the venue typing configuration values from a PDF into a terminal. The scene model in OZ Designer is the source of truth. The deployed node reads from it."

The installation team's job is to execute the physical specification: mount the camera pods at the positions defined in Designer, run the cables along the routes mapped in Designer, connect the compute node to the power and network infrastructure. The calibration process validates that the physical installation matches the digital specification: camera fields of view are checked against the model, mounting angles are confirmed, coverage is verified.

"Pass means pass," Sunil says, echoing Audur Erlingsdottir's operational principle. "The acceptance suite runs automatically. If the physical installation matches the scene model within calibration tolerances, the system proceeds to shadow mode. If it does not, the playbook blocks go-live until the discrepancy is resolved. There is no 'close enough.'"

Why This Matters for Scale#

For a league deploying OZ at twelve venues (or fifty, or a hundred), the scene planning workflow in OZ Designer is the mechanism that makes scale possible without proportional headcount growth.

"Your tenth venue does not start from zero," Sunil says. "It starts from a template refined by nine previous deployments. The zones you defined at venue one carry forward. The capture policies you validated in ghost mode transfer. The playbook logic that your best director crafted is available at every venue in the fleet."

This is the product-level expression of what Baldur Stefansson describes as the deployment flywheel: each venue improves the fleet. In OZ Designer, the flywheel is tangible: it's the growing library of venue templates, validated playbooks, and refined capture policies that make each subsequent deployment faster, more predictable, and lower risk.

"A federation manager once asked me how many people they would need to plan fifty venues," Sunil says. "The answer surprised them: the same team that planned the first five. Not because those people work harder. Because OZ Designer carries the knowledge. The playbook, not the person, is the unit of scale."


This interview is part of the OZ Interview Series, profiling the team building the world model for the physical world.

All InterviewsAll with SunilLearn more about OZ