The operating layer does not replace every system in the building. It wraps the systems the building already runs — access hardware, property management, payments, accounting — and orchestrates them through a single behavioral specification. Each integration absorbs the vendor's data model into the operating layer, normalizes it against the standard, and surfaces a consistent experience to residents and staff.

Integrations are categorized by the role they play in the building. Access control connects to the orchestration engine and inherits the permissions model. Property management wraps lease, ledger, and unit-state data. Payments routes resident charges through the payment wrapper. Accounting synchronizes financial events into the building's books. The behavioral specification is the same regardless of which vendor sits behind it; the integration is the seam that makes vendor swaps possible without renegotiating the standard.

Integration approach

Each integration declares its capabilities, its data model, and its failure modes against the operating layer's contract. Where a vendor exposes a stable API, the operating layer consumes it directly. Where the vendor exposes only a portal, the integration is built against the documented data export and a scoped service account. Critical paths — access decisions, payment authorization — execute through the edge gateway when connectivity to the vendor cloud is intermittent.

No integration is exclusive. The orchestration engine is designed so the building can swap one access vendor for another, or one PMS for another, without rewriting the behavioral specification or breaking the resident experience. The vendor directory below lists the integrations currently shipped or available on request.