System Pipeline — End to End 19/19 records verified
INPUT
Telegram
Natural conversation with @Health_bae_bot on iPad
ORCHESTRATION
n8n
Companion workflow + silent extraction layer
EXTRACTION
GPT-4o-mini
38 labels · 18 associations · valence −1→+1
STORAGE
Supabase
wellness schema · state_of_mind_records
BRIDGE
iOS App
HealthKitSyncBridge · SwiftUI · iPad
OUTPUT
Apple Health
State of Mind · HKStateOfMind · verified
Next: Apple Watch correlation · HRV + sleep vs extracted valence · infrastructure staged · 2–3 weeks data collection

The question

Health trackers ask you to report how you're feeling. They present scales, prompts, scheduled check-ins. The burden is always on the user to notice, assess, and record. The more faithful you are to the tracker, the more the tracking becomes its own cognitive task.

Bae is an investigation into whether that burden can be eliminated. The question: can emotional wellness signals emerge from natural ambient conversation — without any tracking action from the user?

Not a therapy tool. Not a journalling app. A companion that talks, listens, and — invisibly — extracts structured health data that Apple Health can receive and store.

How it works

Bae runs on Telegram as @Health_bae_bot. The persona is warm, curious, present — not clinical. The conversation is natural: checking in, discussing the day, following up on things said before. Nothing signals that wellness data is being collected, because nothing needs to be signalled. The extraction is silent.

Behind the conversation, a separate gpt-4o-mini instance reads each message exchange and extracts a structured Apple HealthKit State of Mind record: valence (−1 to +1), labels, associations, and kind. It applies this extraction only when the signal is meaningful — when conversation is thin, no extraction happens. Every extraction is logged regardless.

If the extraction produces a valid record, it queues in Supabase. An iOS app (HealthKitSyncBridge) polls for unsynced records and writes them into Apple Health — using the exact Apple HealthKit API, with exact enum values, so the data is real health data in the health ecosystem.

The signal problem

Apple HealthKit's State of Mind schema is specific. There are 38 label values and 18 association values — exact strings defined by Apple's API. The extraction model had to know these precisely. "Money" not "finances." "Romantic relationships" as a single string. Every deviation means a record Apple Health rejects.

This specificity is the point: Bae isn't producing an approximate emotional log. It's producing HealthKit-writable structured data — the same format a medical app would produce. The research question is whether the signal extracted from ambient conversation is valid enough to be clinically meaningful. That question requires HealthKit-grade data to investigate.

What the extraction produces

Extracted per message
valence — Double −1 to +1
kind — momentaryEmotion / dailyMood
labels — up to 38 Apple-exact values
associations — up to 18 Apple-exact values
Extraction rules
Skip when conversation is thin
Never reference extraction in conversation
Always log raw to extraction_events
Confidence score gates queue insertion

What 19/19 means

The first end-to-end verification: 19 records extracted from conversation, queued in Supabase, polled by the iOS app, written into Apple Health, and verified in the Health app — 19 of 19, zero lost, zero duplicates. The pipeline works.

This runs on an iPad. The iPhone was blocked by GE's enterprise MDM policy, which prevents trusting personal developer certificates. The iPad is unmanaged. The iOS app is a personal-team SwiftUI build — not App Store distribution, not TestFlight. The HealthKit sync is real: the data appears in the Apple Health app alongside step counts and heart rate measurements.

Apple Watch correlation — staged

The most important question is not whether the pipeline works. It's whether the extracted signal is real — whether the mood valence extracted from conversation correlates with objective physiological measures.

The infrastructure for that test is already built: a Supabase table for biometric records, a POST endpoint for Apple Watch data, and an extraction pipeline that produces timestamped valence scores. The remaining pieces: the iOS read-side for HRV and sleep data, and 2–3 weeks of data to run the correlation on.

When that correlation runs, it will either validate the hypothesis or falsify it. Either outcome is useful. The project isn't designed to confirm that ambient extraction works — it's designed to find out.

What connects to HDFC and IVR

Bae is the same pattern as HDFC — complexity absorbed at the system layer, invisible at the interaction layer. The user never sees an extraction event. They see a conversation. The routing logic, the schema compliance, the sync pipeline — all of it happens without asking the user to be aware of it.

And it connects forward to the IVR work: the IVR used conversational framing to guide users through banking without exposing the system's structure. Bae uses conversation to extract health data without exposing the extraction. In both cases, the interaction model and the technical model are deliberately decoupled.

The stack

Telegram · @Health_bae_bot n8n · companion + extraction WFs gpt-4o-mini · both sides Supabase · wellness schema SwiftUI iOS app · HealthKit sync Apple Health · final store

Next milestone

Apple Watch correlation: HRV + sleep vs extracted valence. Infrastructure staged. Needs iOS read-side + 2–3 weeks of data.

Related work

PRDY — reflective companion with memory → IVR — conversation absorbing system complexity →
← Previous
A1OS
Ask Rohan
Powered by reflective memory · Phase 1