Scenario discrimination is where WELL v2 gets genuinely hard: a single building decision can sound like it belongs to several concepts at once, and the same strategy can be justified at different tiers and documented through different evidence pathways. The workable method is concept-triage: read the stem, name the occupant outcome in one phrase, classify whether the project faces a mandatory baseline gap or an elective enhancement, then select the answer whose evidence type fits. This guide demonstrates that method with two worked scenarios, a triage rubric, and an adaptable preparation sequence.
Distinguishing Preconditions from Optimizations Before You Compare Answer Options
WELL v2 divides strategies into preconditions, which every project must meet, and optimizations, which are elective achievements. Scenario decisions turn on that split: the project's starting condition tells you whether to close a baseline gap or pursue an elective.
A precondition establishes a health and wellbeing baseline that a project commits to as a condition of participation, while an optimization is a strategy a project elects and pursues to a defined achievement level. They differ in obligation, in how much choice a project has among them, and in the documentation each requires. When you read a scenario stem, your first classification is therefore not 'which feature?' but 'which kind of feature does this project need next?' A project describing a missing basic safeguard is answering a different question than one describing a project that has met its baseline and wants to push higher.
Apply the distinction by interrogating the stem's framing. If the narrative says the team is 'selecting strategies to earn higher achievement,' the stem is describing an optimization decision, and a baseline feature — however sensible in real life — is off-target. If the narrative describes a fundamental condition that is absent or unverified, the better decision is to close that gap before any elective. Practicing this one question — mandatory baseline or elective enhancement — narrows the plausible answers in your own practice items to those describing strategies at the right tier.
- Words like 'must,' 'baseline,' or 'all projects' point toward preconditions.
- Words like 'elective,' 'higher achievement,' or 'additional' point toward optimizations.
- If a stem shows a basic condition missing, close that gap before considering electives.
| Stem signal | Treat it as | Typical better decision | Evidence pathway |
|---|---|---|---|
| A basic safeguard is absent or unverified | Precondition gap | Address the mandatory feature first, then revisit electives | Design documentation or testing, per that feature part |
| Baseline met; team wants higher recognition | Optimization | Select the elective whose occupant outcome matches the stem | Per the part: assurance letter, annotated document, or test |
| Occupants report a measurable complaint | Performance condition | Match the concept to the outcome, not to the symptom word alone | On-site measurement or operational records |
| A design-phase choice is being made | Intent decision | Fix the concept-level strategy before drafting documents | Letter of assurance or annotated documents |
Telling Apart Air, Thermal Comfort, and Light When Symptoms Overlap
Air governs what occupants inhale, Thermal Comfort governs the body's heat balance, and Light governs visual and circadian conditions. When a stem mixes symptoms across these, name the physical variable being controlled before choosing a feature.
These three concepts overlap in ordinary language — 'stuffy,' 'glary,' 'stuffy and warm' — but they control different physical variables. Air features concern contaminant sources, moisture management, and freshness of inhaled air. Thermal Comfort features concern how the body exchanges heat: air temperature, radiant temperature from surfaces, humidity, and air speed, often with an emphasis on individual control. Light features concern visual performance and the biological effects of light exposure across the day, including circadian rhythm support. A useful probe for any symptom: does the stem name a substance, a heat sensation, or a timing-and-visibility condition?
Watch the boundary cases. Dampness and mold sit at the intersection of Air and Thermal Comfort because humidity drives both, so a stem about condensation on glazing requires you to decide whether the occupant outcome is inhaled-air quality or surface and heat-balance conditions. Afternoon drowsiness sits at the intersection of Light and Thermal Comfort, because warm zones, low stimulation, and weak circadian cues can each produce it. Train yourself to restate the stem as a single physical mechanism before you look at the options. A discipline worth holding in your own practice: the outcome clause should match exactly one candidate answer's mechanism — if two options fit your clause, the clause is too vague, so sharpen it until only one mechanism survives.
Worked Scenario 1: An Afternoon Complaint That Is Not an Air Problem
A complaint about afternoon heat and glare near west-facing glazing is a solar-exposure problem. The better response targets shading and thermal control, not a circadian lighting package that addresses biological rhythm instead of discomfort.
Scenario: occupants along a west-facing open office edge report 'drowsiness and heat' every afternoon. The design team, wanting to show a wellbeing strategy, proposes an enhanced circadian lighting optimization — brighter, cooler-toned light in the afternoon. That is the plausible mistake: the response latches onto 'drowsiness' and reaches for a Light-concept strategy. But the stem's mechanism is solar gain through west glazing raising radiant temperature and creating glare; the light package would not change either. The better decision is to treat this as a Thermal Comfort and visual-condition problem first — exterior or interior shading, and controllable thermal zones along the perimeter — and evaluate lighting only if a circadian gap remains after the discomfort is resolved.
Why it matters: choosing a strategy at the wrong concept level wastes budget on an intervention that leaves the complaint intact, and in WELL terms it mislabels the project's actual gap. A correct optimization pursued for the wrong outcome cannot be justified by the stem's own evidence. The transferable habit is to write the mechanism in one clause — 'west solar gain raises radiant temperature and glare in the afternoon' — and check each candidate answer against that clause. Any answer whose mechanism does not appear in your clause is a distractor, however attractive its vocabulary.
Worked Scenario 2: Choosing the Evidence Type for an Air Optimization
A design choice and a measured result require different evidence. Product literature shows intent, while annotated drawings with a professional assurance letter show design compliance, and on-site tests show performance. Match the evidence type the part describes.
Scenario: a project pursues an Air-concept optimization whose feature part concerns ventilation delivering sufficient outdoor air to occupied spaces. The team submits the ventilation unit manufacturer's specification sheet as its documentation. That is the plausible mistake: a spec sheet describes equipment capability, not what was actually designed for this project or what the system achieves in the occupied building. The better decision is to read what the part is claiming and supply evidence of that same kind — for a design requirement, an annotated mechanical plan plus the mechanical engineer's letter of assurance; for a measured condition, an on-site test or operational record showing delivery in the occupied spaces.
Why it matters: in WELL's verification framework, the strength of an optimization claim rests on the fit between the claim and the evidence. A well-chosen strategy can fail review when documented with the wrong artifact type. In your own practice sets, this is a productive stem to build deliberately: precise equipment data sounds persuasive, but it answers a different question than the one the part is asserting. Check that any wrong-evidence option you write actually mismatches the claim type; if it does, the elimination is defensible. The habit to build: after selecting a strategy, ask 'what does this part assert — an intention, a design condition, or a measured condition?' and let that verb choose your document.
Reading Verification and Documentation Language, and Where Ethics Draws the Line
Feature language signals its own documentation pathway: assurance letters attest professional decisions, annotated documents show requirements on plans, and tests confirm measured conditions. Ethics limits attestations to each signer's professional scope.
Learn the three common evidence forms as distinct tools. A letter of assurance is a professional attesting that a specific design or construction decision was made — it carries the signer's professional accountability. Annotated documentation takes plans, specifications, or policies and marks them up so a reviewer can locate the required elements. On-site verification measures the built condition after occupation. When you write or review practice stems, build the mismatches in deliberately: a design-phase question answered with a test result, or a performance question answered with a drawing, is exactly the kind of mismatch you want to catch on sight.
Ethics and professional standards enter through who may attest to what. An engineer can credibly assure mechanical design decisions; a contractor can assure installation; an owner or operator signs for policies and programs that belong to operations. When a stem asks who signs a given document, match the attestation to the signer's professional role and responsibility for that decision — the correct signer is the person who actually made or controls the choice, not the most senior person available. This also disciplines real projects: attestations made beyond one's scope are both an ethics problem and a verification failure.
A Four-Step Concept-Triage Exercise With a Self-Check Rubric
Rehearse a four-step triage on every scenario: name the occupant outcome, eliminate mismatched concepts, classify precondition versus optimization, then pick the evidence pathway. Score each step and treat eight-out-of-eight as a milestone, not a prediction.
Take any exam-style scenario question — from a practice set, or written by a colleague from a real project debrief — and work it on paper in four steps. Step one: before reading the options, write the occupant outcome in one clause ('afternoon heat and glare at the west facade'). Step two: list the two or three concepts the clause could touch and eliminate each mismatch with a written reason. Step three: classify the project's need as a baseline gap or an elective pursuit. Step four: identify which evidence type the surviving answer would require. Compare your paper trail to the answer's rationale, not just to the letter of the correct choice.
Score each step 0 to 2: 2 if you committed to the step in writing before looking at options, 1 if you reached it after, 0 if you skipped it. Eight out of eight on a fresh scenario is a useful learning milestone — it means the triage ran before guesswork — but it is a study benchmark, not a prediction of your exam score. Expected observations as you repeat this across ten or so scenarios: your outcome clause gets shorter and more mechanical, your eliminations start citing concepts by name rather than by feel, and the evidence-type step stops feeling like guesswork because you recognize the verbs in feature language.
- Outcome clause written before reading options: 0–2 points.
- Both plausible distractors rejected with named-concept reasons: 0–2 points.
- Precondition-versus-optimization classified correctly: 0–2 points.
- Evidence pathway matched to the part's claim: 0–2 points.
An Adaptable Preparation Sequence and Observable Readiness Checks
Build preparation in layers: one-sentence concept intents, then a feature map, then verification pathways, then timed scenario drills. Finish with readiness checks you can actually observe, and confirm scheduling details directly with GBCI.
A sequence you can compress or stretch: first, write a one-sentence intent for each WELL v2 concept in your own words and test them against boundary symptoms like dampness, glare, and drowsiness. Second, map each concept's features into two columns — preconditions and optimizations — so the tier distinction becomes visual rather than memorized. Third, sort the common evidence forms (assurance letters, annotated documents, on-site tests, operational records) against the kinds of claims they support. Fourth, run scenario drills through the triage rubric from the previous section, keeping a log of which concept your triage errors cluster in. Fifth, do mixed timed review where you apply all four triage steps under time pressure.
Readiness is observable if you define it that way. You are in reasonable shape for scenario work when you can state each concept's intent without notes; classify a fresh scenario's tier and concept in a single pass and defend both in writing; name the evidence type a feature part implies; and explain why the correct optimization in a worked stem serves the stated occupant outcome. Re-run your error log weekly and drill only the concepts where triage failed. One administrative note: for credential eligibility, scheduling, and current program details, rely on GBCI directly rather than on secondary summaries, since administrative specifics change and this guide deliberately avoids restating them.
- Layer 1: one-sentence intent per concept, tested against boundary symptoms.
- Layer 2: two-column feature map separating preconditions from optimizations.
- Layer 3: evidence forms sorted by the claim type they support.
- Layer 4: rubric-scored scenario drills with a concept error log.
- Layer 5: timed mixed review applying all four triage steps.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.