Study the WELL v2 framework as a decision system, not a list. For every feature part you review, record three things: whether it is a precondition or optimization, what compliance path it offers, and what evidence verifies it. That mapping habit is what turns reading into exam-ready reasoning.
Feature anatomy: concepts, features, and parts in WELL v2
WELL v2 organizes requirements into ten concepts, each containing features, and each feature contains numbered parts. Scenario reasoning works at the part level, so always anchor your analysis to the specific part, not the concept or feature name.
A mental model helps: concepts are chapters (Air, Water, Nourishment, Light, Movement, Thermal Comfort, Sound, Materials, Mind, Community, plus Innovations), features are the strategies within them, and parts are the individually verifiable requirements inside each feature. A scenario that names a feature may actually turn on one part of it, and the parts can differ in threshold, applicability, and evidence. Treating a whole feature as a single lump therefore blurs exactly the distinctions you are asked to reason about.
When you study a feature, read every part and note where parts split by project type, such as owner-occupied versus tenant-improvement scopes. Parts can be conditionally applicable, so check applicability whenever you read: a part may be required only depending on project characteristics. Practicing that conditional reading early prevents the habit of assuming every part applies to every project.
- Ten concepts plus Innovations frame the standard's scope
- Features break into independently verified parts
- Applicability conditions decide when a part applies
- Part-level detail is where scenario reasoning happens
Preconditions versus optimizations: the distinction that drives answers
Preconditions are mandatory requirements a project must meet at its chosen level; optimizations are optional features that add points. Deciding which category a requirement belongs to is often the first step in answering a scenario question correctly.
The distinction matters because it changes the consequences of an answer. If a scenario omits a precondition, the project cannot achieve certification at all; if it omits an optimization, the project still certifies but earns fewer points. Scenario practice probes this: a plausible-sounding fix that addresses an optimization may be wrong because the real gap is a precondition, and recognizing that requires asking what category each requirement sits in before evaluating the fix.
A useful study habit is labeling while you read: mark each requirement P or O and ask what happens if it is unmet. For preconditions, ask whether the failure blocks certification entirely or just that feature. For optimizations, ask how many points are at stake and whether a substitute optimization could fill the gap. This consequence-first reading trains exactly the judgment scenarios demand.
- Preconditions: mandatory, gate certification achievement
- Optimizations: optional, contribute points toward targets
- A precondition gap is a bigger problem than a points shortfall
- Label every part P or O during your first reading pass
Verification pathways: matching evidence type to requirement type
WELL v2 verification generally falls into document-based evidence (such as annotated documents and letters of assurance), on-site performance testing, and interviews. Matching the right pathway to a feature is a core exam skill.
Each pathway proves something different. Letters of assurance attest that a party has committed to or implemented a policy; annotated documents show a design decision in a drawing or plan; technical documents supply supporting records such as product data; performance tests measure conditions in the built space; interviews confirm ongoing operational practices. A feature part whose claim is a measured environmental threshold cannot be satisfied by paperwork describing intent, and a policy commitment cannot be satisfied by a drawing. Sorting every part into its pathway forces you to identify what the part fundamentally claims.
Revisit the table below after finishing each concept in your review. For every part you studied, predict which row it belongs to, then check your reasoning. Disagreements between your prediction and the table reveal parts where you memorized wording but not the underlying claim type — exactly where scenario questions probe.
| Verification pathway | What it demonstrates | Requirement style it fits | Common study mix-up |
|---|---|---|---|
| Letter of assurance | A signed commitment that a policy or action is in place | Policy, procurement, and operational commitments | Treating a signed letter as proof of a measured condition |
| Annotated document | A design decision visible in a drawing, plan, or schedule | Features fixed at the documentation stage | Assuming a drawing shows how a finished space performs |
| Technical document | Supporting records such as product or equipment data | Requirements resting on equipment or material properties | Confusing supporting records with direct proof of a space condition |
| On-site performance test | A measured condition in occupied spaces after construction | Thresholds expressed as maximum or minimum levels | Expecting a specification to substitute for measurement |
| Interview | Confirmation from a responsible party about ongoing practices | Operational practices only staff or management can describe | Guessing that every operational part is verified by paperwork |
Worked scenario 1: choosing optimizations under a limited scope
When a scenario restricts budget or scope, first confirm all preconditions, then compare optimizations by points earned and evidence burden. The better answer usually weighs feasibility of verification, not just the headline points value.
Practice scenario (invented for study): a tenant-improvement office project has confirmed its preconditions and can pursue only two optimizations. Option A is an enhanced filtration feature worth more points but requiring performance testing of installed systems. Option B is a policy-based feature worth fewer points, verifiable through a letter of assurance from the employer. The plausible mistake is picking Option A purely on points without asking whether the mechanical scope and testing schedule fit the project.
The better decision evaluates evidence burden alongside value. If the project cannot support testing in its timeline, Option A risks verification failure, and its points exist only on paper. Option B's smaller value is dependable because a signed attestation fits the project's capabilities. Why it matters: optimization selection is an investment decision under constraints, and building the habit of connecting points, scope, and pathway is what makes any similar comparison feel routine. Rehearse this trade-off with feature pairs from any two concepts until weighing evidence burden becomes automatic.
- Mistake: ranking optimizations by points alone
- Better: weigh evidence burden and project scope
- Why: unverifiable points deliver nothing at review
- Rehearse with feature pairs from different concepts
Worked scenario 2: a performance part misread as a paperwork task
Some feature parts demand measured conditions, not documents. A scenario asking how to verify such a part should point to on-site testing; answering with a specification or attestation shows the intent-versus-condition confusion.
Practice scenario (invented for study): a feature part sets a maximum measured level for an environmental condition in occupied spaces. A project team submits an annotated specification showing the installed equipment meets the limit on paper, and treats the part as complete. The mistake is category confusion: the part's claim is about the condition in the space, which drifts with installation quality, commissioning, and operation, so the framework calls for direct measurement of the built environment.
The better decision is to plan for performance verification of the actual condition, treating the specification as supporting context rather than proof. Why it matters: this confusion tests whether you understand what a requirement fundamentally asserts. Train the reflex with a two-question drill: what does this part claim, and can a drawing prove a claim about a living building? If the claim involves an environmental condition people experience, lean toward measurement. Apply the drill across Thermal Comfort, Sound, Air, and Light features to see the pattern hold across concept boundaries.
- Mistake: submitting design documents as measured proof
- Better: schedule verification of the actual condition
- Why: conditions vary even when specifications are correct
- Drill: ask whether a drawing could prove the claim
Reading feature language precisely: thresholds, compliance paths, and Innovations
Feature parts often offer multiple compliance routes and may pair a base threshold with an enhanced one. Read the exact condition, note alternate paths, and treat Innovations as a distinct proposal-based route outside the standard feature set.
Precision reading pays because feature language is conditional. Phrases distinguishing required actions from options, or a base level from a more ambitious level within the same part, change what a scenario's correct answer is. When studying, underline the operative verb in each part and any point where the text says a project may choose between routes. Ask which route fits which project profile, since scope and occupancy often steer the choice.
Innovations deserve separate handling: rather than a named feature, they let a project propose a strategy outside the standard's listed features, subject to review against defined criteria. In study terms, do not force every scenario answer into an existing feature; check whether the scenario is actually steering you toward an innovation proposal. Distinguishing named features from proposal-based pathways keeps you from inventing nonexistent requirements or overlooking a valid route the scenario deliberately describes.
- Underline operative verbs and conditional phrases in each part
- Note base versus enhanced levels inside a single part
- Innovations follow a proposal pathway, not a named feature
- Some scenarios describe strategies that fit no listed feature
Self-check drill and an adaptable preparation sequence
Run a feature-to-evidence mapping drill across all ten concepts, score yourself with a rubric, and sequence your study as framework first, concepts second, scenarios third. Repeat the drill at the end of each concept.
The drill: pick any ten feature parts from different concepts and, for each, write one line answering three questions — precondition or optimization, primary verification pathway, and one applicability condition. Score each line: two points if the pathway is correct and justified by the claim type, one point if correct but justified vaguely, zero if the pathway is wrong. A self-check milestone worth aiming for during review is consistently scoring eighteen or above out of twenty; treat it as a learning indicator of your mapping skill, not a prediction of exam performance.
A sequence that adapts to any schedule: first, learn the framework anatomy and verification pathways until the table in this guide is intuition; second, work through concepts one at a time, running the drill after each; third, shift to scenario practice, writing two-sentence justifications for every answer choice — the category, the pathway, and the consequence. Readiness checks before you finish: you can classify any sampled part by pathway without notes, you can state what certification consequence follows from a missed precondition versus a missed optimization, and you can explain why a specification cannot prove a measured condition. When those three checks pass without hesitation, your reasoning is in exam shape. For administrative details such as scheduling and eligibility, consult the issuer's site directly at wellcertified.com rather than relying on third-party summaries.
- Drill: ten parts, three answers each, scored out of twenty
- Milestone: sustained eighteen-plus indicates mapping fluency
- Sequence: framework, then concepts, then scenarios
- Readiness: pathway classification, consequence logic, intent-versus-condition all automatic
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.