Methodology
How the standard was written, how it is structured, and how it is intended to be used.
Origin
The Apareé Digital Architecture Guidelines emerged from a single observation: physical buildings are governed by codes and standards that have evolved over decades. The behavioral experience of living in those buildings — every notification, every credential, every interaction with a system the building operates — is governed by nothing.
The gap between the physical standard of care and the behavioral standard of care is where resident frustration lives. The guidelines exist to close that gap.
Scope
The standard defines behavioral expectations — what the building does, as experienced by the resident. It does not prescribe technology, vendor selection, or system architecture. A behavioral expectation is the same whether the building uses smart lockers or a staffed desk, mobile credentials or key fobs, a single-vendor system or a multi-vendor integration.
The standard is technology-neutral by design. It defines expected behavior, not required capability. Following the principle established by ISO/IEC Directives, Part 2: requirements are expressed in terms of performance rather than design or descriptive characteristics.
Structure
The standard is organized along two axes.
Six domains define where behavior happens: Access, Deliveries, Spaces, Support, Lifecycle, and Environment. These are anthropological constants — they represent the recurring activities that define a resident's relationship with their building.
Six qualities define how behavior is judged: Reliability, Clarity, Control, Harmony, Grace, and Care. These form a hierarchy — each level depends on the one below it.
The intersection of six domains and six qualities produces thirty-six behavioral expectations. Each expectation is specific, testable, and universal.
Expectation format
Every behavioral expectation follows a consistent structure:
Expectation — a single sentence defining what the building does. Uses "shall" to indicate obligation. Each expectation contains a single behavioral claim.
Required — the minimum set of behaviors the building must demonstrate. Written in bare declarative present tense: "the building communicates," "the resident can," "no outage persists." These are testable requirements, not aspirations.
Recommended — behaviors that strengthen the expectation but are not mandatory. Same voice as Required. These represent what becomes possible with deeper integration or greater capability.
In practice — concrete scenarios showing what the expectation looks like when met. These are not hypothetical — they describe behaviors that existing buildings demonstrate.
Failure modes — specific, named patterns of failure. Each describes a recognizable moment where the building breaks the expectation and how the resident experiences that failure.
Test — observable, repeatable verification steps. Each test uses a "Confirm:" structure that produces a binary result. If the building passes the test, it meets the expectation. If it fails, the gap is specific and actionable.
Language conventions
The standard uses precise language to distinguish levels of obligation.
Expectation statements use "shall" to indicate a requirement. This is the only context where "shall" appears.
Required bullets use bare declarative present tense: "the building communicates the failure," "the resident can initiate a household change," "no notice persists longer than 48 hours." This voice describes the expected state of the building — how it behaves when it meets the standard.
Recommended bullets use the same declarative voice. The distinction from Required is structural (the section heading), not verbal.
In practice and failure modes use present tense narrative. These sections are informative — they illustrate the expectation but do not impose additional obligations.
The standard avoids emotion, persuasion, and marketing language. Every sentence in a Required or Recommended bullet is either a testable claim or a concrete scenario. If a statement cannot be tested or observed, it does not belong in the standard.
Measurement
The standard defines expectations. The Living Experience Index (LEI) measures them.
LEI translates the thirty-six behavioral expectations into observable, scorable signals — producing a score for each expectation, each domain, each quality, and an overall index from 0 to 100. LEI is vendor-neutral. Any building, with any technology stack, can be measured. Buildings can be compared across portfolios and tracked over time.
The standard defines the expectation. LEI measures the outcome. They are separate by design: the standard does not change based on measurement methodology, and the measurement can evolve without rewriting the standard.
The full LEI methodology is published separately.
Intended use
The standard is designed for three audiences.
Architects and developers use the standard during design to specify how the building should behave — alongside the physical specifications that govern how it is built.
Operators and property managers use the standard during operation to measure whether the building is meeting its behavioral commitments and to identify where drift has occurred.
System integrators and consultants use the standard as a reference when selecting, configuring, and connecting the systems that produce the resident's experience.
The standard is not a product specification. It is a behavioral specification — a shared language for what residents have the right to expect from the building they live in.