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.

What the standard does not govern

The boundary is deliberate. Outside it:

Physical performance. Structural integrity, fire safety, mechanical and electrical performance, energy efficiency — the domain of building codes and engineering standards. The standard begins where they end: how the building behaves toward the people inside it. Where physical systems appear in the standard, the subject is communication about their state, never their performance.
Community and social programming. Events, neighbor relations, the cultural life of shared spaces. The standard governs whether the booking works — not whether the gathering succeeds.
Staffing models and organizational structure. The standard specifies behavior, not headcount. Expectations that operate at all hours describe system behavior, not staffing schedules.
Pricing and commercial terms. Rents, fees, and deposits belong to the instruments between the parties. The standard governs only their communication: charges explained, published before applied, and disputable.
Sustainability targets and reporting. Consumption data may surface to residents within the Environment domain; sustainability certification and reporting remain separate disciplines.

A topic outside the standard is not declared unimportant — it is declared out of scope, so that the behavioral expectations stay specific, testable, and durable.

Structure

The standard is organized along two axes.

The 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.

The 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 two axes are ordered differently by design. The qualities form a hierarchy of dependency. The domains are peers — no domain depends on another — and their sequence is a reading order, from the resident's most frequent interaction to the building's ambient state, never a ranking. Which domain carries the greatest weight is a property of the building and its type, not of the standard.

The intersection of six domains and six qualities produces thirty-six behavioral expectations. Each expectation is specific, testable, and universal.

The grid is closed by construction. The domains enumerate what a resident does with a building; the qualities enumerate what a person needs from any system they depend on. A candidate expectation that fits no intersection is either outside the standard's scope or evidence that a domain or quality needs sharper definition — it is not grounds for a seventh row.

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.

Basis of the expectations

The failure modes are drawn from documented incident patterns in operating buildings — each describes a way buildings have actually failed, not a hypothetical. The In practice scenarios describe behaviors that existing buildings demonstrate. Where the standard states a fixed threshold — an advance notice window, an update interval, a revocation time — the threshold marks the floor at which the documented pattern was observed to break: the point past which residents stop treating a notice as live, a warning as actionable, or a revocation as real.

The fixed thresholds

Most numbers in the standard are not the standard's — they are the building's own, published and honored as parameters. The thresholds the standard itself fixes are few, and each marks an observed floor:

48 hours — the advance-notice and update interval: disposition notice before an unclaimed delivery leaves custody, planned closures and disruptions, the refresh interval for standing outage notices. Below two days, a resident who checks the interface daily cannot reliably both see a notice and act on it; past two days without an update, a standing notice reads as abandoned rather than live. The same floor holds in both directions, which is why it recurs across domains.
One minute — credential revocation. Revocation is a security action, and its tolerance is measured in the time it takes the revoked person to reach a door. A propagation window measured in hours is not slow revocation; it is access that has not been revoked.
90 days — renewal communication. The shortest span in which a household can weigh options, decide, and act without the deadline doing the deciding.
30 days — the departure guide. Long enough to plan a move around the building's process rather than discover the process mid-move.
12 months, or the current occupancy — record visibility floors for delivery, booking, and financial history. Disputes arrive on annual cycles — billing, renewals, deposits — and a record that expires before the cycle closes fails at the moment it is first needed.

A building may exceed any of these; the thresholds are floors, not targets. A revision that moves one must show the observed pattern that moved.

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.

Reading the absolutes

Expectations state absolutes — "on every attempt," "every item," "at all hours" — because they define the designed behavior of the building, not an engineering tolerance. The standard treats failure as a designed state: detection, communication, alternatives, and recovery are themselves Required behaviors in the relevant expectations. An absolute is breached by design choices and recurring patterns — a credential system that cannot survive a network interruption, a receiving system that loses records at migration — not by a single incident that the building detects, communicates, and recovers through its own published provisions. What escapes the standard is not failure; it is silent failure.

Revision discipline

The standard evolves within a fixed structure. The six domains and six qualities are stable; the expectations within them change only through documented revision — proposed, weighed against the structural rules above, and recorded with the reasoning that motivated the change. Nothing changes because a single building or project found a requirement inconvenient.

Cross-domain references are informative annotations, not normative requirements. They make coordination between domains visible without binding one domain's revision to another's.

Measurement

The standard defines expectations. The Living Experience Index (LEI) is the scoring methodology that reads buildings against them — the mathematics under the scoring, maintained separately by Apareé.

Satisfaction surveys and sentiment scores measure how residents feel; the standard defines what the building does. They answer different questions, and one cannot substitute for the other — a sentiment score locates no cause, and a met expectation guarantees no feeling.

LEI translates the 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 scored result for an individual building is its behavioral profile; scored buildings are published on the Benchmark.

The standard defines the expectation. LEI measures the outcome. They are separate by design: the standard does not change based on scoring methodology, and the methodology can evolve without rewriting the standard.

Intended use

The standard is designed for four 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.

Owners and acquirers use the standard when examining a building — before acquisition, at refinancing, or at an operator transition. The Tests provide a protocol for what to examine; the scope statement defines what the building has committed to.

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.

Companion pages serve each audience in their own terms: Designing to the Standard for design-stage work, Implementation Notes for technical readers, and Specifying the Standard for the instruments that reference the standard.