[{"data":1,"prerenderedAt":1037},["ShallowReactive",2],{"arch-details":3,"faq-architecture":986},[4,61,109,157,182,235,262,289,314,339,396,418,440,495,517,539,562,610,632,679,701,723,768,790,812,834,896,918,959],{"id":5,"title":6,"body":7,"category":46,"deepPage":47,"description":48,"extension":49,"layer":50,"meta":51,"navigation":52,"path":47,"relatedFlows":53,"replaces":57,"seo":58,"stem":59,"__hash__":60},"architecture/architecture/edge-gateway.md","Edge gateway",{"type":8,"value":9,"toc":42},"minimark",[10,14,21,27,33,39],[11,12,13],"p",{},"The edge gateway is a dedicated on-site runtime installed alongside the building's network infrastructure. It carries a copy of the behavioral specification, the workflow definitions, the permissions model, and a recent snapshot of resident and guest identity. Its purpose is narrow and specific: keep the building behaving correctly when the link to the cloud drops.",[11,15,16,20],{},[17,18,19],"strong",{},"What continues locally during an outage."," Access decisions execute against the local permissions model. Door controllers, locks, and readers receive the same orchestrated decisions they would receive online. Critical notifications fire through any channel that does not depend on the cloud — the intercom system, on-site staff radios, and unit-side panels. Resident apps fall back to cached state with a clear offline indicator.",[11,22,23,26],{},[17,24,25],{},"What pauses."," Cross-building portfolio operations pause. Delayed-channel notifications (email, batched summaries) queue locally. Long-running workflows continue from their last persisted step when the link returns.",[11,28,29,32],{},[17,30,31],{},"Reconciliation."," When connectivity returns, the gateway and cloud reconcile state through versioned event logs. Conflicts that are not auto-resolvable are surfaced to staff for review before they affect the resident experience. The gateway never silently reverts a decision that has already been communicated.",[11,34,35,38],{},[17,36,37],{},"Hardware footprint."," A small fanless server in the building's IT closet, sized for the building. Network segmentation isolates it from resident-facing systems. Owner-supplied and owner-replaceable.",[11,40,41],{},"The edge gateway is the reason the operating layer can be called infrastructure rather than software-as-a-service. Residents do not experience the cloud — they experience the building. The gateway makes that contract enforceable.",{"title":43,"searchDepth":44,"depth":44,"links":45},"",2,[],"hardware","/architecture/edge-gateway","The on-site Apareé runtime that keeps the building operating during connectivity loss.","md","5",{},true,[54,55,56],"access","issue","delivery",null,{"title":6,"description":48},"architecture/edge-gateway","AGvmKnfg5va3DDBnkhOEerAgxNtOyL1EDpXR4PiutRo",{"id":62,"title":63,"body":64,"category":98,"deepPage":99,"description":100,"extension":49,"layer":101,"meta":102,"navigation":52,"path":99,"relatedFlows":103,"replaces":104,"seo":106,"stem":107,"__hash__":108},"architecture/architecture/engines/access-orchestration.md","Access orchestration engine",{"type":8,"value":65,"toc":96},[66,69,75,81,87,93],[11,67,68],{},"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.",[11,70,71,74],{},[17,72,73],{},"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.",[11,76,77,80],{},[17,78,79],{},"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.",[11,82,83,86],{},[17,84,85],{},"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.",[11,88,89,92],{},[17,90,91],{},"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.",[11,94,95],{},"For the building, this means access can be added, modified, or replaced as a vendor without re-architecting the operating layer above it.",{"title":43,"searchDepth":44,"depth":44,"links":97},[],"engine","/architecture/engines/access-orchestration","Coordinates access decisions across hardware vendors, credential types, and rules.","4",{},[54],[105],"vendor-specific-access-management-consoles",{"title":63,"description":100},"architecture/engines/access-orchestration","2gBUbv66udtHo8F6euWyOATQMCLFsBC-5pk74PrlP_s",{"id":110,"title":111,"body":112,"category":98,"deepPage":146,"description":147,"extension":49,"layer":101,"meta":148,"navigation":52,"path":146,"relatedFlows":149,"replaces":151,"seo":154,"stem":155,"__hash__":156},"architecture/architecture/engines/booking-engine.md","Booking engine",{"type":8,"value":113,"toc":144},[114,117,123,129,135,141],[11,115,116],{},"The booking engine manages reservations for every amenity the building offers — gym slots, coworking desks, screening rooms, rooftop bookings, guest suites, EV charger stalls. It is a single capacity model shared across the building, not a collection of per-amenity sign-up sheets.",[11,118,119,122],{},[17,120,121],{},"Capacity model."," Each amenity declares its capacity profile: total slots, slot duration, lead time, advance window, deposit requirements, eligibility rules. The engine tracks live availability and prevents double-booking through transactional reservation writes.",[11,124,125,128],{},[17,126,127],{},"Rule evaluation."," Every booking request runs through the rules engine before the slot is held. Quiet hours, capacity limits, eligibility (resident vs. guest), advance window, and deposit clearance are checked declaratively. Rules are versioned with the behavioral specification — most rule changes do not require a code release.",[11,130,131,134],{},[17,132,133],{},"Lifecycle."," Hold → confirm → check-in → release. The check-in step is opportunistic: it accepts an access event from the orchestration engine, a staff acknowledgement, or a resident-confirmed arrival. Unclaimed slots release automatically after a grace period, returning capacity to the pool.",[11,136,137,140],{},[17,138,139],{},"Why not the PMS."," Property management systems treat amenities as line items on a charge ledger. They do not model rolling capacity, contextual eligibility, or behavioral rules. The booking engine wraps the PMS for billing handoff while owning the resident-facing experience and the operational logic.",[11,142,143],{},"For the resident, the experience is one app, one place to book everything in the building, with consistent rules and reliable confirmations.",{"title":43,"searchDepth":44,"depth":44,"links":145},[],"/architecture/engines/booking-engine","Manages amenity reservations, capacity, rules, and no-show handling across the building.",{},[150],"booking",[152,153],"pms-booking-modules","per-amenity-vendor-portals",{"title":111,"description":147},"architecture/engines/booking-engine","i8uZocGZssOT9Qyr28tLmgbexxngrc0sWIy1l-aTiQ0",{"id":158,"title":159,"body":160,"category":98,"deepPage":173,"description":174,"extension":49,"layer":101,"meta":175,"navigation":52,"path":173,"relatedFlows":57,"replaces":176,"seo":179,"stem":180,"__hash__":181},"architecture/architecture/engines/identity.md","Identity engine",{"type":8,"value":161,"toc":171},[162,165,168],[11,163,164],{},"The identity engine holds the canonical record of every person the building interacts with. There is one representation of a resident — not one in the access system, one in the property management system, one in the resident app, and one on a clipboard at the front desk. The same is true for staff, contractors, and recurring guests. Identity reconciliation is not an end-of-quarter cleanup task; it is the engine's continuous job.",[11,166,167],{},"Authentication is multi-modal. Residents prove identity through the resident app's device-bound credential; guests through a scoped, time-bound link; staff through the building's identity provider; contractors through service-account credentials issued against an active work order. The engine evaluates the strength of the proof against the action being requested — opening the lobby door requires less assurance than authorizing a withdrawal from the building's operations account.",[11,169,170],{},"The identity engine is what makes portability work. A resident who moves between buildings under the same operator carries their identity with them, with credentials that re-scope on arrival. A staff member promoted to a multi-building role inherits the access pattern her new role requires without manual provisioning. The engine is the single source the orchestration, permissions, and payment engines consult before acting.",{"title":43,"searchDepth":44,"depth":44,"links":172},[],"/architecture/engines/identity","The single representation of every person the building knows about — residents, guests, staff, contractors — and how they prove who they are.",{},[177,178],"duplicate-identity-records-across-vendors","manual-credential-issuance",{"title":159,"description":174},"architecture/engines/identity","L2GsrWuVrnVbPxS8gUc3zKldBvKtnQniAGe2ZwJwJ4Q",{"id":183,"title":184,"body":185,"category":98,"deepPage":225,"description":226,"extension":49,"layer":101,"meta":227,"navigation":52,"path":225,"relatedFlows":228,"replaces":229,"seo":232,"stem":233,"__hash__":234},"architecture/architecture/engines/issue-engine.md","Issue engine",{"type":8,"value":186,"toc":223},[187,190,196,202,208,214,220],[11,188,189],{},"The issue engine handles every maintenance, service, and operational request in the building. From a leaking faucet to a request for a replacement key fob to a noise complaint about a neighbor — the engine assigns each event a category, a priority, an owner, and a resolution path.",[11,191,192,195],{},[17,193,194],{},"Categorization."," Submissions arrive with a free-text description and optional photos. The engine classifies the request against the building's domain taxonomy (Access, Deliveries, Spaces, Support, Lifecycle, Environment) and assigns severity based on rules tied to safety, habitability, and resident impact.",[11,197,198,201],{},[17,199,200],{},"Routing."," Each category maps to one or more responders — on-site staff, contracted vendors, or third-party services. SLAs are attached at routing time; missed SLAs trigger escalation paths defined in the behavioral specification.",[11,203,204,207],{},[17,205,206],{},"Work tracking."," State transitions (acknowledged → in-progress → awaiting parts → resolved → closed) are versioned and visible to the resident at the right moments. Parts and vendor coordination are tracked alongside the work order so handover between teams is clean.",[11,209,210,213],{},[17,211,212],{},"Resident communication."," The notification engine handles the resident-facing updates. The issue engine produces structured events; tone and timing are decided by the notification rules. The resident sees a coherent thread, not a stream of system messages.",[11,215,216,219],{},[17,217,218],{},"Feedback capture."," A short, contextual survey fires when the work is closed. The signal feeds Layer 6 — both the building's own scoring and the cross-building intelligence corpus.",[11,221,222],{},"The engine replaces tenant-portal ticketing because tenant portals do not understand the building. The issue engine does.",{"title":43,"searchDepth":44,"depth":44,"links":224},[],"/architecture/engines/issue-engine","Manages maintenance and service requests end to end — categorization, routing, resolution, feedback.",{},[55],[230,231],"tenant-portal-ticketing","paper-work-orders",{"title":184,"description":226},"architecture/engines/issue-engine","Yea1HgkhNoEI56qsnSKU1F1-KWJXeqQHsMNNOt1bSy0",{"id":236,"title":237,"body":238,"category":98,"deepPage":251,"description":252,"extension":49,"layer":101,"meta":253,"navigation":52,"path":251,"relatedFlows":254,"replaces":256,"seo":259,"stem":260,"__hash__":261},"architecture/architecture/engines/notification.md","Notification engine",{"type":8,"value":239,"toc":249},[240,243,246],[11,241,242],{},"The notification engine is the engine behind the notification flow. It is the service that consumes events from across the operating layer and decides, for each event, what to send, to whom, on which channel, and when. It sits underneath every workflow that needs to reach a resident, a staff member, or a guest.",[11,244,245],{},"Routing decisions are made declaratively against the resident's preferences, the channel reliability profile, the urgency tier, and the quiet-hours policy. The engine knows that a critical safety message uses multi-channel fan-out and overrides quiet hours; a routine booking confirmation uses the resident's preferred channel and respects quiet hours; a delivery notification waits if the resident is in a do-not-disturb window for non-urgent traffic. The rules are versioned with the behavioral specification.",[11,247,248],{},"Acknowledgement is part of the engine's responsibility, not the consumer's. When a workflow asks the engine to notify a resident, the engine returns a handle that can be observed for delivery, read, and explicit acknowledgement. The behavioral specification can then score whether residents are reliably reached, and which channels are reliable for which event types in which buildings.",{"title":43,"searchDepth":44,"depth":44,"links":250},[],"/architecture/engines/notification","Routes outbound communication to the right resident, on the right channel, at the right urgency, against quiet-hours and acknowledgement policies.",{},[255],"notification",[257,258],"per-vendor-notification-stacks","sms-gateway-glue",{"title":237,"description":252},"architecture/engines/notification","dVg0k0Z4NddwcHKyiGIR2gUxpRYASnt-Rjrx92M03Ng",{"id":263,"title":264,"body":265,"category":98,"deepPage":278,"description":279,"extension":49,"layer":101,"meta":280,"navigation":52,"path":278,"relatedFlows":281,"replaces":283,"seo":286,"stem":287,"__hash__":288},"architecture/architecture/engines/onboarding.md","Onboarding engine",{"type":8,"value":266,"toc":276},[267,270,273],[11,268,269],{},"The onboarding engine is the engine behind the move-in flow. It receives a lease handoff from the property management system, builds the resident's identity through the identity engine, issues credentials through the permissions engine, schedules the welcome sequence through the notification engine, and persists every acknowledgement as evidence the building met its onboarding standard.",[11,271,272],{},"Move-in is treated as a multi-step workflow with defined response-time windows. The lease handoff arrives from the PMS and the engine has a specified window to provision the resident. Credentials are issued in a defined order — first scoped to the unit and shared spaces, then expanded as the resident acknowledges the welcome materials. Each touchpoint is logged so the behavioral specification can score whether the building's onboarding consistently meets the floor.",[11,274,275],{},"The engine is also the thing that makes the resident's first impression measurable. The standard does not say \"make residents feel welcome\"; it says specific testable things — the resident's app account is active before key handoff, the resident receives a named point of contact within a defined window, the resident's first issue raised within the move-in period is acknowledged within the standard's acknowledgement window. The onboarding engine is what turns those expectations into orchestrated work.",{"title":43,"searchDepth":44,"depth":44,"links":277},[],"/architecture/engines/onboarding","Drives the move-in workflow end to end — identity provisioning, credential issuance, welcome touchpoints, acknowledgement tracking.",{},[282],"move-in-out",[284,285],"front-desk-paper-checklists","fragmented-welcome-flows",{"title":264,"description":279},"architecture/engines/onboarding","3IkgO1Iop7ZI6HvEXsEK9gTh-foeohbkIkjqXSIajFk",{"id":290,"title":291,"body":292,"category":98,"deepPage":305,"description":306,"extension":49,"layer":101,"meta":307,"navigation":52,"path":305,"relatedFlows":57,"replaces":308,"seo":311,"stem":312,"__hash__":313},"architecture/architecture/engines/payment-wrapper.md","Payment & invoice wrapper",{"type":8,"value":293,"toc":303},[294,297,300],[11,295,296],{},"Money flows through buildings in many shapes — recurring rent, one-off charges, amenity fees, utility passthroughs, deposit holds, refunds, late fees, partial credits. Each of those shapes typically lives in a different vendor. The payment wrapper is the engine that lets the operating layer treat payment as a behavior of the building rather than a feature of a vendor.",[11,298,299],{},"The wrapper exposes a single set of operations — charge, hold, release, refund, reconcile — that the booking engine, the issue engine, and the move-in / move-out flow consume without knowing whether the underlying processor is Stripe, Adyen, or a regional alternative. Idempotency, retry policy, and failure semantics are normalized at the wrapper, not at every consumer. When the building swaps payment processors, the consumers are unaffected.",[11,301,302],{},"The wrapper also normalizes the path into accounting. Each financial event flows into the accounting integration with consistent metadata — building, unit, resident, category, period, behavioral context — so the building's books reflect the operational reality without manual reconciliation. The behavioral specification can then score whether the financial side of the resident experience meets the standard: refunds happen within a defined window, holds release on schedule, and statements arrive when the standard says they should.",{"title":43,"searchDepth":44,"depth":44,"links":304},[],"/architecture/engines/payment-wrapper","A single layer that wraps the building's payment processor and accounting system so resident charges, refunds, and reconciliation behave the same regardless of vendor.",{},[309,310],"direct-payment-vendor-integrations","manual-ledger-reconciliation",{"title":291,"description":306},"architecture/engines/payment-wrapper","eaxLuX_AHL2anDiQ0G0Nj50w09-OOKSolEXpnVrysJ8",{"id":315,"title":316,"body":317,"category":98,"deepPage":330,"description":331,"extension":49,"layer":101,"meta":332,"navigation":52,"path":330,"relatedFlows":57,"replaces":333,"seo":336,"stem":337,"__hash__":338},"architecture/architecture/engines/permissions.md","Permissions engine",{"type":8,"value":318,"toc":328},[319,322,325],[11,320,321],{},"The permissions engine answers a single question, evaluated millions of times across the building's lifetime: is this principal allowed to do this thing in this place at this moment. The principal can be a resident, a guest, a staff member, a contractor, a service technician, or another system. The thing can be opening a door, booking an amenity, raising an issue, retrieving a delivery, or invoking an internal workflow. The model is one model — there is no parallel matrix per vendor, per amenity, or per floor.",[11,323,324],{},"Permissions are declarative and time-bound. Each grant carries a scope (which spaces, which actions), a window (when it is valid), and an origin (who issued it and on what authority). The engine evaluates grants in real time, including transitive grants — a guest invited by a resident inherits the resident's spatial scope minus a defined exclusion list, with a window the resident cannot extend beyond the policy ceiling.",[11,326,327],{},"The permissions engine is the single source of truth that the access orchestration engine, the booking engine, the issue engine, and the staff console all consult before acting. When a building swaps an access vendor or a property management system, permissions are not migrated — the engine continues to hold the truth, and the new vendor consumes it through the integration layer.",{"title":43,"searchDepth":44,"depth":44,"links":329},[],"/architecture/engines/permissions","A single declarative model of who can do what, where, and for how long — across residents, guests, staff, contractors, and systems.",{},[334,335],"vendor-specific-permission-matrices","ad-hoc-key-management",{"title":316,"description":331},"architecture/engines/permissions","fv8JN5vs3HVpQFOsM7-juvKuN1FqssyihT32tZHJ-gs",{"id":340,"title":341,"body":342,"category":388,"deepPage":389,"description":390,"extension":49,"layer":391,"meta":392,"navigation":52,"path":389,"relatedFlows":57,"replaces":57,"seo":393,"stem":394,"__hash__":395},"architecture/architecture/flows/access.md","Access flow",{"type":8,"value":343,"toc":386},[344,347,353,359,365,371,377,383],[11,345,346],{},"The access flow runs on every attempt to enter the building, a unit, an amenity, or a back-of-house space. It is the most frequently executed workflow in the operating layer, and the one with the strictest reliability requirements.",[11,348,349,352],{},[17,350,351],{},"Request."," A credential read at a reader, a guest-pass scan, a delivery-courier code, a remote unlock from the resident app, or a staff-issued temporary pass. Every entry attempt produces a Request event with identity, location, and credential type.",[11,354,355,358],{},[17,356,357],{},"Evaluate."," The request runs through the rules engine and the permissions engine. Identity is resolved (resident, guest, staff, vendor, courier). Permissions are checked against the zone, the time window, escort rules, and any active building state (lockdown, maintenance, scheduled access window). Vendor APIs are queried only when the local cache cannot resolve.",[11,360,361,364],{},[17,362,363],{},"Permit."," A decision — allow or deny — is recorded before any hardware command is issued. The decision includes the rule set version that produced it. Hardware is then signaled through the access orchestration engine.",[11,366,367,370],{},[17,368,369],{},"Log."," The event is written to the building record with full context: who, where, when, decision, rule version, vendor response. Logs feed Layer 6 for trend and anomaly analysis.",[11,372,373,376],{},[17,374,375],{},"Notify."," The notification engine decides who hears about the event and how — usually nobody, sometimes the resident (a guest arrived), sometimes staff (a denial pattern suggests a problem), sometimes the host (a delivery is at the door). Tone and channel match the building's brand and the resident's preferences.",[11,378,379,382],{},[17,380,381],{},"Fallback paths."," If the cloud is unreachable, the edge gateway evaluates the decision locally against cached permissions and queues the log for sync. If hardware does not respond, the staff console alerts and a manual override path is available. If identity cannot be resolved, the request is denied and recorded for review.",[11,384,385],{},"The resident experience is silence until something matters. The flow exists to make sure that silence is earned.",{"title":43,"searchDepth":44,"depth":44,"links":387},[],"flow","/architecture/flows/access","Every entry decision is evaluated, permitted, logged, and acknowledged.","2",{},{"title":341,"description":390},"architecture/flows/access","3tKoVW2UjrkbF0znkePxDvZq7bwPsI-bTp_m8qHaPuk",{"id":397,"title":398,"body":399,"category":388,"deepPage":412,"description":413,"extension":49,"layer":391,"meta":414,"navigation":52,"path":412,"relatedFlows":57,"replaces":57,"seo":415,"stem":416,"__hash__":417},"architecture/architecture/flows/booking.md","Booking flow",{"type":8,"value":400,"toc":410},[401,404,407],[11,402,403],{},"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.",[11,405,406],{},"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.",[11,408,409],{},"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":43,"searchDepth":44,"depth":44,"links":411},[],"/architecture/flows/booking","How residents reserve amenities — request, evaluation, hold, confirmation, check-in, release.",{},{"title":398,"description":413},"architecture/flows/booking","GF-lTXzFOf7JRYQVFxnSydr1BnSMTyOKq99feX-wxZA",{"id":419,"title":420,"body":421,"category":388,"deepPage":434,"description":435,"extension":49,"layer":391,"meta":436,"navigation":52,"path":434,"relatedFlows":57,"replaces":57,"seo":437,"stem":438,"__hash__":439},"architecture/architecture/flows/delivery.md","Delivery flow",{"type":8,"value":422,"toc":432},[423,426,429],[11,424,425],{},"The delivery flow handles every parcel, food order, grocery, and goods movement that arrives for a resident. It is the most-frequent guest-style interaction in the building and the one that tends to fail loudest when it is unmanaged — packages stack at the front desk, residents miss handoffs, and recovery costs scale with volume.",[11,427,428],{},"A courier arrives with a delivery code or a known integration with a logistics partner. The access orchestration engine evaluates the credential and grants scoped entry — typically to the lobby and the parcel storage area, never to resident floors. The handoff is acknowledged: by a staff member, by an automated parcel locker, or by a resident who has chosen direct-to-door under their unit's permission policy. The acknowledgement is logged against the behavioral specification.",[11,430,431],{},"The resident is notified through their preferred channel within the response-time window specified by the standard. If retrieval does not occur within a defined period, the issue engine raises a follow-up. Edge cases — wrong unit, refused delivery, damaged parcel — are routed to staff with the context they need to resolve without contacting the resident a second time.",{"title":43,"searchDepth":44,"depth":44,"links":433},[],"/architecture/flows/delivery","How parcels and goods reach residents — courier arrival, scoped access, handoff, acknowledgement, retrieval.",{},{"title":420,"description":435},"architecture/flows/delivery","0XtV3uOn1HYt2TXWlew5UnRHDEBmw02-R1omDJCcAMM",{"id":441,"title":442,"body":443,"category":388,"deepPage":489,"description":490,"extension":49,"layer":391,"meta":491,"navigation":52,"path":489,"relatedFlows":57,"replaces":57,"seo":492,"stem":493,"__hash__":494},"architecture/architecture/flows/issue.md","Issue flow",{"type":8,"value":444,"toc":487},[445,448,454,460,466,472,478,484],[11,446,447],{},"The issue flow handles every maintenance, service, or operational request raised in the building — by a resident, by staff, by a sensor, or by an automated check.",[11,449,450,453],{},[17,451,452],{},"Submit."," A resident describes a problem in the app, with optional photos, location, and unit context. Staff submit through the operations console with category and priority pre-filled. Sensor-driven submissions arrive from the IoT layer with structured payloads.",[11,455,456,459],{},[17,457,458],{},"Categorize."," The issue engine assigns a domain (Access, Deliveries, Spaces, Support, Lifecycle, Environment) and a severity tier. Categorization combines text classification, the building's domain taxonomy, and explicit overrides where staff intervention is appropriate.",[11,461,462,465],{},[17,463,464],{},"Route."," Each category resolves to one or more responders — on-site staff, contracted vendors, or automated subsystems. The routing engine attaches an SLA based on category and severity, and identifies escalation paths for missed SLAs.",[11,467,468,471],{},[17,469,470],{},"Resolve."," The responder works the issue with state visibility (acknowledged → in-progress → awaiting parts → resolved). Parts, vendor coordination, and elapsed time are tracked alongside the work order. Multi-step resolutions hand off cleanly between teams.",[11,473,474,477],{},[17,475,476],{},"Close."," Completion criteria are explicit per category. A closed issue includes the work performed, the time spent, and any parts consumed. Resident-facing closure messages fire through the notification engine with the building's tone.",[11,479,480,483],{},[17,481,482],{},"Feedback."," A short survey fires after closure — typically one or two questions calibrated to the issue type. The signal feeds Layer 6 in two places: the building's own scoring (trust index, friction minutes, promise-kept rate) and the cross-building intelligence corpus that informs the next version of the behavioral specification.",[11,485,486],{},"The flow is the same whether the issue is a broken bulb or a major HVAC failure. The difference shows up in the SLA, the routing, and the tone — not in the workflow shape.",{"title":43,"searchDepth":44,"depth":44,"links":488},[],"/architecture/flows/issue","Maintenance and service requests, end to end.",{},{"title":442,"description":490},"architecture/flows/issue","ApgZ82r7OaAgNgNmSI0KemnDOj31WO1YJ2Zr5KABdsE",{"id":496,"title":497,"body":498,"category":388,"deepPage":511,"description":512,"extension":49,"layer":391,"meta":513,"navigation":52,"path":511,"relatedFlows":57,"replaces":57,"seo":514,"stem":515,"__hash__":516},"architecture/architecture/flows/move-in-out.md","Move-in / move-out flow",{"type":8,"value":499,"toc":509},[500,503,506],[11,501,502],{},"The move-in and move-out flows are the bookends of every resident relationship. They are also the moments the building is most exposed — credentials are issued, identity is established, lease terms are activated, and the resident's first impression is set. The standard treats both events as full workflows, not status changes.",[11,504,505],{},"At move-in, the operating layer ingests the lease handoff from the property management system, provisions the resident's identity, issues credentials scoped to the unit and shared spaces, schedules the welcome touchpoints, and surfaces a checklist for the resident to acknowledge. Each step is governed by the behavioral specification — credential issuance has a defined window, the welcome touchpoints have defined channels, and the acknowledgements are persisted as evidence the building met its move-in standard.",[11,507,508],{},"At move-out, the same engine reverses the lifecycle. Credentials revoke on a schedule tied to the lease end. Outstanding charges, deposits, and damage assessments route through the issue engine and the payment wrapper. The resident is offboarded with the same care they were onboarded with, and the building closes the lifecycle in a way that holds up under audit and protects the next tenancy.",{"title":43,"searchDepth":44,"depth":44,"links":510},[],"/architecture/flows/move-in-out","How the operating layer handles the transitions that bracket every tenancy — onboarding, credential issuance, key handback, and lifecycle closure.",{},{"title":497,"description":512},"architecture/flows/move-in-out","7Ja9Zg-K7_eH-WJd_2RtwMHQVgAvO507LXRFtUWOVIA",{"id":518,"title":519,"body":520,"category":388,"deepPage":533,"description":534,"extension":49,"layer":391,"meta":535,"navigation":52,"path":533,"relatedFlows":57,"replaces":57,"seo":536,"stem":537,"__hash__":538},"architecture/architecture/flows/notification.md","Notification logic",{"type":8,"value":521,"toc":531},[522,525,528],[11,523,524],{},"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.",[11,526,527],{},"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.",[11,529,530],{},"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":43,"searchDepth":44,"depth":44,"links":532},[],"/architecture/flows/notification","How the operating layer decides what to send, to whom, through which channel, and when.",{},{"title":519,"description":534},"architecture/flows/notification","XIDMKwGXsS6ixU7sWy9ha0DQAG6Uy0xBz52dOZ1K1To",{"id":540,"title":541,"body":542,"category":388,"deepPage":555,"description":556,"extension":49,"layer":557,"meta":558,"navigation":52,"path":555,"relatedFlows":57,"replaces":57,"seo":559,"stem":560,"__hash__":561},"architecture/architecture/guest-portal.md","The Guest Portal",{"type":8,"value":543,"toc":553},[544,547,550],[11,545,546],{},"The guest portal serves people who interact with the building without being residents — visitors, contractors, couriers, service technicians, short-term occupants. It is a lightweight, no-install surface accessed by link or QR code, with a credential that is scoped, time-bound, and revocable.",[11,548,549],{},"A resident invites a guest by issuing a credential through their app. The credential carries a defined window of validity, a specific set of permitted spaces, and an explicit purpose. The guest portal is what the guest sees: arrival instructions, entry credentials, a way to acknowledge house rules, and a single point of contact if something goes wrong. The orchestration engine evaluates the credential at every access point in the same way it evaluates a resident credential — there is no parallel \"guest\" pathway.",[11,551,552],{},"Delivery coordination uses the same primitives. A courier presents a delivery code, the orchestration engine permits scoped entry, and the issue engine routes any exceptions to staff. Temporary credentials for contractors and service technicians follow the same model, with the additional constraint that work-related access is logged against an active service request.",{"title":43,"searchDepth":44,"depth":44,"links":554},[],"/architecture/guest-portal","Visitor access, delivery coordination, and temporary credentials — for people who don't live in the building.","3",{},{"title":541,"description":556},"architecture/guest-portal","gggtN8GUNVDFYF_LsfrsSCzGvufThLDA56iY8asNZuU",{"id":563,"title":564,"body":565,"category":603,"deepPage":604,"description":605,"extension":49,"layer":101,"meta":606,"navigation":52,"path":604,"relatedFlows":57,"replaces":57,"seo":607,"stem":608,"__hash__":609},"architecture/architecture/integrations.md","Integrations",{"type":8,"value":566,"toc":600},[567,570,589,594,597],[11,568,569],{},"The operating layer does not replace every system in the building. It wraps the systems the building already runs — access hardware, property management, payments, accounting — and orchestrates them through a single behavioral specification. Each integration absorbs the vendor's data model into the operating layer, normalizes it against the standard, and surfaces a consistent experience to residents and staff.",[11,571,572,573,576,577,580,581,584,585,588],{},"Integrations are categorized by the role they play in the building. ",[17,574,575],{},"Access control"," connects to the orchestration engine and inherits the permissions model. ",[17,578,579],{},"Property management"," wraps lease, ledger, and unit-state data. ",[17,582,583],{},"Payments"," routes resident charges through the payment wrapper. ",[17,586,587],{},"Accounting"," synchronizes financial events into the building's books. The behavioral specification is the same regardless of which vendor sits behind it; the integration is the seam that makes vendor swaps possible without renegotiating the standard.",[590,591,593],"h2",{"id":592},"integration-approach","Integration approach",[11,595,596],{},"Each integration declares its capabilities, its data model, and its failure modes against the operating layer's contract. Where a vendor exposes a stable API, the operating layer consumes it directly. Where the vendor exposes only a portal, the integration is built against the documented data export and a scoped service account. Critical paths — access decisions, payment authorization — execute through the edge gateway when connectivity to the vendor cloud is intermittent.",[11,598,599],{},"No integration is exclusive. The orchestration engine is designed so the building can swap one access vendor for another, or one PMS for another, without rewriting the behavioral specification or breaking the resident experience. The vendor directory below lists the integrations currently shipped or available on request.",{"title":43,"searchDepth":44,"depth":44,"links":601},[602],{"id":592,"depth":44,"text":593},"integration","/architecture/integrations","How external systems connect to the operating layer — the vendor directory and the integration approach.",{},{"title":564,"description":605},"architecture/integrations","lDsPbdf0wjKA7T4DK8iCyTlmkgarD-gQWTc2dgsoqHk",{"id":611,"title":612,"body":613,"category":603,"deepPage":626,"description":627,"extension":49,"layer":101,"meta":628,"navigation":52,"path":626,"relatedFlows":57,"replaces":57,"seo":629,"stem":630,"__hash__":631},"architecture/architecture/integrations/adyen.md","Adyen integration",{"type":8,"value":614,"toc":624},[615,618,621],[11,616,617],{},"Adyen is the primary payment processor used by Apareé clients in EMEA and APAC, and a common choice for operators running cross-border portfolios. The integration sits behind the payment wrapper, exposing the same operations Stripe exposes, with Adyen's settlement, local payment methods, and regulatory posture underneath.",[11,619,620],{},"The integration consumes Adyen's unified commerce model so the same operating-layer behavior — charging an amenity fee, holding a deposit, issuing a refund — works across every market the building operates in. Local payment methods (SEPA, iDEAL, Bancontact, regional card schemes) are supported without per-method consumer code; the wrapper normalizes them into the same charge / hold / release / refund / reconcile contract.",[11,622,623],{},"The integration also handles the regulatory side. SCA challenges, 3DS flows, and country-specific reporting are managed at the wrapper, not exposed to the consumers. The behavioral standard scores the financial side of the resident experience — refunds within the window, holds released on schedule, statements arriving when they should — and the integration is what makes those guarantees enforceable across processors.",{"title":43,"searchDepth":44,"depth":44,"links":625},[],"/architecture/integrations/adyen","Adyen unified payments wrapped through the payment & invoice wrapper.",{},{"title":612,"description":627},"architecture/integrations/adyen","GbQS9CWTkIL-MuR3HNlTrmWFRS0II-QD-gEP_fKTZK4",{"id":633,"title":634,"body":635,"category":603,"deepPage":672,"description":673,"extension":49,"layer":101,"meta":674,"navigation":52,"path":672,"relatedFlows":675,"replaces":57,"seo":676,"stem":677,"__hash__":678},"architecture/architecture/integrations/dormakaba.md","Dormakaba integration",{"type":8,"value":636,"toc":670},[637,640,646,652,658,664],[11,638,639],{},"Dormakaba is the second primary access-control family wrapped by the operating layer. The integration covers three Dormakaba product lines, suited to different building scales and operational models.",[11,641,642,645],{},[17,643,644],{},"Dormakaba Lyazon."," A cloud-based access management platform aimed at commercial and mixed-use buildings. The integration uses the Lyazon cloud API for credential management, door control, and event ingestion. Lyazon is well-suited to buildings with more complex zone hierarchies and shift-based staff access patterns.",[11,647,648,651],{},[17,649,650],{},"Dormakaba exivo."," A cloud-managed access control system for small-to-mid buildings. The integration uses the exivo REST API. exivo is the default choice when a building's access needs are straightforward and the management overhead of a more configurable platform is not warranted.",[11,653,654,657],{},[17,655,656],{},"Dormakaba Ambiance."," A platform aimed at residential and hospitality contexts with a focus on mobile credentials and guest workflows. The integration uses the Ambiance API for credential issuance and door commands, with event subscription for real-time orchestration.",[11,659,660,663],{},[17,661,662],{},"What gets wrapped."," Door commands, credential lifecycle, event subscription, and device health. Per the same pattern as the SALTO integration, configuration of physical zones, door groups, and schedules stays in the Dormakaba console where vendor support and audit trail live; the operating layer reads from there.",[11,665,666,669],{},[17,667,668],{},"What is unified."," Same contract as every other integration. The resident does not see Dormakaba. Staff do not need to learn the Dormakaba console for routine operations. The orchestration engine presents a single decision interface, and Dormakaba is one of the hardware families that fulfils it.",{"title":43,"searchDepth":44,"depth":44,"links":671},[],"/architecture/integrations/dormakaba","Dormakaba Lyazon, exivo, and Ambiance wrapped through the access orchestration engine.",{},[54],{"title":634,"description":673},"architecture/integrations/dormakaba","mek8V076p-D0FJCuESBk0GNYgnEFqbJaO9XYIer3KQ8",{"id":680,"title":681,"body":682,"category":603,"deepPage":695,"description":696,"extension":49,"layer":101,"meta":697,"navigation":52,"path":695,"relatedFlows":57,"replaces":57,"seo":698,"stem":699,"__hash__":700},"architecture/architecture/integrations/quickbooks.md","QuickBooks integration",{"type":8,"value":683,"toc":693},[684,687,690],[11,685,686],{},"QuickBooks Online is the accounting system most commonly used by smaller and mid-tier residential operators in North America. The integration consumes the financial events emitted by the payment wrapper and lands them in QuickBooks with the metadata the building's accountant needs to reconcile without rework — building, unit, resident, category, period, behavioral context.",[11,688,689],{},"The integration is one-directional from the operating layer into QuickBooks. Charges, refunds, deposits, and adjustments flow in as journal entries against the right accounts on the right cadence. Where QuickBooks exposes class and location dimensions, the integration uses them so portfolio-level reporting works without manual tagging. Where the building's chart of accounts is non-standard, the integration is configured at deployment to map operating-layer categories onto the right account codes.",[11,691,692],{},"The point of the integration is not to replace the building's accountant. It is to remove the manual reconciliation step that traditionally bridges operations and accounting — so the books reflect the operational reality the standard scored, with no discretionary mapping in between.",{"title":43,"searchDepth":44,"depth":44,"links":694},[],"/architecture/integrations/quickbooks","QuickBooks Online wrapped through the accounting integration so financial events from the operating layer land in the building's books.",{},{"title":681,"description":696},"architecture/integrations/quickbooks","MlVSZ1THx3mjZ5upDkOOSe8W9kqYAHmeRqU2yrQaK-w",{"id":702,"title":703,"body":704,"category":603,"deepPage":717,"description":718,"extension":49,"layer":101,"meta":719,"navigation":52,"path":717,"relatedFlows":57,"replaces":57,"seo":720,"stem":721,"__hash__":722},"architecture/architecture/integrations/realpage.md","RealPage integration",{"type":8,"value":705,"toc":715},[706,709,712],[11,707,708],{},"RealPage is the second of the two dominant property management systems in the residential operator market. The integration covers the OneSite product line for traditional multifamily and the Investment Management Services platform for institutional asset operators, behind the same operating-layer contract used for Yardi.",[11,710,711],{},"The integration consumes RealPage as the system of record for lease, ledger, and unit-state data. The orchestration is one-directional from RealPage on lease and tenancy facts, and bi-directional on operational events that need to land in RealPage's ledger — amenity charges, late fees, deposit holds, refunds. The wrapper normalizes the shape of these events so the building's books reflect the resident's actual experience, not a vendor-specific schema.",[11,713,714],{},"Failure modes are explicit. If RealPage is unreachable, the operating layer continues to serve resident workflows from cache and queues outbound events for reconciliation when the link returns. The behavioral standard scores the resident-facing experience, not the integration's uptime — a Yardi-backed building and a RealPage-backed building produce the same resident behavior or they do not meet the standard.",{"title":43,"searchDepth":44,"depth":44,"links":716},[],"/architecture/integrations/realpage","RealPage OneSite and IMS wrapped through the property management integration layer.",{},{"title":703,"description":718},"architecture/integrations/realpage","BKGAjC_ZoRD0sfElKMBhbGBux8cr4UbJo9g3r6crPJk",{"id":724,"title":725,"body":726,"category":603,"deepPage":761,"description":762,"extension":49,"layer":101,"meta":763,"navigation":52,"path":761,"relatedFlows":764,"replaces":57,"seo":765,"stem":766,"__hash__":767},"architecture/architecture/integrations/salto.md","SALTO integration",{"type":8,"value":727,"toc":759},[728,731,737,743,749,754],[11,729,730],{},"SALTO is one of two primary access-control families wrapped by the operating layer. The integration covers three SALTO product lines, each suited to a different building profile.",[11,732,733,736],{},[17,734,735],{},"SALTO KS."," Cloud-based access control for buildings that need centralised credential management and remote operation. The integration uses the KS REST API for credential issuance and revocation, real-time door commands, and event subscription. KS is the default choice for portfolio operators who want a single management surface across multiple buildings.",[11,738,739,742],{},[17,740,741],{},"SALTO Nebula."," A unified cloud platform for SALTO's broader hardware range. The integration uses the Nebula REST API and event stream. Nebula carries the more recent SALTO product roadmap and is the recommended path for new commissioning unless an existing building is already on KS.",[11,744,745,748],{},[17,746,747],{},"SALTO Homelok."," Designed for residential applications with a stronger resident-facing posture — mobile credentials, guest passes, delivery codes. Where Homelok is deployed, the operating layer wraps it the same way: residents see the Apareé surface, Homelok handles the door.",[11,750,751,753],{},[17,752,662],{}," Door control commands, credential lifecycle (issue, modify, revoke, replace), real-time event ingestion (access granted, denied, door held, forced), and device health telemetry. Configuration of doors, schedules, and access groups remains in the SALTO console where SALTO owns the truth — the operating layer reads from those configurations rather than mirroring them.",[11,755,756,758],{},[17,757,668],{}," From the resident's perspective, there is no SALTO. There is the building. The same is true for staff using the operations console and for the workflows that issue access decisions. SALTO is an implementation detail, swappable without disturbing the experience.",{"title":43,"searchDepth":44,"depth":44,"links":760},[],"/architecture/integrations/salto","SALTO KS, Nebula, and Homelok wrapped through the access orchestration engine.",{},[54],{"title":725,"description":762},"architecture/integrations/salto","JUKvkeN8Xuw8TCuXb65L7f9whymhck7-iMJlzyb2ZHY",{"id":769,"title":770,"body":771,"category":603,"deepPage":784,"description":785,"extension":49,"layer":101,"meta":786,"navigation":52,"path":784,"relatedFlows":57,"replaces":57,"seo":787,"stem":788,"__hash__":789},"architecture/architecture/integrations/stripe.md","Stripe integration",{"type":8,"value":772,"toc":782},[773,776,779],[11,774,775],{},"Stripe is the primary payment processor used by Apareé clients in North America and several non-EEA markets. The integration sits behind the payment wrapper, exposing the same charge / hold / release / refund / reconcile contract that the booking engine, the issue engine, and the move-in / move-out flow consume.",[11,777,778],{},"The integration uses Stripe's idempotency primitives and webhook delivery model to guarantee that financial events land exactly once in the building's ledger, even under retries and processor outages. Holds for amenity deposits and security deposits are issued through Stripe's authorization model and released on the schedule defined by the behavioral standard. Refunds are a first-class workflow, not a manual back-office task — the standard requires refunds to happen within a defined window, and the wrapper enforces that contract regardless of which processor sits behind it.",[11,780,781],{},"When a building swaps Stripe for Adyen, or vice versa, the consumers — booking engine, issue engine, onboarding — are unaffected. The wrapper is the only thing that changes.",{"title":43,"searchDepth":44,"depth":44,"links":783},[],"/architecture/integrations/stripe","Stripe Payments and Connect wrapped through the payment & invoice wrapper.",{},{"title":770,"description":785},"architecture/integrations/stripe","nuD8OE0yN0H2R2XZ9aWlZu4zjYw7mdfruP7l6LKjxDE",{"id":791,"title":792,"body":793,"category":603,"deepPage":806,"description":807,"extension":49,"layer":101,"meta":808,"navigation":52,"path":806,"relatedFlows":57,"replaces":57,"seo":809,"stem":810,"__hash__":811},"architecture/architecture/integrations/xero.md","Xero integration",{"type":8,"value":794,"toc":804},[795,798,801],[11,796,797],{},"Xero is the accounting system most commonly used by Apareé clients in EMEA, APAC, and emerging markets. The integration is the EMEA-and-APAC counterpart to QuickBooks: it consumes the financial events emitted by the payment wrapper and lands them in Xero with consistent metadata for unit, resident, category, period, and behavioral context.",[11,799,800],{},"The integration is one-directional from the operating layer into Xero. Charges, refunds, deposits, and adjustments flow in as bills, invoices, and journal entries against the right accounts on the right cadence. Tracking categories are used for portfolio-level reporting where the operator runs multiple buildings on the same Xero tenant. Multi-currency handling follows Xero's settlement model so cross-border operators can report in a single base currency without manual conversion.",[11,802,803],{},"The integration's role is the same as QuickBooks's role: remove the manual reconciliation step between operations and accounting, so the books reflect the resident experience the standard scored without discretionary mapping in between.",{"title":43,"searchDepth":44,"depth":44,"links":805},[],"/architecture/integrations/xero","Xero wrapped through the accounting integration so financial events from the operating layer land in the building's books.",{},{"title":792,"description":807},"architecture/integrations/xero","oWlbO7mS6lM6dJtqqlgQeAZRtSjoq4XUOjgdUsR6IAc",{"id":813,"title":814,"body":815,"category":603,"deepPage":828,"description":829,"extension":49,"layer":101,"meta":830,"navigation":52,"path":828,"relatedFlows":57,"replaces":57,"seo":831,"stem":832,"__hash__":833},"architecture/architecture/integrations/yardi.md","Yardi integration",{"type":8,"value":816,"toc":826},[817,820,823],[11,818,819],{},"Yardi is one of the two dominant property management systems in the residential operator market. The integration covers the two product lines most commonly deployed by Apareé clients — Voyager for institutional and mid-tier portfolios, and Breeze for smaller operators — and absorbs both behind the same operating-layer contract.",[11,821,822],{},"The integration consumes Yardi as the system of record for lease, ledger, and unit-state data. Lease activations and terminations flow into the onboarding and move-out engines on a defined cadence. Charges originating in the operating layer flow back into Yardi's ledger through the accounting integration with consistent metadata. The resident-facing experience does not depend on Yardi being reachable in real time; the operating layer caches the data the resident-facing flows need and reconciles asynchronously.",[11,824,825],{},"Where Yardi exposes a stable API, the integration consumes it directly. Where Yardi exposes only a portal, the integration is built against documented exports and a scoped service account. Either way, the building's resident experience is governed by the behavioral specification, not by the seam between the operating layer and the PMS.",{"title":43,"searchDepth":44,"depth":44,"links":827},[],"/architecture/integrations/yardi","Yardi Voyager and Breeze wrapped through the property management integration layer.",{},{"title":814,"description":829},"architecture/integrations/yardi","fh5oUiIo8aETSy_wNjQUwTcInnHGwmzYPPoFw9ULIvk",{"id":835,"title":836,"body":837,"category":888,"deepPage":889,"description":890,"extension":49,"layer":891,"meta":892,"navigation":52,"path":889,"relatedFlows":57,"replaces":57,"seo":893,"stem":894,"__hash__":895},"architecture/architecture/intelligence.md","The Intelligence Layer",{"type":8,"value":838,"toc":884},[839,842,861,865,868,871,875,878,881],[11,840,841],{},"The Intelligence layer sits above the operating infrastructure. It does not run the building — it observes how the building performs against the behavioral specification, quantifies drift, and produces evidence the bureau can act on. Every workflow execution, every access decision, every resident interaction becomes a record. The Intelligence layer reads those records and answers a single contractual question: is the building still meeting the standard it was commissioned to meet.",[11,843,844,845,848,849,852,853,856,857,860],{},"Four evidence streams converge here. ",[17,846,847],{},"Telemetry"," captures continuous machine-generated signals from the operating layer — request volumes, resolution times, error rates, channel reliability. ",[17,850,851],{},"Surveys"," capture resident sentiment at moments tied to specific behaviors, not annualized satisfaction averages. ",[17,854,855],{},"Interviews"," capture qualitative findings from staff and residents on a recurring cadence. ",[17,858,859],{},"Cross-building comparisons"," place the building's performance against peer buildings of similar profile, market, and tier. None of the four streams alone is sufficient; together they triangulate a defensible behavioral score.",[590,862,864],{"id":863},"scoring-methodology","Scoring methodology",[11,866,867],{},"Each of the thirty-six expectation cells in the standard is evaluated independently. A cell receives a green, yellow, red, or grey state based on weighted evidence across the four streams. Green means the cell is meeting its expectation. Yellow indicates partial fulfillment or recent drift. Red indicates the floor has not been met. Grey means insufficient evidence — usually a building too new or a domain not yet in scope. The aggregate LEI score is a roll-up across cells, weighted by domain criticality and quality tier.",[11,869,870],{},"The score is a contractual reference point, not a marketing rating. A building scored at commissioning establishes a baseline. Each quarter, the score shows whether performance held, improved, or drifted — and in which domain. Over years, the score produces a behavioral performance history for the asset.",[590,872,874],{"id":873},"insights-engine","Insights engine",[11,876,877],{},"The insights engine processes the building's evidence and produces specific recommendations: which domain is drifting, what is likely causing it, and what the specification requires. It is an analytical service maintained by Apareé, separate from the commissioned infrastructure. It runs continuously for every building under warranty.",[11,879,880],{},"Recommendations are not generic. They reference specific cells, specific evidence patterns, and specific operational interventions. A drifting \"Deliveries × Reliability\" cell does not produce \"improve delivery operations\" — it produces \"package handoff time has increased 22% over the last quarter; the issue is concentrated in evening hours when the front desk is unattended; the specification requires acknowledged handoff within fifteen minutes.\"",[11,882,883],{},"The insights engine closes the behavioral loop. It feeds findings back into the next version of the standard and into the deployment governance process. It is what makes the warranty enforceable.",{"title":43,"searchDepth":44,"depth":44,"links":885},[886,887],{"id":863,"depth":44,"text":864},{"id":873,"depth":44,"text":874},"metric","/architecture/intelligence","How the operating layer turns operational records into evidence — the scoring methodology, four evidence streams, metrics, and the insights engine.","6",{},{"title":836,"description":890},"architecture/intelligence","VRS04mbsBcykN-ivuCWC_DlakvMpQpRq34Jbq2O01A0",{"id":897,"title":898,"body":899,"category":388,"deepPage":912,"description":913,"extension":49,"layer":557,"meta":914,"navigation":52,"path":912,"relatedFlows":57,"replaces":57,"seo":915,"stem":916,"__hash__":917},"architecture/architecture/resident-app.md","The Resident App",{"type":8,"value":900,"toc":910},[901,904,907],[11,902,903],{},"The resident app is the primary surface through which a resident encounters the operating layer. Its design follows a single principle: residents should not experience the system, they should experience the building. Every workflow the building offers — entering a space, booking an amenity, reporting an issue, receiving a delivery, paying rent — is one place, with consistent rules, reliable confirmations, and a single source of truth.",[11,905,906],{},"The app is offered as a white-labeled native experience and as a progressive web surface for residents who do not install apps. Brand customization spans typography, color, copy, and the building's identity — but the structural elements of the experience, the workflows, and the response times are governed by the behavioral standard. The app cannot be themed in a way that violates the specification.",[11,908,909],{},"Offline behavior matters. The app maintains a cached representation of the resident's permissions, recent bookings, and active issues. During cloud connectivity loss, access decisions and amenity check-ins continue through the edge gateway; the app shows a clear offline indicator and reconciles state when the link returns. Residents should never see a blank screen because a cloud service is degraded.",{"title":43,"searchDepth":44,"depth":44,"links":911},[],"/architecture/resident-app","The resident-facing surface — features, design approach, and brand customization.",{},{"title":898,"description":913},"architecture/resident-app","PRe69T940LAG_OajAVqRuOW_U6Dg4cSupB_EYFz3UWs",{"id":919,"title":920,"body":921,"category":46,"deepPage":952,"description":953,"extension":49,"layer":954,"meta":955,"navigation":52,"path":952,"relatedFlows":57,"replaces":57,"seo":956,"stem":957,"__hash__":958},"architecture/architecture/security.md","Security and Compliance",{"type":8,"value":922,"toc":947},[923,926,930,933,937,940,944],[11,924,925],{},"The operating layer runs on infrastructure controlled by the building owner. Apareé operates within scoped service accounts, against a defined behavioral specification, with no access to data the building has not explicitly granted. Security is not a feature of the operating layer — it is a property of the ownership model.",[590,927,929],{"id":928},"data-governance","Data governance",[11,931,932],{},"Resident data is owned by the building. The operating layer stores it in the building's cloud tenancy under the building's identity provider. Access to resident records is gated by role-based permissions defined in the deployment agreement. Apareé's bureau staff have no standing access; bureau access is opportunistic, scoped, audited, and revocable by the owner at any time.",[590,934,936],{"id":935},"encryption-and-access-control","Encryption and access control",[11,938,939],{},"Data at rest is encrypted using keys held in the owner's key management service. Data in transit is encrypted end-to-end between the resident app, the edge gateway, and the cloud. Service-to-service authentication uses short-lived tokens scoped to specific operations. The principle is consistent across the stack: the smallest possible privilege, the shortest possible duration, the clearest possible audit trail.",[590,941,943],{"id":942},"compliance-posture","Compliance posture",[11,945,946],{},"The operating layer is designed to operate under GDPR and equivalent regional data-protection regimes. Residents have rights of access, correction, portability, and erasure; the operating layer exposes these rights as first-class workflows. Data residency follows the building — a building in the EU runs on EU-hosted infrastructure with EU-resident data, regardless of which bureau operates the warranty. Detailed compliance documentation is provided as part of the deployment package.",{"title":43,"searchDepth":44,"depth":44,"links":948},[949,950,951],{"id":928,"depth":44,"text":929},{"id":935,"depth":44,"text":936},{"id":942,"depth":44,"text":943},"/architecture/security","Data governance, GDPR posture, encryption, access control, and the compliance boundary between the bureau and the building.","7",{},{"title":920,"description":953},"architecture/security","CkztcK6pvZKHvpzOshaMl6-IQ6uARmBfy3POFLWNUvs",{"id":960,"title":961,"body":962,"category":388,"deepPage":980,"description":981,"extension":49,"layer":557,"meta":982,"navigation":52,"path":980,"relatedFlows":57,"replaces":57,"seo":983,"stem":984,"__hash__":985},"architecture/architecture/staff-console.md","The Operations Console",{"type":8,"value":963,"toc":977},[964,967,970,974],[11,965,966],{},"The operations console is the surface that on-site staff and remote operators use to run the building. It is a single workspace that consolidates every operational signal — open issues, active deliveries, incoming guests, amenity bookings, environmental alerts — and presents them prioritized by behavioral consequence rather than by feature category.",[11,968,969],{},"The console is organized around the standard, not around vendors. Staff do not switch between an access portal, a ticketing system, and a delivery log; they see one queue of work, with each item carrying enough context to act. The console enforces the same rules the resident app enforces: the workflows that route, escalate, and resolve are governed by the behavioral specification, not by staff preference.",[590,971,973],{"id":972},"monitoring-and-alerts","Monitoring and alerts",[11,975,976],{},"Real-time monitoring covers the building's operational health: integrations, hardware uptime, response-time SLOs, scheduled handoffs. When a metric drifts outside its specified band, the console raises an alert with the context needed to investigate. Alerts are triaged by behavioral impact — a paused booking engine ranks above a delayed monthly report — and the console exposes the underlying telemetry feeding each metric so staff can verify findings before acting.",{"title":43,"searchDepth":44,"depth":44,"links":978},[979],{"id":972,"depth":44,"text":973},"/architecture/staff-console","The staff-facing operations surface — features, workflows, monitoring, and alerts.",{},{"title":961,"description":981},"architecture/staff-console","dNXztBNAFqT65oO_XOz3XTDn-KZl_fn0KBJlYQT5F9c",[987,997,1007,1017,1027],{"path":988,"question":989,"body":990},"/faq/how-different-from-yardi","How is Apareé different from a property management system like Yardi or RealPage?",{"type":8,"value":991,"toc":995},[992],[11,993,994],{},"Property management systems handle tenancy — leases, billing, maintenance ticketing, communication. Apareé sits above these systems. The operating layer orchestrates what property management software and every other vendor system in the building produce together for the resident. A building can keep its existing property management system. Apareé defines what the resident experience across all systems should be, and holds it to that standard.",{"title":43,"searchDepth":44,"depth":44,"links":996},[],{"path":998,"question":999,"body":1000},"/faq/what-happens-to-existing-systems","What happens to my existing systems? Do you replace them?",{"type":8,"value":1001,"toc":1005},[1002],[11,1003,1004],{},"Existing systems are integrated, not replaced. Where a system is sufficient, the operating layer wraps it — integrating its data and orchestrating its output. Where a system is weak or absent for a specific designed interaction, Apareé provides a dedicated engine or recommends an alternative. Which systems are wrapped and which are built is defined in the commissioning blueprint for each building.",{"title":43,"searchDepth":44,"depth":44,"links":1006},[],{"path":1008,"question":1009,"body":1010},"/faq/is-the-resident-app-white-labeled","Is the resident app white-labeled to our brand?",{"type":8,"value":1011,"toc":1015},[1012],[11,1013,1014],{},"The resident application is designed to the building's identity. The interface, visual language, tone, and interaction quality reflect the brand's intent — not Apareé's brand. For branded residences, the application is an extension of the brand experience, not a third-party tool.",{"title":43,"searchDepth":44,"depth":44,"links":1016},[],{"path":1018,"question":1019,"body":1020},"/faq/what-data-do-you-collect","What data do you collect? Who owns it?",{"type":8,"value":1021,"toc":1025},[1022],[11,1023,1024],{},"The operating layer collects structured operational data — interaction records, resident signals, system events — necessary to score the building's behavior against its specification. The data belongs to the building. Apareé processes it to produce behavioral intelligence and scoring. Data governance, access, and retention terms are defined in the commissioning agreement.",{"title":43,"searchDepth":44,"depth":44,"links":1026},[],{"path":1028,"question":1029,"body":1030},"/faq/how-does-this-work-with-iot","How does Apareé's system work with smart home / IoT systems in the building?",{"type":8,"value":1031,"toc":1035},[1032],[11,1033,1034],{},"The operating layer integrates with the building's existing IoT and smart home systems through the integration backbone. Environmental sensors, smart locks, lighting controls, HVAC — these are wrapped into the orchestration layer so they contribute to the designed resident experience rather than operating independently. The edge gateway ensures critical functions continue even during connectivity interruptions.",{"title":43,"searchDepth":44,"depth":44,"links":1036},[],1779718757696]