RFC one-pager, Lock Management Area

LMA in PMS

Smart locks are property infrastructure. Reservations are booking context. The RFC says: keep lock management inside PMS, and let RMS provide reservation context only when lock operations need it.

Greatest callout Move smart locks from Legacy/Nuki-specific flows into a PMS-owned lock registry with provider adapters.
Owner
Nam
Status
Draft v2
Boundary
Inside PMS
First providers
Nuki, Akiles

What changes?

Fragmented locks to PMS registry

Today: lock truth is scattered

Legacy owns most behavior, Nuki IDs leak into the model, Hostaway custom fields map locks indirectly, and PMS mostly has guest-facing access instructions.

  • 1Legacy smartlock tables and jobs are still the operational source.
  • 2PMS cannot reliably answer status, battery, provider, code, or assignment questions.
  • 3Adding Akiles would create another one-off integration unless we define a provider-neutral layer.

Future: PMS owns the lock layer

LMA becomes a PMS module with a stable internal SmartLock ID, provider mappings, capability-aware adapters, and Nexus-facing APIs.

  • ✓sml-* is the Arbio lock identity.
  • ✓(provider, externalId) keeps Nuki, Akiles, and future providers separate.
  • ✓accessInfo can reference locks, but it remains guest-facing instructions.
Consumers
Nexus, internal tools, RMS when needed
Everything talks through PMS APIs instead of Legacy lock endpoints.
→
PMS boundary
LMA module inside PMS
SmartLock registry, lock operations, status, capabilities, and provider metadata.
→
Providers
Nuki, Akiles, future adapters
Each provider can differ. PMS exposes explicit capabilities instead of assuming parity.
🔑

SmartLock registry

One PMS entity for known locks, with internal sml-* IDs, provider, external ID, name, status, battery, capabilities, and metadata.

🏠

No assignment table in v1

Use PMS target IDs and accessInfo.checkInSteps references first. Add assignment history later only if real requirements need it.

🧩

Adapter capability model

Nuki and Akiles do not behave identically. The abstraction should expose what each provider can actually do.

🛡️

Codes need security gates

Raw code persistence is not automatic. Decide encryption, masking, permissions, audit, and retention before exposing codes.

Boundary split

PMS

Owns smart locks, provider metadata, provider adapters, lock operations, and PMS target references.

RMS

Owns reservations and lifecycle data. PMS asks RMS for reservation context when creating reservation-related lock operations.

AccessInfo

Stays guest-facing. It describes the check-in path and can reference smartLockResourceId.

Code types are not one thing

Guest

Reservation codes are temporary, tied to a stay window, and need RMS context.

Ops

Permanent, master, or fallback codes are operational and tied more naturally to locks, units, or properties.

Caution

Akiles may return PINs only once, which can force a storage decision. Do not hide that behind a generic code model.

Important nuance

This is not a separate LMA service for v1. It is a PMS-internal lock-management area. The separate-service abstraction may be tempting, but the RFC's decision direction is to keep lock management close to PMS property structures and access data.

Success means the team agrees on

  • ✓LMA lives inside PMS for v1.
  • ✓PMS gets a dedicated SmartLock entity with internal Arbio IDs.
  • ✓Provider IDs are stored as (provider, externalId).
  • ✓No dedicated assignment table unless investigation proves it is needed.
  • ✓Legacy lock APIs and jobs can be deprecated after PMS LMA reaches parity.

Open questions

  • !Which Legacy job creates reservation codes, and what is the exact timing and retry behavior?
  • !Do Nuki and Akiles support the same validity windows, activity logs, and remote unlock flows?
  • !Who can view raw codes or trigger remote unlock?
  • !What is Nexus v1 scope: read-only status, codes, remote unlock, or backend migration only?
Recommendation: start with PMS SmartLock registry, provider adapter abstraction, Nuki migration, and smartLockResourceId references in check-in data. Keep raw code exposure and remote unlock behind explicit security, audit, and retention decisions.