Revised Proposal - snuhcs-course/swpp-2026-project-team-18 GitHub Wiki

Project Proposal

0. Team Information

Team Name Members Student ID
Momentum SWPP 18μ‘° κΉ€μˆ˜μ—° 2022-13750
Momentum SWPP 18μ‘° κΉ€μ§„ν˜Έ 2020-19462
Momentum SWPP 18μ‘° λ°•μ€€ν•˜ 2018-15290

1. Project Name

JustInTime β€” Risk-Aware Alarm Scheduling

2. Target Customers

  1. 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.

  2. Chronically late commuters β€” People who consistently underestimate how long they need. Research on the planning fallacy shows self-reported preparation time is systematically optimistic.

  3. 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.

  4. 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.

3. Motivation

Problem. Most conventional alarm apps ask users to choose what time to wake up. This forces users to mentally estimate their preparation time, travel time, and safety margin, and then work backward from the required arrival time. People are often poor at this calculation, especially when those times vary from day to day. Arrival-based alarm apps, such as Arrive, reduce some of this effort by combining a destination, live traffic, a user-entered preparation time, and a fixed safety buffer to calculate a wake-up time. However, users must still decide how much preparation time and buffer are enough.

Innovation. JustInTime replaces the fixed-buffer decision with a risk decision. The user chooses a maximum acceptable lateness probability (Ο„), and the app computes the latest wake-up time. 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: how long this user takes to get ready, and how long this route at this hour actually takes. Also, the app updates the user's predicted lateness risk using real-time traffic conditions. When that risk exceeds the user-selected threshold, it proposes actionable alternatives, such as leaving immediately, taking a faster route, or switching transportation modes.

Why it is exciting. First, the app's predicted on-time probability is directly testable: a 90% on-time prediction should produce approximately 90% on-time arrivals over repeated use. Second, it can be compared fairly with a fixed-buffer alarm: at the same observed on-time rate, does personalization let the user wake up later and save sleep? Third, when live traffic changes or the user is behind schedule during preparation, JustInTime recomputes the user's personalized arrival probability and can warn the user when it falls below the selected target.

4. Main Features

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.

Primary features:

  1. Personal preparation-time model. Quantile regression over a feature vector of weekday, appointment tag, previous night's bedtime, etc. 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.

  2. 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 options β€” skip breakfast, call a taxi β€” and learns which option this user actually accepts. During onboarding, the user provides initial duration estimates for each routine block, whose sum forms the initial total preparation-time estimate. As observed wake-to-departure durations accumulate, the app fits a personalized total preparation-time distribution and proportionally adjusts the estimated durations of the routine blocks to remain consistent with that distribution.

  3. 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 ranked by minutes gained against cost.

Additional features:

  1. 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.

  2. Routine block segmentation. Preparation is separated into routine blocks. Blocks carry duration distributions, prerequisites, parallelizability, and a cost of skipping, so the app can reorder, overlap, or drop them under time pressure.

  3. 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.

  4. 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.

  5. Weather-aware correction. 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.

5. Device Needed

2 Γ— Samsung Galaxy S23

6. Test & Demo Plan

We will validate the system in three layers. First, the distribution composition, quantile calculation, and routine-block scheduling are covered by unit tests against fixtures with known expected outputs. Second, we will inject thirty days of observations generated from known weekday, weather, and slack coefficients, then confirm if the trained model recovers those coefficients and that the calibration report renders correctly. 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 the mean absolute error between actual arrival time and the appointment time on physical Galaxy devices. We will also compare these metrics against those of a fixed safety-buffer baseline. We will compare the number of late arrivals and the mean absolute difference between actual arrival time and the appointment time.

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.

7. Concept Figure

JustInTime screen flow

Figure 1. JustInTime screen flow. Thirteen screens over the six stages of one morning. Authentication (β‘ β‘‘) and schedule entry (⑫⑬, with β‘«-a showing direct time entry and the appointment-type dropdown that sets Ο„) feed the alarm decision (β‘’β‘£β‘€), where the inversion described in Β§3 becomes concrete: β‘£ decomposes the alarm into learned preparation time, measured travel time, and safety buffer, while β‘€ replaces a time picker with a risk picker β€” 7:20 at 97%, 7:40 at 90%, 8:00 at 65% β€” each labelled with the sleep it costs. Replanning covers the two moments the plan can still be saved, before leaving (β‘₯) and in transit (⑦), each ranking recoveries by minutes gained against fare. Reports (⑧⑨) close the loop with calibration evidence: predicted quantiles against observed on-time rates (p90 β†’ 89%). Companion mode (β‘©β‘ͺ) derives a separate alarm per member and proposes moving the meeting rather than rushing the bottleneck member.