A resident registry looks like a list: names, birthdays, addresses. That is the demo. The working system is four linked problems, and each one changes the schema and the screen.
1. Identity
The same person arrives as "Maria Santos", "Ma. Santos", and "M. Santos". A birthdate is missing or off by a year. A household moves and the address changes, but the resident record should not. The registry needs a stable resident identity before it needs a pretty table.
In practice that means search that works across name variants, household codes, and addresses; a soft delete so a correction does not erase history; and an audit trail so a change can be explained later. The registry is a record of corrections, not a one-time list.
2. Household
A resident is not a row. They belong to a household, with a relationship to the head, a shared address, and a family composition that changes. The registry has to answer "who else lives there?" and "which household is this child in?" without making staff maintain two copies of the same address.
The household is also the unit for many programs. Sector tags, vulnerability flags, and notes often belong to the household or to a member within it. If the model only stores a resident, those links get flattened into text fields and stop being reportable.
3. Geography
Every record sits in a barangay. Population counts, sector lists, maps, and reports all depend on that link. The barangay is not a label on a form; it is a dimension of the data.
Once the geography is real, the reports become possible: residents per barangay, households per barangay, sex and age breakdowns, and household locations on a map. Without it, the registry can print a list but cannot answer a question.
4. Reporting
The reason to keep the registry is to produce a number someone trusts. The counts have to reconcile: total residents, households, barangays, and the breakdowns by sex, age, civil status, and sector.
Reporting is not a separate module bolted on at the end. It is a test of the model. If the registry cannot produce a consistent population count, the data model is usually the problem.
What this means for the build
Separate the resident, household, and barangay records. Use foreign keys, not text fields. Keep an audit trail for corrections. Treat imports as a queue of changes that need review, not a one-time upload that ends the work.
The screens follow from the model: search with filters, a resident profile with household composition, a barangay view, and reports that export. The dashboard is a summary of the same data, not a different source of truth.
Resident data is sensitive. That is why the system is built to run locally: on a laptop or LAN, not a hosted demo with someone else's records. The screens on the Resident Hub page use a generated demo dataset.