Exploit LSMS+ individual/intra-household (male vs female) disaggregation — new feature direction

[ligon]

What LSMS+ is and why it matters

The WB LSMS+ program collects individual-disaggregated, intra-household data — interviewing multiple household members (notably men and women) separately and self-reporting on asset ownership, employment, entrepreneurship, financial inclusion, and decision-making — rather than collecting one household-head report. This enables intra-household / gender analysis (who owns what, who decides, who works) that a single household-level value erases.

We currently exploit none of this — our harmonization collapses to household-level (or a single roster). This is a distinct, complementary direction from the WB-parity (agricultural-productivity) pass just completed.

What's actually in the repo

• Confirmed LSMS+: Cambodia 2019-20 (KHM_2019_LSMS-PLUS_v01_M) — carries individual_cover + individual labor modules; the clearly-marked LSMS+ survey in the library.
• Needs a wave-level audit: the broader WB LSMS+ pilot set was Cambodia, Ethiopia, Malawi, Tanzania. For Ethiopia/Malawi/Tanzania we carry the LSMS-ISA panels (ESS/IHPS/NPS), not surveys labeled "Plus" — but the LSMS+ individual-disaggregated modules (per-respondent asset ownership / decision-making) may be embedded in specific ISA waves, or exist as separate surveys not yet in the repo. Step 1 of this work is to confirm exactly which of our waves carry the respondent-disaggregated modules.

The ask

Design features that preserve the respondent / individual dimension — who (male/female household member) reported a value — instead of collapsing to one household figure. Candidate features (keyed at individual grain, e.g. (t, i, pid[, item]) with a respondent/sex axis):

• individual asset ownership (sole/joint, reported vs documented) — the flagship LSMS+ module;
• individual decision-making / control over assets, income, plots;
• individual financial inclusion (accounts, mobile money, borrowing);
• per-respondent time use / employment (extends our existing people_last7days).

This fits the library philosophy cleanly: it is item/individual-level detail preserved, not an aggregate — exactly the "harmonize the interface, keep the detail" principle. Some scaffolding already exists: anthropometry and people_last7days from the parity pass are already at (t,i,pid) individual grain.

Approach

1. Audit: enumerate which library waves carry LSMS+ individual-disaggregated modules (start: Cambodia 2019-20; then Ethiopia/Malawi/Tanzania ISA waves; flag any standalone LSMS+ surveys we should ingest via the add-wave path).
2. Design the respondent axis: a shared convention for "reporting member" / sole-vs-joint ownership so the male/female perspectives are first-class index levels, not lost.
3. Wire features per the parity-loop machinery (item-level, adversary-verified, data-driven partials), reusing the by-gap/disjoint-file orchestration.

References

• Cambodia LSMS+: lsms_library/countries/Cambodia/2019-20/
• WB-parity pass (individual-grain precedent — anthropometry, people_last7days): slurm_logs/2026-06-14_parity_loop/HANDOFF.org, PRs feat(parity): GAP 5 — item-level anthropometry (t,i,pid) across 5 LSMS-ISA countries #434–feat(parity): GAP 3 — labor (plot_labor + people_last7days) across 7 LSMS-ISA countries #435
• Related future-work: Extend the WB-parity item-feature stack to non-ISA countries (where survey modules permit) #438 (extend parity stack to non-ISA countries)

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

[ligon]

Scope (scoping session, no data access)

Full design doc committed: slurm_logs/DESIGN_lsms_plus_individual_disaggregation_2026-06-14.org (branch claude/trusting-goldberg-7i60sv, commit 78ccc5a).

Decisions locked

• Respondent/owner axis: owner-expansion grain (t, i, j, pid) — one row per (household, harmonized asset-type j, owner pid); joint ownership ⇒ multiple rows. Sex is joined from household_roster on pid, never baked in (mirrors anthropometry); ownership types / rights / tenure are reported boolean columns; proxy rows flagged; no aggregates stored (gender gaps, rates, shares → transformations).
• Breadth: Cambodia-first vertical slice, proposed for a data-enabled session (this environment has no WB API key / DVC cache, so the column-level audit + build + verification can't run here).

Audit (doc-level)

• Cambodia 2019-20 is the one confirmed, self-contained LSMS+ survey: individual_cover.dta (respondent spine) + 32 hh_sec_* files; only sample/cluster_features/household_roster wired today. The a/b/c sections hh_sec_16a…20b are the likely individual asset/rights modules — exact section→module map is audit step 1 (questionnaire PDF + .dta labels).
• Ethiopia/Malawi/Tanzania: ISA panels, not "Plus" surveys — individual modules may be embedded (e.g. Ethiopia ESS4 2018-19) or standalone; needs a data-access audit, wire-what-exists. Nepal/Sudan would be add-wave ingestion.
• Base branch: the precedent (anthropometry/people_last7days at (t,i,pid), harmonize_* infra, transformations layer) is on development, not master → implementation must branch from development.

Candidate features (Cambodia)

Feature	Grain
individual_assets ⭐	(t,i,j,pid)
financial_inclusion	(t,i,pid)
decision_making	(t,i,pid,domain)
people_last7days (+time-use)	(t,i,pid) (Cambodia add)

Execution sequence (each gate green before the next): Unit #0 label foundation (harmonize_asset + canonical-schema entries + test_schema_consistency) → GAP 1 individual_assets → GAP 2 financial_inclusion → GAP 3 decision_making → GAP 4 people_last7days. Per-feature artifact pattern + adversary-check + cold-build + test-gate, per the parity loop. Cross-country extension pairs with #438.

Open sub-decisions for the build (in the doc): land/dwelling type-level vs parcel-level asset_id; pid keyspace match per wave; Cambodia API hygiene (deprecated imports, stale CONTENTS.org).

---

Generated by Claude Code