Trust is earned, not declared
Users trust a system they can model. Demonstrating how data becomes output through core interactions does what disclaimers can’t.
Nimbus
The weather app that knows you run cold.
Designed for people who’ve just moved to Seattle and haven’t figured out what 48°F actually means.
The challenge
How do you get someone to trust a system’s judgment about their own comfort?
Nimbus turns a number into layers.
Nimbus translates weather conditions into a temperature-adjusted outfit guide, grounded in thermal science and explained in plain language. Built for Seattle microclimates, it accounts for when wind changes what a number feels like and when yesterday’s layers weren’t enough.
Building it surfaced a harder problem than the forecast. An outfit is a judgment about your comfort, and testing showed people don’t accept that judgment from a system just because it’s correct.
What building Nimbus taught me about AI trust:
Scoping the Model
Applying AI broadly weakens a product. Unwanted variability erodes trust, so the model’s scope has to be narrowed and enforced with guardrails.
Every weather app stops at the forecast.
Weather apps report an accurate number and leave the task of what to wear for those conditions to the user. When the day feels wrong, users blame the app even when the number was right. A study by the Royal Meteorological Society shows users judge accuracy by experience, not the number alone. Accuracy and trust are not the same thing.
62%
Seattle Residents Born Outside of Washington
— U.S. Census 2024
Seattle makes the gap impossible to ignore. Every forecast collapses the city into one number, but wind off the water and block-to-block microclimates decide whether that number keeps you comfortable or leaves you underdressed for the rest of the day. A system that makes the call for you has to be trusted, not just correct.
To better understand the gap, I mapped what people already use to get dressed.
| Market Category | Optimizes for | Limit |
|---|---|---|
| Weather apps | Forecast accuracy | Stops at data: no outfit decision |
| LLM chat advice | Flexible language | No memory loop, inconsistent warmth logic |
| Outdoor layering guides | Technical warmth | Not built for daily commute routines |
| Closet-inventory tools | Wardrobe truth | High setup cost, weak weather translation |
1 · Garment Science
Before designing screens, I built the thermal foundation: a garment reference grounded in ISO 9920 insulation values (CLO). Every item Nimbus can suggest has a known warmth.
2 · Testing the Personalization Loop
The first prototype ran the full loop. A single AI call read the weather, picked the garments, and wrote the voice. An evening check-in fed the recommendations for the next day.
Do users trust what the system does with their input?
| Finding | Signal | Participant Quote |
|---|---|---|
| Invisible Feedback Loop | 4/5 didn’t realize check-in influences tomorrow’s recommendations | “I thought I was just rating the day. I didn’t know it was actually doing something.” — P1 |
| Transparency Language Reads as Surveillance | 3/5 paused at visibility language until data use was explained | “Calibrated for me based on what?” — P3 |
| Static Tone Impedes Personalization | 2/5 with a year in Seattle found the newcomer tone patronizing | “I like the humor in the descriptions, but I’ve been here a year. I’m not that lost anymore.” — P5 |
The learning and the payoff sat on two different screens, so nobody connected them. The new version narrowed AI’s job: a deterministic thermal engine owns warmth, the model owns language only. The check-in moved inline, and the loop became visible.
3 · Building Trust
-
Detailed ExplanationsSeeing every adjustment the AI made did not explain why.
-
Data DisclaimerLabeling all the data used by AI created suspicion it was meant to prevent.
-
Decision VisibilityLet users watch a cause produce an effect.
Warmth is physics, not a prompt.
The engine exists because of one V2 decision: warmth had to stop being a model output. Warmth is physics. It’s testable, so it runs through deterministic code: a UTCI stress score maps to an insulation tier, garment lookup applies rain, wind, and damp-cold overrides, and your check-ins shift the band before lookup. Same weather, same history, same outfit. Every recommendation is traceable.
Language is where non-determinism earns its keep. The model writes the voice on top of decisions the engine already made. Nimbus also dresses you for exposure: the coldest hour you’re actually outside on your commute, not the daily high.
A contract, not a prompt.
My first one-shot prompt let the model make every decision I hadn’t specified, including claims about personalization nobody asked it to make. That’s the same failure warmth had: when the model owns a decision, nobody can trace how it got there. So warmth moved to code I could check, and the prompt became a behavioral contract: what the model can say, what it can never claim, and when it stays quiet.
Weather-aware outfit recommendations that adapt to you, and show you how.
Step through a single day: morning forecast, outfit lock-in, evening check-in, tomorrow’s adjustment.
What’s today like?
Today’s outfit and forecast on Home — no label claiming personalization, just the suggestion and the data behind it.
Week 2
“44° and drizzling — classic Seattle greeting. Your merino base and rain shell will handle it.”
Month 7
“42°, light rain. Shell, merino, boots. You ran warm last Thursday, trimmed the tier.”
What should I wear?
Lock in my outfit — not save. Nimbus only learns from clothes you actually wore.
Try Another
Lock in my outfit
How did today feel?
Check-in on the outfit tile, not a separate screen. Two steps when needed — feel, then reason — and loading copy that mirrors what you just said.
Did it work?
Tomorrow’s suggestion tonight — already adjusted for your check-in and the forecast. The loop closes before you sleep, with a plain-English note explaining why.
Outfit note
“I saw you felt cold today. Tomorrow will be rainy and 45°F, so I’ve swapped the flannel for a heavy sweater and added a scarf.”
The rules the loop never breaks
Closed vocabulary
Model picks from a fixed item set with known CLO values. It cannot invent garments that break the thermal math.
Hard weather overrides
Rain means a rain shell. The model doesn’t negotiate with weather.
Try Another
Variety within the same warmth band. A different outfit, not a worse one.
Sick-day escape hatch
Unusual days don’t train the thermal offset. The system learns only from representative days.
They asked to download it.
Nobody asked what the check-in was for. They asked if they could download the app.
“I wish I had this when I first moved here. It would’ve made the winter more bearable.”
— MHCI+D Cohort Member
Find the line before trust breaks.
Using AI everywhere is not always the right call. Nimbus only worked once I found the line between what the model should own and where it was breaking trust.
Where AI broke trust
“Calibrated for you” claimed personalization without showing proof. Users felt watched, not helped. Trust didn’t come from smarter copy. It came from making the feedback loop visible: see your check-in change tomorrow’s suggestion.
Where AI earned its place
V1 let the LLM pick garments and write the voice. V2 moved warmth to deterministic CLO math and limited the model to language. Both layers got better. The model stopped making calls it couldn’t defend.
What’s Next?
Longitudinal · 4–6 weeks
Diary study
% “just right” or “stayed in” ↑
check-in open rate ↑
Whether personalization improves comfort over time, not just first-session comprehension.
Automated + human eval
LLM eval harness
Tone varies by tenure level
Outfit recommendations stay consistent
Automated and human review of tenure-aware tone outputs tested against fixed outfit decisions.