Security for property means property_id is the primary key, not camera_id. Every alert, every report, every export is scoped to one building.

Hardware bundles and service hours. ADT and Vivint and SimpliSafe list camera kits, sensor kits, and monthly monitoring. Brinks and Alert360 list equipment tiers. Allied Universal and Securitas list guard hours. Forbes and Safewise rank those products against each other. Every result is a list of things that plug into a property, with the property itself treated as the shipping address and the billing row. None of them describe how the system groups incidents per property, routes an alert to the right person per property, or emits an exportable monthly record scoped to a single property. The property is a tag on a cart line item. It is not the primary key.

It means every record the system produces has a property_id column that is never null, never a default, never inferred from a camera, and never a shipping-address afterthought. Alerts are routed by property_id, not by camera_id, so a 3am tailgating event at Oak Ridge Apts Building C pages the on-call for Oak Ridge, not the oncall for Pine Hill across town. Incident rollups are grouped by property_id, so Building C's monthly report shows only Building C's events. Quiet hours are configured per property_id because the mailroom in one building opens at 6am and the mailroom in another opens at 8am. Exports are generated per property_id because an insurer for Building C wants exactly one PDF, not a portfolio dump filtered by metadata.

In one file on the unit itself. /var/lib/cyrano/provisioning/status.json is written by the on-device captive portal the first time the maintenance tech submits the bind form on their phone. The JSON object has a property_label field (for example 'Oak Ridge Apts, Bldg C'), a device_id, an account_email, a bound_at_unix timestamp, and the WiFi config. That file lives on real disk (not tmpfs) so a reboot mid-install resumes in place. Every downstream event the unit emits carries the property_label from that file as a header. The cloud side never asks the box 'what property are you' because the box knows.

Four that matter for operations. First, the alert router: when a tailgating or loitering event fires, the router looks up property_label to find the on-call schedule, the preferred notification channel (SMS, voice, dashboard toast), and the escalation chain specific to that property. Second, the incident rollup job: nightly it GROUP BY property_id to produce per-property counts, per-property trend lines, and per-property heatmaps. Third, the quiet-hours engine: it applies the schedule keyed to property_id so Building C's garage is not alarm-muted when Building A's garage is. Fourth, the monthly export pipeline: it generates one PDF per property_id with the property_label in the filename and in the header block.

Because the property is the smallest unit that owns its own risk, its own insurance policy, its own lease contracts, and its own on-call rotation. Splitting below that level (one unit per building within a property, one unit per wing) fragments the incident log across devices that no single report can reconcile. Sharing above that level (one unit for a portfolio) means every per-property configuration (quiet hours, alert routing, notification channel, retention policy) has to be encoded into tags that the product cannot enforce at the process boundary. The unit scoped to one property exactly matches the scope at which an owner or asset manager thinks about security. It keeps the data model honest.

The dashboard is a list of properties, one row per property, each row backed by exactly one Cyrano unit. Click a row and the drill-down is scoped to that property: the cameras on that property, the incidents at that property, the monthly incident trend for that property, the last export for that property, and the alert recipients for that property. Nothing at the portfolio level holds raw events; raw events live on-device at the property. The portfolio view is aggregations, one row per property_id, and the aggregations are GROUP BY the same property_label that was written into status.json at bind time.

Because the thing an owner is actually buying is coverage for a property, not utility for a camera. A property with 6 cameras and a property with 24 cameras both have one mailroom, one lobby, one parking lot, one after-hours on-call. The risk profile is property-scoped. When security is priced per camera, a property manager is discouraged from adding the twelfth camera that would close the garage blind spot, because the twelfth camera is another $150 per month. When security is priced per property, that same garage blind spot gets closed for free, because the new camera just shows up as another tile in the same inference pipeline on the same unit. The same dynamic applies to reporting, alert recipients, and export obligations: they are all property-scoped, so the pricing should be too.

One PDF per property, named with the property_label and the month (for example 'oak-ridge-bldg-c-2026-04.pdf'). The header block shows the property_label, the property address, the device_id of the unit installed there, the month, and the count of incidents. The body is a chronological list of incident cards, each with a thumbnail, the AI classification (loitering, tailgating, package removal, vehicle entry outside hours), the tile camera the event came from, the timestamp local to the property, and the resolution note from the on-call. The rollup section has per-incident-type totals and the week-over-week delta. The cover page is built from exactly the fields in status.json and the aggregation tables keyed on property_id.

Two fields in status.json get rewritten: account_email and (if the property trades names) property_label. The device_id does not move; the Cyrano unit stays bolted to the shelf. The history of incidents stays attached to the property_id, so the new owner inherits a month of baseline data on day one and can see trend lines starting before they closed. The old owner's dashboard row disappears from their portfolio view when account_email flips. The bound_at_unix timestamp records when the rebind happened, so an auditor can draw a clean before/after line across a sale or a management change.

Forty rows on the portfolio dashboard. Forty Cyrano units on forty shelves, one per property. Forty /var/lib/cyrano/provisioning/status.json files, each with a different property_label. Forty on-call rotations, forty quiet-hours schedules, forty monthly PDFs each month. The regional manager sees all forty rows at once with incident counts, change versus last month, and the unit's live boot_phase; clicking any row drills into that property's specific feed and leaves the other 39 untouched. No cross-property mixing in the data path, no shared camera_ids across properties, no ambiguous alerts. The schema matches the org chart.