tzvaita/nyika-reg

# Nyika Community Registry A household registry for Nyika village. The guiding principle is **one identity, many programmes, one auditable history**: a household is registered once, and later programmes, campaigns and contributions attach to that single record over time, with a full audit trail. ## Scope All nine entities from the brief's minimum data model exist: Household, Person, Consent record, Programme case, Document record, Mobilisation campaign, Contribution record, Receipt record and the Audit event. Built: the registry and its verification queue, purpose-specific consent, the immutable audit trail, role-based access, the registrar workspace, assisted capture, the full six-item resident menu, one government-support workflow, one mobilisation campaign with reconciliation, and the pilot exports and data-quality report. **Not built:** WhatsApp/SMS messaging — its own work package in the brief, gated on provider contracting. Resident links are therefore sent by hand. **Excluded by the brief itself, not merely deferred:** plot and occupancy records, political contribution flows, USSD, and direct payment-provider API integration before provider approval. ## Governance rules These are structural, not policy notes. Changes that break them are defects, and `test/models/governance_test.rb` fails when one is broken. - **Field minimisation.** No national ID, health, income, disability specifics, or plot claims anywhere in the schema. Use `age_band` / `year_of_birth`, never a full date of birth; `location_description`, never GPS or plot title. - **Purpose-specific consent.** Consent is one row per purpose — village administration, communication, programme support, payment receipts and partner contact — carrying version, channel and withdrawal status. Never a single blanket flag. Withdrawal is recorded; the row is never deleted. - **Immutable audit.** Every sensitive change records actor, timestamp, old value, new value, reason **and source channel**. Records ar …