YYZdata
Signals · venues, campuses, and multi-site operators

How fast can you get an answer out of your own systems?

Signals is an intelligence layer over the systems your operation already runs. Cameras, transactions, sensors and systems of record, read together on site, answering in plain language. In most large operations that answer takes days today, assembled by hand, from four systems that disagree with each other.

In deployment today, onboarding design partners
Ask the operation · five questions, answered from a deployment
Worked examples over an anonymized dataset. In your deployment you type your own question and it answers from your own database.
01 Who it is for

Where the money is actually sitting.

Our view, from building this.

Stadiums and arenas
Per-cap nobody can explain. The camera estate went in for security and has never been asked an operational question.
Colleges and campuses
Scheduled is not occupied. Utilization is reported from the timetable, and a bond case needs better than that.
Multi-site operators
A number with nothing behind it. Every question that crosses the floor and the register becomes a project.
Enterprise operations
Nine systems, two vendors. The answer exists. No layer above the systems of record is trusted enough to act on.
Stadiums, arenas, and large venues

You installed four hundred cameras and asked them nothing.

A modern ballpark runs four to five hundred non-game events a year through a building designed for eighty. The camera estate went in for security and has never been asked an operational question. Meanwhile per-cap is the number everyone reports and nobody can explain, because the queue at gate four and the register at stand twelve live in systems that have never met. Six minutes of line at the right moment costs more in per-cap than the labor saved by leaving the second stand closed. Nothing in the building measures that trade.
Queue depth by gateConcourse flowStand-level conversionPer-cap by zone and hourEgress and dwellNon-event day utilization
Colleges and campuses

The state grades your rooms on a standard written in 1966.

California measures community college classrooms against 53 hours a week between 8am and 10pm at 66 percent station occupancy. Those standards date to 1966. Districts report against them from the timetable, which records what was scheduled, not what was occupied. When a district is carrying a nine-figure capital and deferred maintenance need and heading toward a bond, the difference between scheduled and actual is not a facilities metric. It is the evidence base for the ask.
Actual vs scheduled occupancyStation occupancy by roomEvening utilizationSpace inventory supportAfter-hours energySafety awareness
Multi-site operators

Head office gets a number. Nobody can get behind it.

Twenty sites, one dashboard, and no way to ask why site eleven is down without three people and a week. The floor data and the transaction data are in different vendors, so every question that crosses them becomes a project. Shrink, staffing, and spoilage all live in that gap, and they are small enough per site that nobody chases them and large enough across the estate that they matter.
Site-to-site benchmarkingFloor vs register varianceStaffing against measured trafficSpoilage and expiryQueue and walkoutEquipment and energy
Enterprise operations and finance

The answer exists. It is spread across nine systems and two vendors.

Large organizations do not lack data, they lack the ability to ask one question that crosses domains. The blocker is rarely the model. It is that no layer sits above the systems of record and is trusted enough to act on. We wrap, we do not replace. Nothing gets migrated, nothing gets switched off, and the answers land in storage you control.
Cross-system reconciliationOperational reportingException detectionPlain-language queryingAudit-ready lineageOn-premise processing
02 What it reads

Three streams, one picture.

Every operation already produces all three. Almost nobody reads them against each other, which is why the queue never shows up next to the register and the empty room never shows up next to the timetable.

Vision
Occupancy, flow, queue depth, dwell, zone state, and safety awareness, from the cameras you already operate. Read over RTSP and ONVIF, or off the recorder you already run.
Sensors and the physical plant
Doors, temperature, energy, HVAC, equipment state. The building joins the same picture, with video as the cross-check that catches a sensor when it is wrong, late, or silent.
Systems of record
Point of sale, inventory, ticketing and access control, scheduling and timetables, labor, work orders, finance. Read-only, by API where the vendor allows it, and by ingesting the reports the system already emails you where it does not.
RTSP / ONVIF camerasExisting NVR / DVRAnalog behind an encoderPOS and inventory APIsScheduled report ingestAccess controlReservations and ticketingLabor and schedulingWebhooksCSV drop folder

Named connectors are confirmed during the survey against your actual estate, rather than listed here as logos we have not tested on your floor.

03 How it lands

Survey, appliance, your rules, answers.

No construction and no closures. Where a camera genuinely cannot serve, we name it in the survey rather than letting it miscount in production.

1 · The survey
A review of your cameras and systems that names every readable signal in your estate, and grades every camera on angle, lighting, and occlusion before anything ships. Concrete, and yours to keep either way.
2 · The appliance
Preconfigured from your survey and installed in a day. Processing is local by default.
3 · Your rules
Your definitions of normal, your thresholds, your chain of command. Every signal carries a precision floor; one that cannot hold it in your building reports as a count you can inspect until it earns the right to alert.
4 · Answers
Plain-language answers and alerts before the loss, with a manual override on every action path. Every output lands in storage you control.
Measured, not promised

An example, running today.

A licensed hospitality venue, eight camera positions, read as they were. In the first sixty days: expiring inventory surfaced that nobody was tracking, in time to be sold rather than written off; storefront software on its way off the monthly bill; peak-hour traffic measured for the first time. One finding reached inventory, revenue, and the reporting record at the same time, which is the whole point of reading the systems together.

The example, one page, PDF
VenueLicensed hospitality, single site
Cameras8 positions, read as they were
Installone day
First 60 days3 findings, 1 software line retired
Design partners

We are taking on a small number of partners.

A venue, a campus, or a multi-site operator willing to put Signals on a real floor and tell us what is wrong with it. In return you get the survey, a named engineer, and direct influence over what gets built next. We are looking for operations with a question they cannot answer today and the appetite to be early.

The position

Own and access your data.

Ownership is the half everybody claims in the contract. Access is the half that bites. Vendors meter the API to your own numbers, tier your own reports, and charge you to export what your business produced. Signals inverts it: the platform computes in your building and pushes every result into storage you control, in standard formats. No export fees and no data tiers. Your deployment learns from your floor. If YYZdata disappeared tomorrow, everything your operation produced would still be sitting in the building that produced it, and you would still be able to read it.

Research

What we have been looking into.

Short pieces on where operational data goes missing, and what it costs. Free, no form.

The first step

Tell us what you run.

The survey names, concretely, which of your cameras and systems Signals can read and which questions it could answer on your floor. You keep it either way.