Facility admins ran a campus through five vendor consoles — each with its own model of who's allowed where. The brief: one configuration surface, audit-grade, without removing depth.

Identity, health, policy — in that order

The selected building (HQ North) is rendered as a record, not a landing page. A compact identity row anchors the screen — name, code, status pill, address — then a KPI strip (floors, sq ft, capacity, occupancy) frames the building at a glance.

System Health appears before Building Policy: the admin's first question — "is anything broken?" — is answered before they face decisions. The building dropdown carries each campus's state inline so swapping buildings never hides a warning, even before selection.

Status on the card, depth behind Configure

Every controllable thing in the building — a conference centre, an elevator bank, an HVAC zone — surfaces as the same card. Operational, Restricted, and Maintenance render on the card face, so a routine status audit is a scroll, not a series of opens.

The five-filter bar shows live counts inline — a lightweight inventory check (HVAC shows 3 but you expected 4? something's missing). Type-specific depth (HVAC temperature limits, elevator priority modes, sanitation hazardous flags) stays exactly one click away, behind Configure →.

Profile as a record. Match count as trust signal.

Seven access profiles — Executive, Employees, Engineering, Security, Facilities, Cleaning, Visitors — each rendered as a compact identity row: 10×10 colour swatch, name, priority chip, one-line description. No editorial framing, no big swatch blocks — dense identity, zero overhead.

The hardest detail to get right: the match count. Each profile shows the live number of occupants whose current tags resolve to its rules. Zero matches is a silent failure — either locking everyone out or granting access to nobody — so the count had to be the first thing an admin sees, glance-readable without opening anything.

Two views, one rule object

The matrix flips Access Profiles on its side: rows are facility systems, columns are profiles, cells are the access state. A coverage strip across the top counts Always / Hours / Conditional / Deny across the entire building — over-restriction or over-permission shows up before the admin scrolls to any cell.

Click any cell: an inline picker with four options appears. Hours opens the schedule editor anchored to that exact cell — pick days and a time window without leaving the matrix. An edit here is the same edit in Access Profiles — one rule object, two render surfaces. No duplicate state to manage, no sync to break.

Five vendor models, one matrix

HVAC controllers expose temperature limits and occupancy modes. Elevators expose floor-access and after-hours rules. Sanitation has hazardous-flag and safety-lock semantics. The brief was to design one mental model a facility admin can hold — without losing the per-system depth.

Permissions that aren't binary

"Access" isn't allow/deny in a real building. A cleaning crew needs hours-only. A security lead needs conditional on incident. The matrix had to express four modes without becoming a colour-coded spreadsheet.

Multi-building cognitive load

A campus operator manages four+ buildings with different policies. The console has to make "you are configuring HQ North" structurally obvious — and the building dropdown has to carry each campus's state so swapping never hides a warning.

Audit-grade legibility

SSH's market is regulated enterprise. Every config change must be defensible at audit. The visual language couldn't hide state behind hover or animation; the resting view had to be a complete answer.