Layer 2 · flow

Notification logic

How the operating layer decides what to send, to whom, through which channel, and when.

Back to architecture

Notification is not a feature that fires every time something happens. It is a workflow with rules — a behavioral question about when the building should reach a resident, what it should say, which channel is appropriate, and what the consequence should be if the message is not acknowledged.

The notification engine consumes events from across the operating layer — booking confirmations, access alerts, delivery handoffs, maintenance updates, building-wide communications — and evaluates each event against the resident's preferences, the channel reliability profile, the urgency tier, and the quiet-hours policy. The same event can resolve into a push notification at one hour and a delayed email summary at another, depending on the rules.

Channel choice is not the resident's responsibility. Residents declare preferences and quiet hours; the engine selects the channel that best matches the event's urgency and reliability requirement. Critical safety notifications override quiet hours and use multi-channel fan-out. Routine updates batch and digest. Acknowledgement is tracked end-to-end, so the behavioral standard can score whether residents are reliably reached when reaching them matters.