Introducing the OZ Changelog

Starting today, every production release across OZ ships with a public changelog entry.

This isn't a marketing blog repackaged as release notes. Every entry is tied to a specific product, version, and deployment. If it's listed here, it's running at a live venue.

Why we're doing this#

Most infrastructure companies talk about what they plan to build. We'd rather show what we already shipped.

OZ operates across the full stack: sealed enclosures, robotic gimbals, GPU edge compute, real-time inference, operator control planes, and a structured Spatial API. Changes ship at every layer, often in the same release cycle. A traditional changelog wouldn't capture the breadth. A blog wouldn't capture the discipline.

So we built something in between: a product-filtered timeline where each entry maps to a specific system, carries a version tag, and links to the technical context behind the change.

What development partners get#

If you're building on the Spatial API, integrating OZ into a broadcast workflow, or evaluating the platform for a venue deployment, the changelog gives you:

• Release cadence visibility: see how frequently each product ships, and what the trajectory looks like over quarters.
• Breaking change awareness: API contract changes, data schema updates, and deprecations are flagged explicitly.
• Feature context: each entry explains not just what changed but why it matters for downstream consumers.
• Version pinning: every entry carries a product tag and version, so you can cross-reference against your integration.

How we ship#

OZ runs a continuous deployment pipeline from hardware bring-up through API release. The team operates in 2-3 week cycles. Each cycle touches whichever layer of the stack needs it: sometimes that's firmware, sometimes the inference pipeline, sometimes the operator console.

The key constraint: every release is deployed and operating at live venues before it appears here. We don't changelog features that are in staging. If it's in the changelog, it's survived match-day conditions under broadcast SLOs.

This is possible because we own the full stack. There's no dependency chain to negotiate; hardware, firmware, runtime, control plane, and API are all ours. When a perception model improves, we can update the inference runtime, adjust the control plane, and extend the API schema in the same release cycle.

What this says about how we operate#

Publishing a changelog is a small thing. Maintaining the discipline behind it isn't.

Every entry here represents a release that was designed, implemented, tested against live venue telemetry, deployed to production hardware, validated under broadcast load, and documented, all within the same sprint. The changelog is the artifact. The execution system behind it is the asset.

We expect this cadence to compound. Each release builds on the last. The Spatial API gets richer because the perception pipeline gets sharper. The operator console gets better because the runtime exposes more telemetry. The deployment flywheel accelerates because every venue teaches the system something new.

Filter by product#

You can filter the changelog by product (PanoNode, VI Venue, Designer, Studio, or Spatial API) to see just the releases that matter to your integration. Use the category filter at the top of the changelog page.

We'll keep shipping. The changelog will keep growing. Watch this space.