Inspiration
Wearables collect plenty of numbers, but understanding what changed—and whether it deserves attention—is harder. We wanted to turn those signals into a useful conversation: a timely check-in that remembers your context and compares changes against your own usual patterns.
That became Signal2Care, an iMessage assistant paired with a wearable monitoring dashboard.
What it does
Signal2Care watches a simulated wearable stream and compares each signal with the person’s usual range for the same context, such as sleeping or being awake at a particular time of day.
When a change warrants attention, it can send a short iMessage check-in. Replies become context attached to that moment on the dashboard, helping connect the numbers with what the person reports without claiming what caused the change.
The assistant supports text, photos, and PDFs, with layered memory across conversations. The dashboard brings together signal charts, usual ranges, alert history, messages, and model activity. A recorded demo lets visitors explore the interface without API keys.
The wearable data is synthetic. Signal2Care is a prototype, not a medical device, and does not provide medical advice.
How we built it
We built the backend with Python and FastAPI, using Linq for iMessage connectivity. Memory combines message history, events, profile facts, a rolling summary, and recent conversation context, with keyword and embedding search for recall.
The monitoring pipeline separates computation from language generation. Code computes changes against personal baselines, Jev evaluates the computed state, and a code-based policy gate applies alert limits and cooldowns. The language model phrases a check-in using supplied evidence, followed by output validation.
The dashboard uses HTML, CSS, and JavaScript, hosted on GitHub Pages and backed by a Cloudflare Worker and D1. Phone numbers stay out of the dashboard service.
We used the Kiro IDE with steering documents to guide architecture, evidence requirements, and safety constraints throughout development.
Challenges we ran into
One challenge was deciding when a change deserves an interruption. We combined personal baselines, contextual comparisons, and alert controls to make check-ins more selective.
Another was keeping generated language grounded. We designed the pipeline so numerical evidence comes from code, while the model handles wording.
We also needed a repeatable demonstration without depending on live wearable access. A seeded simulator replays 28 days across three personas, allowing us to inspect different patterns consistently.
Accomplishments that we're proud of
We connected monitoring, conversational memory, and a visual timeline into one working prototype. A person can receive a check-in, reply through iMessage, and see that context alongside the signal that prompted it.
We also implemented consent commands, memory inspection and deletion, and code-enforced response boundaries.
What we learned
A useful health-related assistant needs more than fluent answers. It needs traceable evidence, clear boundaries, and careful decisions about when to speak.
Separating computation, policy, and language generation made the system easier to inspect and reason about.
What's next for Signal2Care
We want to evaluate alert quality more systematically, improve memory retrieval, and explore supported wearable integrations with explicit consent. The next step is testing how well the prototype balances useful check-ins with unnecessary interruptions.
Log in or sign up for Devpost to join the conversation.