The permissions engine answers a single question, evaluated millions of times across the building's lifetime: is this principal allowed to do this thing in this place at this moment. The principal can be a resident, a guest, a staff member, a contractor, a service technician, or another system. The thing can be opening a door, booking an amenity, raising an issue, retrieving a delivery, or invoking an internal workflow. The model is one model — there is no parallel matrix per vendor, per amenity, or per floor.

Permissions are declarative and time-bound. Each grant carries a scope (which spaces, which actions), a window (when it is valid), and an origin (who issued it and on what authority). The engine evaluates grants in real time, including transitive grants — a guest invited by a resident inherits the resident's spatial scope minus a defined exclusion list, with a window the resident cannot extend beyond the policy ceiling.

The permissions engine is the single source of truth that the access orchestration engine, the booking engine, the issue engine, and the staff console all consult before acting. When a building swaps an access vendor or a property management system, permissions are not migrated — the engine continues to hold the truth, and the new vendor consumes it through the integration layer.