The access orchestration engine sits between the experience layer and the building's access hardware. It makes one decision per access event, regardless of which vendor's lock or reader is involved on the other side.

Vendor-neutral decision surface. Door controllers, smart locks, and readers from different vendors expose different APIs, different credential models, different event formats. The orchestration engine wraps each vendor through the integration layer and presents a single decision interface to Layer 3. The resident app, the staff console, and the workflows above do not know whether a given door is a SALTO Nebula, a Dormakaba Lyazon, or something else — they just know whether access was permitted.

Credential coordination. A resident has one identity. That identity may carry multiple credentials — a mobile pass for the lobby, a fob for the back-of-house corridor, a PIN for a service entrance. The orchestration engine tracks which credentials map to which vendor systems and ensures provisioning, revocation, and replacement are consistent across all of them.

Decision composition. Every access request runs through the rules engine and the permissions engine before the orchestration layer issues a hardware command. Identity, time window, escort rules, building state, and zone-specific overrides compose into a single permit/deny decision. The decision is logged before the hardware is actuated.

Failure modes. If a vendor API is unreachable, the edge gateway holds the cached decision set and continues to operate against locally stored permissions. The orchestration engine reconciles state when the link returns.

For the building, this means access can be added, modified, or replaced as a vendor without re-architecting the operating layer above it.