Repository navigation
Initial Proposal
Project Proposal
| Team Name | Members | Student ID |
|---|---|---|
Momentum SWPP 18조 |
김수연 | 2022-13750 |
Momentum SWPP 18조 |
김진호 | 2020-19462 |
Momentum SWPP 18조 |
박준하 | 2018-15290 |
JustInTime — Risk-Aware Alarm Scheduling
-
Students with irregular schedules — Class times, part-time shifts, and appointments change daily, so a fixed alarm is either too early or too late. They must redo the mental arithmetic every night.
-
Chronically late commuters — People who consistently underestimate how long they need. Research on the planning fallacy shows self-reported preparation time is systematically optimistic.
-
Over-bufferers who lose sleep — The opposite group. They set alarms an hour early "just in case" and pay for safety with sleep every single day.
-
Groups meeting at one place and time — Friends, project teams, and study groups. A meeting fails if any one member is late, yet every member currently plans in isolation.
Problem. Every alarm app asks the user for the wrong input. It asks what time to wake up, which forces the user to estimate travel time, preparation time, and a safety margin, then subtract. People are bad at this. They are especially bad at variance: the same commute that takes 30 minutes on average takes 50 minutes when one transfer is missed. Google Calendar's "time to leave," map app departure alerts, and sleep-cycle alarms all give a single time and stop there. None of them tells the user how much that time can be off, so every user has to guess their own safety margin and control all uncertainty features. They either lose sleep to an oversized buffer or lose the appointment.
Innovation. We invert the input. The user specifies the lateness risk they are trying to avoid (τ), and the app computes the latest wake-up time that still satisfies it. Instead of "wake at 6:40," the app says "6:42 gets you to a 9:00 presentation with 90% probability; 7:00 drops it to 65%." To do this, the system learns two personal probability distributions rather than two averages: how long this user takes to get ready, and how long this route at this hour actually takes. Preparation time is decomposed into routine blocks (shower, hair, breakfast), each with its own learned distribution, so checking off "no hair wash today" immediately shifts the alarm later.
Why it is exciting. First, it converts an everyday chore into a calibrated prediction problem, and calibration is directly measurable — if we claim 90%, the observed on-time rate should be 90%, and we can show that to the user as proof. Second, transit delay is discrete and multimodal (missing a bus costs one full headway), which means the fastest route is often not the route that lets you sleep longest; ranking routes by wake-up time instead of travel time is a decision no existing app makes. Third, the group case is a genuinely unsolved problem: if four friends each accept a 10% personal risk, the meeting succeeds only 0.9⁴ ≈ 66% of the time. Nobody currently surfaces that gap, and the fix — raise the bottleneck member's threshold, or move the meeting 15 minutes later — is something only a shared, probabilistic app can propose.
What the system does. Reads the user's calendar, learns their personal preparation and travel-time distributions from passively collected observations, and schedules an alarm at the latest time that meets the user's chosen reliability target. It then supervises the morning in real time and intervenes when the plan slips.
AI features (core to the product, not an add-on):
-
Personal preparation-time model. Quantile regression over a feature vector of weekday, appointment tag, previous night's bedtime, snooze history, weather, and the set of routine blocks selected. Cold start is handled with a Bayesian prior elicited during onboarding, updated per observation, with hierarchical shrinkage toward a global prior until enough personal data accumulates. Labels are collected passively: alarm dismissal marks wake time, geofence exit marks departure.
-
Real-time pre-departure risk detection with ranked interventions. Before the user leaves, arrival probability is recomputed as each routine block completes. When it drops, the app offers concrete options — skip breakfast, shorten a block, call a taxi with the fare shown — and learns which option this user actually accepts.
-
LLM-based schedule and constraint parsing. Free-text input such as "presentation at 9 tomorrow, need to wash my hair and pack lunch" becomes a tagged event plus two routine blocks. Place names are resolved by grounding the model to local-search results rather than allowing free generation, which eliminates hallucinated locations.
-
Travel-time correction model. Leaving on time does not mean arriving on time. Once the user is moving, the app compares their actual position against the plan and recomputes expected arrival continuously. When the estimate slips, it proposes concrete recoveries — switch to a taxi with the fare shown, get off one stop early and walk, take the express line — ranked by minutes gained against cost. Transit is where this matters most: missing one transfer costs a full interval rather than a minute, so the app can warn about a connection the user is about to lose while they can still do something about it.
Other key features:
-
Routine block segmentation. Preparation is a small scheduling problem, not one number. Blocks carry duration distributions, prerequisites, parallelizability, and a cost of skipping, so the app can reorder, overlap, or drop them under time pressure.
-
Group meeting mode. Each participant gets a different alarm computed from their own location and profile. The room screen shows live group success probability, identifies the bottleneck member, and can propose shifting the meeting time so that no one has to be in a hurry.
-
Calibration report. Predicted reliability versus observed on-time rate, cumulative sleep saved, and a breakdown of lateness causes into preparation overrun, traffic variance, and late departure.
- Bedtime derivation. The morning alarm is fixed by the time it rings; the only moment sleep can still be gained is the night before. A nightly nudge shows the trade-off in sleep minutes: "sleep now for 6h20m; lowering τ to 0.8 gives you 6h45m."
- Weather-aware correction. Precipitation forecasts adjust both travel and preparation estimates, since rain adds minutes to the walk and to the routine alike. We feed a short-term precipitation forecast into both the travel and preparation models and let each user's own weather penalty be learned from their logs.
- Sleep-debt awareness. Health Connect sleep data adjusts the recommended τ after consecutive short nights.
2 × Samsung Galaxy S23
Justification is specific to this project rather than generic testing convenience:
- Alarm reliability cannot be validated on an emulator. One UI's aggressive battery optimization can defer background work and suppress alarms. Our product fails completely if one alarm does not fire, so we must leave real devices running overnight for consecutive days.
- Geofencing and Activity Recognition do not function meaningfully on emulators. Departure and arrival detection — the only source of our training labels — requires real device sensors and real movement.
- Two devices allow us to test the group meeting mode with two distinct profiles and locations simultaneously.
We will validate the system in three layers. First, the alarm computation engine is pure logic with no Android dependencies, so distribution composition, quantile calculation, and routine-block scheduling are covered by unit tests against fixtures with known expected outputs. Second, the learning pipeline is validated with a synthetic-log seeder: we inject thirty days of observations generated from known weekday, weather, and slack coefficients, then confirm the trained model recovers those coefficients and that the calibration report renders correctly — this also guarantees the demo works before real usage data exists. Third, team members will run the app as their actual alarm for four weeks, and we will report mean absolute error of predicted preparation time, observed on-time rate against the requested τ, and overnight firing reliability on physical Galaxy devices.
For the demonstration we will show the complete flow on one device: create a morning appointment, watch the alarm time change as routine blocks are toggled and the risk slider is moved, let the alarm fire, follow the morning progress screen as blocks are completed, trigger a delay so the risk detector offers its intervention options, and finish with the calibration report. We will then join a second device to a shared meeting room to show two different alarms derived from one appointment, the live group success probability, and the app proposing a later meeting time so that neither member has to wake earlier.
