Act A — The Offline-First Problem
Community health workers in rural Kenya operate in areas where mobile data connectivity is intermittent and sometimes unavailable for days at a time. They collect patient data, record home visit observations, and update maternal health monitoring records using Android tablets. The data needs to be stored locally when connectivity is absent and synced to a central health information system when connectivity is restored.
This is a well-studied problem in distributed systems. The architectural pattern — offline-first, eventual consistency, conflict resolution on sync — is documented in research literature and has been implemented in several open source frameworks. What the literature does not fully address is the specific challenge of health data conflict resolution: when a community health worker's offline record for a patient conflicts with a record updated by a clinic nurse during the same offline window, the resolution algorithm cannot simply "last write wins" — the clinical context of each record matters, and the resolution logic needs to be defined at the field level, not the record level.
Nadia has correctly identified this problem. She has read the existing literature. She needs to talk to someone who has implemented a field-level conflict resolution system in a production health data context and can tell her what approaches work and what the second-order problems are.
Act B — The Story
Nadia submitted a mentorship request to the MarketForge software mentorship platform. Her request: architect guidance on offline-first data sync conflict resolution for a health worker platform, field-level clinical data with multiple writer roles, Android tablet with SQLite local storage, central DHIS2 instance, two-week mentor engagement preferred with async written format.
Raj spent three years at Google on the data consistency systems that power Google Docs' offline mode, and four years since as an independent consultant working on open source offline-first health data systems, including two DHIS2-adjacent implementations in South and Southeast Asia. His platform profile listed field-level conflict resolution for health data as a specific area of experience. He had registered on the platform after contributing to a digital health open source discussion thread.
The platform matched Nadia's request to Raj's profile. He accepted the engagement.
Their exchange unfolded over fourteen days. Raj reviewed Nadia's current architecture document and provided written responses to four specific questions. His guidance on conflict resolution: implement a field-provenance model — each data field carries a provenance type (CHW observation, clinic measurement, automated calculation), and the resolution algorithm is defined by provenance priority per field type, not by timestamp. He provided a worked example of the data model and the conflict resolution algorithm, referenced from an open source implementation he had contributed to.
He also flagged a second-order problem Nadia had not yet reached: sync queue ordering under partial connectivity — a bug pattern where a device with intermittent connectivity generates a sync backlog whose processing order produces transient data inconsistencies visible to clinic staff during the sync window. He explained the ordering guarantee needed and the Redis queue pattern that resolves it.
Nadia's team implemented the field-provenance model. The sync queue ordering architecture was planned into the next sprint.
Act C — Why This Market Stays Broken Without Infrastructure
Raj had the specific knowledge Nadia needed because he had built the same system in a different context and encountered the same problems. His knowledge was not available in the literature at the level of actionable implementation guidance — it was in his head, built from two years of debugging production data in similar health worker systems.
Raj wanted to contribute this knowledge. He actively looks for open source projects and mentorship opportunities in digital health. He could not find Nadia's project — not because he was not looking, but because there is no mechanism that makes a Kenyan health tech company's specific architectural question visible to a London-based digital health architect who has solved the same problem.
Thin market infrastructure makes the technical specificity of Nadia's question matchable to the institutional knowledge in Raj's experience — peer knowledge exchange at the level of granularity where it is actually useful.
Characters are fictional. DHIS2, offline-first distributed health data systems, and community health worker technology challenges in Kenya are real. DeeperPoint is building the infrastructure this story describes.