> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/analytics/use-case-digital-household-welfare-profiling-and-proactive-social-support-analytics/5.-algorithmic-household-assembly-and-graph-theory.md).

# 5. Algorithmic Household Assembly and Graph Theory

A critical theoretical insight driving the design of this architecture is the recognition that while state registries almost exclusively maintain records on *individuals*, socioeconomic welfare, poverty, and resilience are fundamentally experienced and mitigated at the level of the *household*. Because very few sovereign jurisdictions maintain a dedicated, real-time, and legally binding "Household Registry," the Analytics platform must construct this entity dynamically through code.

## 5.1 Programmatic household construction

The system utilizes applied graph theory and a cascading set of deterministic rules to programmatically assemble disparate physical persons into logical, cohesive household units. Each assembled unit is assigned a unique, hashed system surrogate key (e.g. `Household_ID`), to which the individual profiles of all members are tethered. The algorithm evaluates relationships across three primary vectors:

1. **Direct kinship vectors:** The system parses the Vital Statistics and Population registries to map definitive legal and biological connections, primarily focusing on "spouse–spouse" and "parent–child" relationships. These form the nucleus of the household graph.
2. **Lateral and spatial vectors:** To account for multi-generational or non-traditional family structures, the algorithm cross-references the Real Estate Cadastre with residential registration (domicile) data. It identifies lateral kinship (e.g. grandparents, adult siblings) residing at the exact same geographic property code and exhibiting patterns of a shared economic unit.
3. **Temporal and exceptional validation:** The algorithm incorporates temporal logic to prevent the artificial fracturing of the household's economic profile due to temporary administrative anomalies. For example, a dependent university student temporarily registered at a dormitory address is algorithmically retained within the core economic household of their parents, provided financial dependency links (such as tuition payments or shared health insurance) remain active.

This continuous, daily recalculation of the household graph ensures that the state's view of the family unit is never static, instantly reflecting births, deaths, divorces, and spatial migrations without requiring citizens to manually update a central family ledger.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/analytics/use-case-digital-household-welfare-profiling-and-proactive-social-support-analytics/5.-algorithmic-household-assembly-and-graph-theory.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.