[{"data":1,"prerenderedAt":34},["ShallowReactive",2],{"arch-deep-/architecture/flows/booking":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/booking.md","Booking flow",{"type":7,"value":8,"toc":19},"minimark",[9,13,16],[10,11,12],"p",{},"The booking flow runs every time a resident reserves an amenity — a gym slot, a coworking desk, a screening room, a rooftop reservation, a guest suite, an EV charger stall. The same flow handles every amenity in the building because the underlying behavior is the same: declare a window, evaluate eligibility, hold capacity, confirm, check in, release.",[10,14,15],{},"A resident initiates a request from the resident app. The booking engine evaluates the request against the rules engine — quiet hours, capacity, eligibility, advance window, deposit clearance — and either holds the slot, suggests an alternative, or denies the request with a clear reason. The hold is transactional: capacity does not double-book even under contention.",[10,17,18],{},"Confirmation is acknowledged through the resident's preferred channel and persisted in the operating layer's record. At check-in, the booking engine accepts evidence of arrival from the access orchestration engine, a staff acknowledgement, or a resident-confirmed arrival. Unclaimed slots release automatically after a grace period, returning capacity to the pool. Every step is logged against the behavioral specification, so cell-level scoring can determine whether the booking experience is meeting the standard.",{"title":20,"searchDepth":21,"depth":21,"links":22},"",2,[],"flow","/architecture/flows/booking","How residents reserve amenities — request, evaluation, hold, confirmation, check-in, release.","md","2",{},true,null,{"title":5,"description":25},"architecture/flows/booking","GF-lTXzFOf7JRYQVFxnSydr1BnSMTyOKq99feX-wxZA",1779718756836]