Investigate a one-PSU stratum before silencing its variance warning

Identify what is solitary and at which design level

Capture the affected stratum, analysis population, design version and warning context using restricted identifiers where needed. Confirm that the flag concerns a primary sampling unit rather than one respondent or one business account. Several respondents inside the same selected organization do not automatically provide several independently selected primary units. Read the warning with the actual stage diagram, not only the row count in the export.

Lumley’s 2006 explanation distinguishes a non-certainty stratum with one sampled PSU, where the usual variance cannot be calculated, from a genuine certainty PSU whose first-stage contribution is different.

Record whether the condition exists in the original design, appeared after fieldwork loss or arose only in a particular analysis. Those paths call for different investigations. Do not label the unit certainty simply because it is the only one left. Certainty describes selection under the design, not an analyst’s confidence that the record is accurate.

Trace the condition to its design evidence

Compare the planned and actual selected primary units within the affected stratum. Check whether an identifier was reused incorrectly, a join lost a unit, a stratum label changed or a filter altered the analytical population. Retain the distinction between a processing error and a genuine missing or nonresponding unit. Correcting a verified join error is different from fabricating the absent evidence needed for an estimate.

If certainty selection is claimed, request the relevant population and selection documentation. A large organization may have been deliberately included, but its size alone does not establish the full design treatment or eliminate later-stage uncertainty. Keep the explanation bounded to the level at which the claim is supported. Ask what information would change the disposition and record any evidence the supplier cannot provide.

Obtain a justified analytical disposition

Ask the analyst to describe the available defensible responses in the context of this study. A documented coding repair, a methodologically justified combination of design strata, a different qualified uncertainty procedure or withholding an unsupported estimate may each arise in different circumstances. This lesson does not prescribe one universal repair. The record should explain the assumptions introduced and which inference they support.

Compare the proposed disposition with the intended research question rather than with the desired headline. Request a bounded sensitivity assessment where appropriate, clearly distinguishing a primary analysis from alternatives. Do not cycle through software settings until a warning disappears or the interval becomes acceptably small. If the same option name has different behavior across software versions, require current implementation documentation from the analyst instead of relying on an old tutorial.

Carry the exception into the release decision

Preserve the warning, verified cause, chosen treatment and owner’s reasoning beside the analysis version. Identify affected outputs and any result that remains unsuitable for the intended comparison. If a later data correction restores an omitted primary unit, revisit the disposition instead of leaving an earlier workaround in place. The exception record should be specific enough that another qualified analyst can understand why the treatment was chosen.

Explain the business consequence in ordinary language: a subgroup comparison may be uncertain, a table may need a limitation or a planned inference may not be available. Avoid implying that the respondent or organization is defective. The issue concerns what the realized design can support. Successful computation after a change is evidence that software ran, not proof that the uncertainty estimate has become defensible.

Make the reasoning concrete.

A fictional account survey raises a one-PSU warning after an export. An operations reviewer proposes marking the remaining organization as a certainty unit so the report will finish.

The team chooses the exception review and treats any unresolved inference as a reporting limitation, not a software nuisance.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Level

   Which stratum and sampling stage trigger the problem?

2. Origin

   Was the condition designed, lost in collection or created in processing?

3. Evidence

   What supports any claim of certainty selection?

4. Disposition

   Which analyst-approved treatment and assumptions apply?

5. Release

   Which outputs remain limited or require regeneration?

Watch for the wrong conclusion.

• Confusing one respondent with one primary sampling unit.
• Calling the only remaining unit a certainty selection.
• Choosing a variance option solely because it suppresses an error.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis. Sources support only specifically attributed principles. Platform guidance can change; legal requirements depend on jurisdiction and context. No measured results or named human reviewer are claimed.

• Thomas Lumley: Lonely PSUs (11 April 2006) →Primary methodological explanation · Supports: Dated conceptual distinction between certainty selection and a single non-certainty PSU; no current option recipe.