2026 · Android (Kotlin, Jetpack Compose, Room) · sole author
PhoneMood is a direct follow-up to a study I co-authored. Using PISA 2022, we examined digital self-regulation before sleep and emotional control among 19,779 adolescents in Canada and Hong Kong, and found associations at both the student and the school level. Working on it left me with three problems that the design could not solve.
The exposure was measured once. A single questionnaire item about turning off notifications at bedtime stood in for months of behavior. One retrospective answer cannot describe a habit.
People do not recall their own use accurately. Retrospective estimates and device records disagree, and the part that goes missing is exactly the brief, repeated checking that is hardest to reconstruct. Self-report tends to understate it, so the pattern is invisible at the resolution a survey can reach.
A phone is a platform, not an activity. Total screen time treats messaging a friend, reading for class, and scrolling a feed as one exposure. What matters is the content, and the survey could not see which of them a student was doing.
PhoneMood is an attempt to build the instrument those three problems ask for: observation at the resolution the behavior actually happens, kept at the level of the individual app rather than the device, with a report of subjective experience close enough in time to be compared against it.
It records active phone and app use in the foreground, then asks for a 1–10 mood rating after a configurable amount of use, through either a notification or a floating card. It supports snoozing, dismissal, and pausing, keeps daily and multi-day views, and exports observations, model inputs, and data-quality metadata together as JSON. It runs entirely on the device, holds no account, and does not request internet permission.
Recorded phone use, mood ratings, and answered versus issued prompts on one screen. Synthetic demonstration data.A mood rating requested after 30 minutes of active use. Synthetic demonstration data.Daily mood across a selected period, with the underlying records available. Synthetic demonstration data.
Measurement decisions
Design choice
Why it changes the interpretation
Active use is separated from elapsed session time
A locked screen during a session should not count as use
Unanswered prompts, real response times, and monitoring gaps are all retained
Missing observations should stay visible in the analysis
Within-session change and conditional app associations are modeled separately
These answer narrower questions than comparing raw mood averages
Observations, model inputs, and quality metadata export together
A reader can inspect the records behind any summary
Where it stands
A working prototype in small-scale user testing. There are no participant findings yet, no psychometric validation of the mood item, and no claims about mental health or learning outcomes. The screenshots above use synthetic demonstration data.
2022–2026 · Amazon Health · multimodal, multi-agent
Before a prescription ships, someone has to confirm that the pills in the bottle match the label, that the label matches the order, and that the order makes clinical sense. That check is done by pharmacists, and it is the slowest and most consequential step in the workflow.
The system I worked on brought four kinds of evidence together — the prescription image, text extracted from that image, order information, and database records. The architecture moved from a single model to a single agent, and then to coordinated specialist agents running separate checks: prescription rationality, image against database, label against database. The point of splitting it up was to create structured cross-checks that reduce the risk of a fluent but wrong answer reaching a pharmacist. It does not remove the need for human judgment, and pharmacists keep final authority over every case.
The system reports specific mismatches and, in the last item, states that the available image does not support a definitive comparison. Demonstration data.
How we decided whether to trust it
I worked with pharmacists and applied scientists to define evaluation criteria at both the agent and system level, and validated against cases pharmacists had already reviewed. We looked at false positives specifically, because the two error types do not cost the same thing. We built gating and escalation rules for cases the system should not decide, and traceable controls so a decision could be reconstructed afterward. The system also reports when its own evidence is insufficient rather than producing a confident comparison.
3,000+ prescription images per day · under 800 ms average latency · 92% pre-screening accuracy
Pharmacy verification platform
2022–2026 · Amazon Health · React, Java / Spring Boot, AWS
The copilot only matters if there’s a workflow around it. I architected the platform pharmacists and operations staff actually work in: the APIs, the review interfaces, and the backend orchestration behind structured human decisions and auditable review states. It serves 200+ internal users at 99.9% uptime and handles more than 10,000 prescription review requests a day.
The design came out of iterative work with the people using it, which removed about 30% of the manual steps in the verification process. Building this is also where I learned what a human-in-the-loop system actually requires — mostly that the loop is the hard part, not the model.
The workflow platform pharmacists and operations staff work in. Demonstration data.
Fulfillment cost projection service
2022–2026 · Amazon Health · Java, Spring Boot, statistical modeling
A forecasting service built on historical facility- and medication-level data, producing real-time cost estimates used for routing decisions across more than 20 fulfillment facilities. It handles 2,000+ requests per second; reworking the data access path brought read latency down from roughly 400 ms to about 10 ms. Ordinary statistical modeling rather than anything generative, which is part of why I include it.
