KinKeep — From Weak Signals to Coordinated Care

KinKeep turns subtle changes in health and daily routines into bilingual check-ins, explainable family summaries, and consent-based, human-approved care actions.

Comment

Inspiration

KinKeep started with a simple observation: health data is not the same as care.

A wearable can show that someone slept less, walked fewer steps, or had a higher resting heart rate. But numbers alone do not ask how the person feels, connect several small changes, or help a family member living far away decide what to do next.

A general AI assistant is powerful when someone knows what to ask. KinKeep is designed for the moments before that: noticing a meaningful change, starting a low-friction check-in, preserving the person's consent, and helping the right family member follow through.

My long-term vision is a health-connection layer for people who care about someone they cannot be with every day. KinKeep's first use case is helping adult children support aging parents, because the need is concrete and subtle changes can easily be missed. Over time, the same model could support partners, relatives, and close friends living apart.

What it does

KinKeep provides two connected experiences.

Parent experience

The parent sees a bilingual companion rather than a complex health dashboard. They can speak, type, or use short suggested replies. KinKeep can combine optional health signals with conversations about symptoms, meals, sleep, mood, and daily routines.

In the demonstrated care episode, synthetic sleep, activity, and resting-heart-rate signals change together relative to the parent's personal baseline. KinKeep starts a gentle check-in, asks about knee discomfort, checks for warning signs, and asks for consent before sharing the episode reply and requesting family follow-up.

Family experience

The family receives an explainable follow-up rather than another stream of numbers. They can see:

  • what changed from the person's own baseline;
  • what the parent reported;
  • what is still uncertain;
  • three proportionate follow-up options;
  • which actions require human approval;
  • the resulting owners, deadlines, follow-up, and escalation conditions.

After the family approves a plan, the demo can advance to a simulated follow-up outcome: Elena has called, the parent has eaten, knee discomfort has improved from 4/10 to 2/10, and the episode is closed.

KinKeep also includes real voice transcription and meal-photo understanding when OpenAI services are configured, a user-confirmed WhatsApp handoff, and a separate synthetic wandering-risk scenario. Wearables add useful context, but they are not required for the broader product vision.

Try it live:

No login is required. Both surfaces support English and Simplified Chinese. Open both surfaces in the same browser profile to see demo state updates as consent, approval, and follow-up decisions are recorded.

Demo boundary: All wearable and location signals and all displayed follow-up outcomes are synthetic demo fixtures. KinKeep is non-diagnostic and does not contact clinics or emergency services. WhatsApp handoff is user-initiated; no message is sent automatically.

What I added during OpenAI Build Week

KinKeep existed as an earlier prototype before Build Week. It already included the bilingual parent and family experiences, simulated wearable data, meal and voice features, and a synthetic wandering-risk demonstration.

During OpenAI Build Week, I used Codex to extend the prototype in two major waves.

1. A complete interactive Care Episode Loop

The first Build Week increment (commit d1d1c74) added a connected episode that can:

  1. consolidate several synthetic health signals against a personal baseline;
  2. capture the parent's structured replies and consent;
  3. synchronize the episode across the parent and family views within the same-browser demo;
  4. present evidence, uncertainty, and three care-plan options;
  5. require family approval before creating consequential actions;
  6. create a demo task plan with named owners, deadlines, and escalation conditions;
  7. run a reviewer-triggered simulated follow-up and record the outcome.

2. Consent-led family contact and safer interaction

The second increment (commit 6cdac5a) added and refined:

  • a consent-first contact flow: KinKeep provides safety guidance, asks whether family should be contacted, and lets the parent choose who to contact;
  • a WhatsApp handoff that opens a contact-specific pre-filled draft; the user still reviews the message and presses Send, and KinKeep does not claim delivery;
  • family phone numbers configured through server-side environment variables rather than embedded in the client bundle;
  • a typed nine-state escalation model representing possible WhatsApp handoff, primary push or multichannel contact, and backup-contact acknowledgement outcomes; the demo exercises selected states rather than claiming an automatic nine-step progression;
  • time-aware greetings and meal prompts, abdominal-pain safety checks, and optional read-aloud guidance;
  • improved mobile behaviour, consistent bilingual copy, and an automated test suite expanded from 3 to 12 tests.

3. Final release hardening

The final Build Week pass added the Sites/Vite build plugin and submission materials, fixed Chinese IME Enter handling so confirming a candidate does not send partial text, synchronized package metadata, and committed the deployment packaging required for a fresh clone to build consistently.

How I built it

KinKeep is built with Next.js, React, TypeScript, and Tailwind CSS. It runs through vinext/Vite on Cloudflare Workers and is deployed with OpenAI Sites.

The OpenAI layer has clearly scoped responsibilities:

  • GPT-5.6: short, grounded bilingual companion replies and schema-constrained meal-photo understanding through the Responses API;
  • OpenAI speech-to-text: gpt-4o-mini-transcribe transcribes browser-recorded voice server-side and returns editable text; after the user confirms and sends it, the same deterministic symptom-routing flow handles the message;
  • Deterministic TypeScript: symptom branches, danger-sign checks, consent, contact selection, family approval, owners, deadlines, and escalation states.

Model output cannot invent health evidence, bypass consent, choose a care plan for the family, or contact a clinic or emergency service.

The two demo views use typed CareEpisode and CareEscalation records stored in browser storage, with browser events keeping them aligned within the same browser profile. This is a transparent prototype mechanism, not a claim of production cross-device or clinical infrastructure.

For WhatsApp, contact numbers are configured server-side rather than shipped in the client bundle. The server creates a contact-specific wa.me handoff, but the user remains responsible for reviewing and sending the message.

I used Codex as an engineering partner throughout Build Week. Its contribution was concrete:

  • translating the care flow into typed episode and escalation states so transitions are explicit and auditable;
  • refactoring the parent and family experiences to read from one synchronized episode;
  • implementing and maintaining a 12-test suite: three rendered-output tests plus focused tests for escalation helpers, transcription, and WhatsApp handoff;
  • debugging cross-view state changes, mobile rendering, deployment packaging, and Chinese input behaviour;
  • keeping extensive bilingual interface copy consistent across both experiences while the workflow evolved.

Codex accelerated implementation, refactoring, debugging, and verification. I remained responsible for product scope, safety rules, review, integration, and every consequential care boundary.

Challenges I ran into

The main product challenge was preventing KinKeep from becoming either a generic chatbot or a noisy health-alert dashboard.

The useful experience sits between those extremes: flexible enough for natural conversation, but structured enough to explain why something changed and what should happen next. The model can make interaction more natural, but it must not guess medical risk, invent evidence, or make high-impact decisions.

Another challenge was connecting two people without ignoring privacy or autonomy. The parent and family need different information and controls. The parent must decide whether and whom to contact; the family must understand the evidence and approve consequential follow-up.

The engineering challenge was keeping both views synchronized while making the demo reproducible, bilingual, mobile-friendly, and honest about which inputs and outcomes are simulated.

Accomplishments that we're proud of

I am proud that KinKeep goes beyond detecting a health signal and demonstrates a complete interactive demo loop across two connected experiences.

The prototype can:

  • combine several weak signals instead of reacting to one isolated number;
  • compare changes with the person's own baseline;
  • start an accessible bilingual check-in using voice, text, or suggested replies;
  • check warning signs through deterministic logic;
  • request consent before sharing the episode reply and requesting follow-up, then let the parent choose which family member to contact;
  • present evidence, uncertainty, and multiple follow-up options;
  • pause consequential actions for human approval;
  • create a demo task plan with owners and target times, then let the reviewer simulate the 15:00 follow-up and record a synthetic outcome.

I am also proud of the boundary between AI and deterministic software. GPT-5.6 makes conversation and multimodal understanding more natural, while explicit code controls consent, permissions, care-plan state, and escalation. This keeps the experience useful without allowing the model to act as a doctor or take control away from the family.

Most importantly, KinKeep demonstrates the idea behind its name: noticing a small change, helping people respond, and turning everyday concern into coordinated care.

What I learned

The most useful health product is not necessarily the one that generates the most alerts. It is the one that helps people understand what changed, decide whether action is needed, and complete the follow-up.

I also learned that AI and deterministic software have different strengths. GPT-5.6 is valuable for grounded bilingual interaction and multimodal understanding. Explicit code is better for consent, permissions, escalation, and auditable state transitions.

Finally, I learned that a focused first use case does not require a narrow long-term vision. Aging-parent care gives KinKeep a concrete starting point, while the underlying need — caring for someone you cannot be with every day — is much broader.

What's next for KinKeep

The next steps are:

  • real Apple Health, Health Connect, and phone-health integrations;
  • a production backend for accounts, permissions, longitudinal profiles, and cross-device synchronization;
  • production notification channels with delivery and acknowledgement tracking;
  • more non-wearable inputs, including simple check-ins, voice notes, meal photos, and uploaded health reports;
  • user testing with families, followed by carefully scoped pilots with community and care partners.

Over time, KinKeep can expand beyond aging-parent care to support partners, relatives, and close friends who want to stay connected around everyday wellbeing without turning care into surveillance.

KinKeep — notices the change, checks in first, and tells you when you're needed.

Built With

  • cloudflare-workers
  • codex
  • gpt-5.6
  • next.js
  • node.js
  • openai
  • openai-api
  • react
  • speech-to-text
  • tailwind-css
  • typescript
  • vinext
  • vite
Share this project:

Updates