[{"data":1,"prerenderedAt":34},["ShallowReactive",2],{"arch-deep-/architecture/flows/notification":3},{"id":4,"title":5,"body":6,"category":23,"deepPage":24,"description":25,"extension":26,"layer":27,"meta":28,"navigation":29,"path":24,"relatedFlows":30,"replaces":30,"seo":31,"stem":32,"__hash__":33},"architecture/architecture/flows/notification.md","Notification logic",{"type":7,"value":8,"toc":19},"minimark",[9,13,16],[10,11,12],"p",{},"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.",[10,14,15],{},"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.",[10,17,18],{},"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.",{"title":20,"searchDepth":21,"depth":21,"links":22},"",2,[],"flow","/architecture/flows/notification","How the operating layer decides what to send, to whom, through which channel, and when.","md","2",{},true,null,{"title":5,"description":25},"architecture/flows/notification","XIDMKwGXsS6ixU7sWy9ha0DQAG6Uy0xBz52dOZ1K1To",1779718756836]