Nairobi · Free evaluation sample
One resident.
Follow the connections.
Explore a small, downloadable example linking resident identity, household context, education, employment and health records.
A connected example
Start with one resident.
Explore existing Nairobi profiles across five domain areas. The diagram labels the basis of each association.
These seven CSV tables are flattened from 32 existing resident profiles. These are all 32 of the 113 supplied Nairobi profiles containing the four connected areas. They demonstrate usable joins within this sample; they do not prove independent joins across all city database tables.
Follow the supplied dates
Read the sequence.
Birth, school, contract and visit dates are retained from the source. Household formation dates describe the household entity.
Only supplied dates are included. Current household context does not establish where someone lived at an earlier event.
Inspect the join
Know what each connection means.
Every association resolves within this normalized sample. The evidence behind an association varies by source.
| Relationship | Basis | Matched rows |
|---|---|---|
households → residentsKey: citizen_id | Native member IDSelected citizen ID is present in the source household member list. Household attributes describe the supplied current context. | 32/32 |
education → residentsKey: citizen_id | Profile associationCitizen ID inherited from the enclosing supplied profile. This is a normalized profile association, not an independently tested database foreign key. | 161/161 |
contracts → residentsKey: citizen_id | Profile associationCitizen ID inherited from the enclosing supplied profile. This is a normalized profile association, not an independently tested database foreign key. | 32/32 |
patients → residentsKey: citizen_id | Profile associationCitizen ID inherited from the enclosing supplied profile. This is a normalized profile association, not an independently tested database foreign key. | 32/32 |
visits → patientsKey: patient_id | Profile associationPatient ID inherited from the enclosing health object; visit IDs are retained from the source. | 288/288 |
The join keys for profile associations are derived from the enclosing JSON object. Generated row locators are explicitly separate from original citizen, household, patient and visit IDs.
Measured sample results
Check the example yourself.
Results apply to this 32-resident extract. The downloadable Python script repeats the key integrity and chronology checks.
Take the example with you
Download the complete working sample.
Seven CSV tables, SQL schema and queries, Python loader, original profile JSON, field names, provenance and file hashes.
Scope and limitations
- 32 selected existing profiles demonstrate five domain areas. The cohort is not a representative sample of Nairobi.
- Education, employment and health records inherit their resident association from the supplied nested profile. This export does not establish independent cross-table database integrity.
- Household formation is an entity event. Current household membership is snapshot context; no resident joining date is supplied.
- Only supplied enrollment, contract and visit dates are shown. Gaps do not imply no activity or a complete life history.
- record_key and event_key are generated row locators, not original database primary keys. Native citizen, household, patient and visit IDs are preserved.
- This sample tests structure and navigation. It does not establish clinical correctness, population realism, causal effects or model performance.
Source snapshot: 2 July 2026. Sample build: 7 September 2026. Website release: V5.74. Evaluation follows the existing FCTE data licence.