# Household Information Methods Audit — Codebook v0.2

Status: frozen after eight-paper pilot  
Date: 2026-09-26  
Unit of coding: one published paper, unless `coder_note` identifies multiple studies  
Pilot set: S03, S05, S06, S10, S21, S23, S24, S25

## Purpose

This codebook records what a study's methods can support about household information work. It does not score research quality, estimate prevalence, infer product requirements, or treat an unmeasured phenomenon as absent.

Only the exact paper from a publisher, university repository, research institution, or author archive may support full-text coding. Competitor webpages, product documentation, marketing reports, derivative summaries, and search snippets are excluded.

## Missingness vocabulary

- `unclear`: the paper was checked, but the available description does not permit a reliable yes/no decision.
- `not_applicable`: the field does not logically apply to the design, such as household participation structure in a literature review.
- `not_coded`: the field has not yet been assessed. This is a workflow state, not evidence, and is not allowed in a completed verified-layer record.
- `no`: the methods or reported evidence positively support absence of the coded feature from the study design; it never means the phenomenon was absent in participants' lives.

## Evidence levels

`verification_basis`

- `full_text`: methods and relevant results/discussion were checked in the exact paper.
- `abstract`: only the abstract or an extended abstract was checked.
- `metadata`: bibliographic metadata only.

The detailed fields below are public-analysis eligible only when `verification_basis=full_text`. Abstract and metadata records must use `not_coded` for fields that require full text.

## Identification and inherited context

| Field | Allowed values | Rule |
|---|---|---|
| `record_id` | S01–S60 | Stable ID from the evidence map. |
| `citation_short` | text | Short author-year label; not a substitute for the bibliography. |
| `source_url` | URL | Exact academic paper or DOI. |
| `evidence_relation` | direct / adjacent / mechanism_only / boundary | Inherited from the evidence map and retained to prevent overgeneralization. |
| `unit_of_analysis` | individual / dyad / household / family_network / artifact / literature | What is actually analyzed, not merely who was recruited. |

## Study design and data

### `design_family`

One primary value: `qualitative`, `survey`, `diary`, `experiment`, `review`, `scale_development`, `trace_log`, `mixed`, `theory`.

- Choose the design that generates the main claim.
- Use `mixed` only when two or more distinct empirical approaches materially support the main claim.
- A study using interviews alongside a diary to explain diary entries remains `diary` if the diary is the organizing design.

### `data_source`

Semicolon-separated values from: `interview`, `observation`, `artifact_walkthrough`, `diary`, `questionnaire`, `system_log`, `experiment`, `document_analysis`.

- Code only data actually analyzed.
- Screen captures intentionally elicited and inspected by researchers count as `artifact_walkthrough`, not `system_log`.
- A research diary is `diary`, not a naturally occurring household artifact.

### `temporal_design`

`point_in_time`, `short_longitudinal`, `longitudinal`, `retrospective`, `not_applicable`, `unclear`.

- `point_in_time`: one session or one collection wave.
- `short_longitudinal`: repeated or continuous collection for less than three months.
- `longitudinal`: three months or longer, or an explicitly longitudinal multiwave design.
- `retrospective`: reconstruction of a prior period is the principal temporal strategy.
- Reliability retesting alone does not turn the substantive study longitudinal; record the retest in `coder_note`.

### `participation_structure`

`single_member`, `dyadic`, `multi_member`, `household_as_unit`, `non_household`, `not_applicable`, `unclear`.

- `single_member`: one member reports, even if they report about others.
- `dyadic`: two members of the same relationship provide analyzable data.
- `multi_member`: two or more members provide data, with member-level perspectives retained.
- `household_as_unit`: the household is sampled and analyzed as a collective case; use only if individual perspectives are not the principal analytic structure.
- `non_household`: participants or tasks are outside a household setting.

### `multi_perspective_data`

`yes`, `no`, `not_applicable`, `unclear`.

`yes` requires data from at least two members of the same household or couple. A participant's account of another person is `no`. A small matched subsample is `yes` only if it materially enters the reported analysis; otherwise code `no` and note it.

## Observability fields

All fields in this section use `yes`, `no`, `not_applicable`, or `unclear`.

The suffix “observed” means evidenced in the study's analyzed material, not necessarily witnessed live by a researcher. `direct_behavior_observed` is the narrower field for witnessed or instrument-recorded behavior.

For literature reviews, every observability field in this section is `not_applicable`. The review's data are publications; coding the presence or absence of primary-study phenomena at review level would mix units and create false negatives. Primary studies represented in a review may be coded separately if they enter the corpus in their own right.

### `direct_behavior_observed`

- `yes`: researchers observe behavior as it occurs, capture an instrument-generated behavioral trace, or measure performance in a task.
- `no`: evidence consists of recall, questionnaire, interview, document review, or static artifacts only.
- A participant-completed diary is self-report unless passive capture or corroborating trace data are present.

### `artifact_examined` and `artifact_type`

- `artifact_examined=yes` only when researchers inspect naturally occurring or participant-created information objects such as lists, calendars, messages, folders, or screen organization.
- Research instruments created solely for the study, including questionnaires and elicited diaries, do not count.
- `artifact_type` must name the object when `yes`, and must be `not_applicable` when `no` or `not_applicable`.

### `system_trace_examined`

`yes` requires automatically recorded events, logs, timestamps, interaction histories, or comparable traces. Screenshots and researcher notes are not logs.

### `self_report_only`

- `yes`: all substantive empirical evidence comes from participant recall, interviews, questionnaires, or participant-entered diaries.
- `no`: at least one analyzed source is behavioral performance, direct observation, a naturally occurring artifact, or a system trace.
- Literature reviews are `not_applicable` because their data are publications rather than participant self-report.

### `cross_medium_observed`

`yes` requires evidence spanning at least two of these medium classes: paper, digital, interpersonal, physical/spatial. Multiple digital applications are one medium class. Merely mentioning other media is insufficient.

### `handoff_observed`

`yes` requires analyzed evidence of information, requests, tasks, or responsibility passing between people or between a person and a system. General claims that couples specialize are insufficient unless a transfer or handoff is part of the evidence.

### `access_asymmetry_observed`

`yes` requires analyzed evidence that people differ in visibility, permission, possession, availability, or practical access to information. Generic individual differences are not access asymmetry.

### `version_conflict_observed`

`yes` requires two or more conflicting states, duplicates, outdated copies, or explicit reconciliation/checking of versions. Distribution across locations alone is not a version conflict.

### `responsibility_disagreement_observed`

`yes` requires member-level evidence that perceived responsibility differs, or observed negotiation/dispute over who is responsible. Measuring allocation alone is not enough.

## Outcomes and method reach

### `outcome_measurement_mode`

One value: `behavioral`, `self_report`, `objective_artifact`, `mixed`, `none`, `not_applicable`, `unclear`.

- `behavioral`: task performance or recorded action is the principal outcome.
- `self_report`: participant-reported state or result.
- `objective_artifact`: outcome is derived from a naturally occurring artifact or system record.
- `mixed`: at least two modes materially support the outcome.
- `none`: empirical work describes process or state without a distinct outcome.

### `validated_measure_used`

`yes`, `no`, `mixed`, `measure_under_validation`, `not_applicable`, `unclear`.

- `yes`: an established measure is used for a substantive construct.
- `mixed`: a review or study includes both validated and nonvalidated measures.
- `measure_under_validation`: the focal measure is being developed or validated in this paper.
- Do not reproduce proprietary or copyrighted scale items.

### `method_visibility`

Semicolon-separated values from `process`, `state`, `outcome`, `mechanism`.

- `process`: sequence, transition, coordination, or work over time.
- `state`: arrangement, distribution, inventory, or condition at a point.
- `outcome`: consequence or completion state.
- `mechanism`: a manipulated or modeled causal/cognitive operation.

Code what the method supports in this paper, not every theoretical possibility of the method.

## Interpretive fields

### `primary_method_strength`

One factual sentence linking a method feature to what becomes visible. Avoid rankings and generic praise.

### `primary_method_blind_spot`

One factual sentence describing what the design cannot establish. Phrase this as a support boundary, never as proof that an unmeasured phenomenon did not occur.

### `evidence_location`

For `full_text`, name the relevant section and page/table/figure where available. A DOI, abstract, or generic “paper” is insufficient.

### `coder_confidence`

`high`, `medium`, `low`.

- `high`: explicit method/result language supports the code.
- `medium`: the code is supported but terminology or reporting leaves a bounded ambiguity.
- `low`: competing interpretations remain; route to review and exclude from public counts until resolved.

### `coder_note`

Record exceptions, small analytic subsamples, study-versus-paper distinctions, and unresolved coding questions. Do not add product implications.

## Cross-field validation

1. Completed pilot records must be `verification_basis=full_text`; no detailed field may be `not_coded`.
2. `self_report_only=yes` and `direct_behavior_observed=yes` cannot coexist.
3. `artifact_examined=yes` requires a concrete `artifact_type` and `artifact_walkthrough` or `observation` in `data_source`.
4. `artifact_examined=no` requires `artifact_type=not_applicable`.
5. `system_trace_examined=yes` requires `system_log` in `data_source`.
6. `multi_perspective_data=yes` requires `participation_structure` of `dyadic` or `multi_member`.
7. `design_family=review` requires `data_source=document_analysis`, `temporal_design=not_applicable`, and `self_report_only=not_applicable`.
8. `coder_confidence=low` records cannot enter published numeric claims.
9. `evidence_location` is mandatory for all full-text records.
10. Competitor brands and competitor-owned URLs are prohibited in every field.

## Pilot decisions incorporated in v0.2

1. Review-level observability fields are `not_applicable`; primary-study phenomena are not recoded as if the review itself observed them.
2. Reliability retesting alone does not change a substantive cross-sectional study to longitudinal; retest timing stays in `coder_note`.
3. Guided researcher inspection of static screenshots is `artifact_walkthrough`, never `system_log`.
4. Event-contingent participant diaries remain `self_report_only=yes` unless behavior is independently captured or corroborated.
5. `household_as_unit` is retained for collective cases; `multi_member` is used when member-level perspectives are retained. Ambiguous reports use `unclear` rather than inferring structure.

## Freeze note

The field set and definitions are frozen for the first-pass coding of the verified core literature. A later version may clarify examples, but changing allowed values or decision boundaries requires a version increment, change log, revalidation of all coded rows, and regeneration of every derived count.