fe Frontend38be Backend26dm Data-model11inf Infrastructure11Describe
A structural sentence about what the system is as an object that exists over time. The generative-ness of the sentence is the test.
Final version
A medication tracker is a time-indexed obligation ledger that reconciles scheduled doses against taken doses across varying adherence, delay, substitution, and prescription-change conditions, rendered on surfaces the user visits intermittently.
Highlighted terms are the structural pieces. Each one generates a cluster of states.
time-indexed window pending, window open, window overdue, window missed
obligation ledger durable history, export, reconciliation with retroactive edits
reconciles on-time, late, skipped, missed, double-confirmed
adherence / delay taken-late, auto-skipped, overdue-not-yet-missed
substitution / prescription-change paused, discontinued, dose-adjusted
rendered on surfaces widget, watch, lock-screen live activity, push, screen-reader, export
visits intermittently re-entry as the default, not the exception
Two rejected drafts
First attempt, feature-framed
"A medication tracker helps people remember to take their pills on time and records whether they took them."
Names a beneficiary and a goal. The verbs (helps, records) describe what the product does for the user, not what it is. Derived states collapse into reminded and recorded, which are events, not conditions.
Second attempt, flow-framed
"A medication tracker is an app where the user sets up a schedule, receives reminders at scheduled times, and marks each dose as taken or missed."
Better. Contains nouns the system is made of (schedule, reminders, doses). Still inadequate: it describes a user sequence rather than the object's structure, and omits the conditions the system spends most of its time in (waiting between windows, accumulating state, reconciling against wall-clock time, rendering on surfaces the user doesn't open).
List
Every state the system can occupy, sorted into four categories. The number (52) is not a target; it's the point at which three successive additions were specialisations of states already named.
Operating normally
- 01 Medication list empty First use, or the user has removed all medications. The home surface has no scheduled obligations.
- 02 Adding a medication Configuration flow for a new medication: name, strength, schedule, preconditions, duration.
- 03 Medication scheduled, idle between doses Between dose windows for this medication; the obligation exists but is not yet due.
- 04 Dose window pending The next dose is within view but the window has not opened. A "coming up" rendering, not an "act now".
- 05 Dose window open The dose is due now, within its acceptable window. The primary action, mark as taken, is available.
- 06 Dose overdue The window has passed but not by enough to count as missed. Still takeable; the system prompts more urgently.
- 07 Dose missed Past the missed threshold. No longer takeable for this window; recorded as missed in the ledger.
- 08 Dose taken on time Recorded within the window. Terminal state for a successfully reconciled dose.
- 09 Dose taken late Recorded after the window but before the missed threshold. Distinct from on-time in the ledger.
- 10 Dose skipped by user User explicitly chose to skip. Optionally records a reason.
- 11 Dose auto-skipped by system System skipped because the medication is paused or discontinued during the window.
- 12 Daily schedule view Aggregate rendering of today's obligations: taken, pending, overdue. Default home surface once medications are configured.
- 13 History view Ledger view across days or weeks. Aggregates taken, late, skipped, missed.
- 14 Medication paused User or provider has paused this medication. Scheduled doses do not surface as obligations; configuration persists.
- 15 Medication discontinued Future doses are removed from the schedule; historical doses remain in the ledger.
- 16 Dose precondition unmet The dose has a precondition (take with food, take on empty stomach) requiring user confirmation of context.
Something goes wrong
- 17 Notification permission not granted At onboarding the user did not grant permission to send reminders.
- 18 Notification permission revoked after onboarding User granted then revoked in OS settings. The app must detect this and surface it explicitly on foreground.
- 19 Schedule conflict Two doses scheduled at identical times across different medications.
- 20 Daily dose exceeds safe total User configured a schedule whose daily sum exceeds a safety threshold for the medication. Policy reject at configuration time.
- 21 Reminder delivery failed Push or local notification did not reach the device (service failure, device offline past TTL).
- 22 Backend sync failure User's actions (mark taken, skip) have not synced to backend. Local state diverges from remote.
- 23 Dose marked in distant past User attempts to mark a dose taken that is more than a day old. Data-integrity policy.
- 24 Device clock significantly off System time disagrees with server time by more than a threshold.
- 25 Time zone change not reconciled Device timezone updated but schedule has not been reconciled against the new zone.
- 26 Daylight saving boundary The DST transition either doubles a dose or skips one, depending on direction.
- 27 Dose double-confirmed within short window User marked the same dose taken twice within seconds, likely a double-tap.
- 28 Interaction warning Two medications scheduled within an unsafe window for a known interaction.
Time, context, or user leaving
- 29 App backgrounded through multiple dose windows The user was not looking; several windows opened and some closed without action.
- 30 Travel across time zones mid-day Device timezone changes between dose windows. Subsequent doses now computed against a different zone.
- 31 Phone off at reminder time Device was off at reminder time. OS delivers on boot, possibly after the window has passed.
- 32 Do Not Disturb at reminder time Notification suppressed by OS. App cannot distinguish 'user saw it' from 'OS withheld it'.
- 33 Airplane mode at scheduled dose Local notifications fire but network sync is unavailable; remote state diverges.
- 34 User opens app days later Many dose windows have passed. Daily schedule view is showing history, not today.
- 35 Notification tapped from lock screen Deep link into a specific dose. System must handle arrival at the dose without the preceding schedule-view context.
- 36 Cross-device action race User marks a dose on one device; opens another device seconds later. Second device may not have synced yet.
- 37 Battery saver suppressing background tasks Device OS has suppressed the app's background work. Reminders do not fire; sync lags.
- 38 Medication deleted with doses in history User deletes a medication that has recorded doses. History must survive the deletion.
Where the system presents itself
- 39 Home-screen widget (compact) One-line summary: next dose name and time.
- 40 Home-screen widget (medium) Today's schedule condensed, with a primary action.
- 41 Lock-screen live activity Live activity surface (iOS) or persistent notification (Android) for an open dose window.
- 42 Watch complication Smallest surface; typically a single next-dose indicator.
- 43 Push notification, first reminder Initial reminder at the window open.
- 44 Push notification, snooze repeat Follow-up reminder after a user-configured snooze.
- 45 Push notification, overdue escalation Stronger reminder once the window has closed but the dose is not yet missed.
- 46 In-app today view Canonical today surface within the app.
- 47 In-app history view Ledger view.
- 48 In-app medication detail Detail surface for a single medication: schedule, recent history, preconditions.
- 49 Screen-reader rendering Semantic rendering of the today view; live-region announcements for dose-window transitions.
- 50 Weekly export / PDF Printable summary for sharing with a clinician.
- 51 Voice-assistant rendering Assistant integration. Becomes in-scope when a specific integration is committed to.
- 52 Custom notification grouping for overlapping doses OS-default grouping is accepted for this iteration.
Hover or tap a state to see its description.
Decide
Assign every state a scope tag. Annotate layers and (for failure states) cause. For medication tracking, all active states are in-scope: the product's core value lives in the reconciliation of dose states.
45 In scope designed in this iteration
5 Out with implication not designed, has consequences for in-scope work
2 Out not designed, no current implication
user-input5system1external1policy1- 01 First use, or the user has removed all medications. The home surface has no scheduled obligations.
- 02 Configuration flow for a new medication: name, strength, schedule, preconditions, duration.
- 03 Between dose windows for this medication; the obligation exists but is not yet due.
- 04 The next dose is within view but the window has not opened. A "coming up" rendering, not an "act now".
- 05 The dose is due now, within its acceptable window. The primary action, mark as taken, is available.
- 06 The window has passed but not by enough to count as missed. Still takeable; the system prompts more urgently.
- 07 Past the missed threshold. No longer takeable for this window; recorded as missed in the ledger.
- 08 Recorded within the window. Terminal state for a successfully reconciled dose.
- 09 Recorded after the window but before the missed threshold. Distinct from on-time in the ledger.
- 10 User explicitly chose to skip. Optionally records a reason.
- 11 System skipped because the medication is paused or discontinued during the window.
- 12 Aggregate rendering of today's obligations: taken, pending, overdue. Default home surface once medications are configured.
- 13 Ledger view across days or weeks. Aggregates taken, late, skipped, missed.
- 14 User or provider has paused this medication. Scheduled doses do not surface as obligations; configuration persists.
- 15 Future doses are removed from the schedule; historical doses remain in the ledger.
- 16 The dose has a precondition (take with food, take on empty stomach) requiring user confirmation of context.
- 17 Handled at onboarding by a permissions primer. Implication: the today view must render meaningfully without assuming reminders have fired.
- 18 User granted then revoked in OS settings. The app must detect this and surface it explicitly on foreground.
- 19 Two doses scheduled at identical times across different medications.
- 20 User configured a schedule whose daily sum exceeds a safety threshold for the medication. Policy reject at configuration time.
- 21 Not reliably detectable device-side. Implication: the today view must not assume a reminder fired; act-now affordances remain visible even when a reminder was expected.
- 22 User's actions (mark taken, skip) have not synced to backend. Local state diverges from remote.
- 23 User attempts to mark a dose taken that is more than a day old. Data-integrity policy.
- 24 Rare; no dedicated rendering. Implication: server-time reconciliation on sync; a generic 'something looks off with your device's time' surface reuses the sync-failure rendering.
- 25 Device timezone updated but schedule has not been reconciled against the new zone.
- 26 Handled by the schedule engine rather than by a rendered state. Implication: the engine's decision (skip vs double-dose) is baked into the data model, documented so it is not rediscovered later.
- 27 User marked the same dose taken twice within seconds, likely a double-tap.
- 28 Two medications scheduled within an unsafe window for a known interaction.
- 29 The user was not looking; several windows opened and some closed without action.
- 30 Device timezone changes between dose windows. Subsequent doses now computed against a different zone.
- 31 Device was off at reminder time. OS delivers on boot, possibly after the window has passed.
- 32 Notification suppressed by OS. App cannot distinguish 'user saw it' from 'OS withheld it'.
- 33 Local notifications fire but network sync is unavailable; remote state diverges.
- 34 Many dose windows have passed. Daily schedule view is showing history, not today.
- 35 Deep link into a specific dose. System must handle arrival at the dose without the preceding schedule-view context.
- 36 User marks a dose on one device; opens another device seconds later. Second device may not have synced yet.
- 37 Device OS has suppressed the app's background work. Reminders do not fire; sync lags.
- 38 User deletes a medication that has recorded doses. History must survive the deletion.
- 39 One-line summary: next dose name and time.
- 40 Today's schedule condensed, with a primary action.
- 41 Live activity surface (iOS) or persistent notification (Android) for an open dose window.
- 42 Smallest surface; typically a single next-dose indicator.
- 43 Initial reminder at the window open.
- 44 Follow-up reminder after a user-configured snooze.
- 45 Stronger reminder once the window has closed but the dose is not yet missed.
- 46 Canonical today surface within the app.
- 47 Ledger view.
- 48 Detail surface for a single medication: schedule, recent history, preconditions.
- 49 Semantic rendering of the today view; live-region announcements for dose-window transitions.
- 50 Not designed this iteration. Implication: data model must preserve enough history to support export later; per-dose entries must carry their medication name rather than an id that might later be deleted.
- 51 Platform integrations deferred.
- 52 OS-default grouping is accepted for this iteration.
Specify
Re-entry is medication tracking's default, not its exception. Two in-scope active states are shown in full; the other in-scope active states have abbreviated specifications in the source.
Canonical rendering
A today surface showing the dose is due now, with a primary mark-as-taken action, secondary skip action, and context about the dose (medication name, strength, preconditions). Rendered on any of the in-scope surfaces (today view, widget, watch, push).
Return after time has passed
If the user returns mid-window, the rendering reflects current window status. If they return after the window closed, the state has transitioned: the dose is now overdue or missed. The return surface must show the transitioned state, not the state at leave-time.
Arrival from notification, deep link, or different device
Canonical arrival. A tap on the first-reminder notification opens this state directly, bypassing the today view. The surface must be self-sufficient: show which medication, which dose, take/skip actions. Arrival from another device requires an optimistic-then-reconciled flow.
Arrival without the preceding state
The user may arrive at this state without having seen window pending — for example, when a notification fires while the app was backgrounded. This state must not assume the user had any warning; it is the user's first awareness of the dose.
Underlying data has changed
Between the moment the window opened and the moment the user arrives, the medication may have been paused, discontinued, or had its schedule changed by the user on another device. The surface must revalidate against current configuration before accepting a mark-as-taken.
Arrival during or after a failure
If the reminder did not fire (permission revoked, DND, battery saver) the window may be open without the user being aware. The today view must render the open dose prominently on re-open regardless of whether the reminder fired. Backend sync failure means a mark-as-taken may not persist; accept optimistically, queue it, reconcile.
Canonical rendering
Today's obligations, ordered by time, each dose shown in its current state (pending, open, overdue, missed, taken, skipped). Aggregate adherence summary for the day at the top or as a running score.
Return after time has passed
If the user returns later the same day, doses that were pending or open have transitioned; the rendering must reflect current state rather than cached state. If they return on a subsequent day, this surface is now rendering a new day and should show the new day's schedule; yesterday's ledger moves to the history view.
Arrival from notification, deep link, or different device
Most common arrival is from a notification tap into a specific dose; a return-to-home action then brings the user to this view. On a different device, the surface may render stale data briefly during sync; show a subtle updating affordance rather than blocking the view.
Arrival without the preceding state
A new user lands on medication-list-empty rather than this view; this state is entered for the first time after a first medication is configured. Arrival without medications configured must route to the empty state.
Underlying data has changed
Data commonly changes between visits: doses marked on another device, medications paused, schedules edited. The surface must reconcile on foreground and render current state. Changes that would surprise the user (an in-progress dose now marked taken) should surface a lightweight indication of the change.
Arrival during or after a failure
If multiple reminders failed (e.g. after battery-saver suppressed background work), several doses may be overdue or missed on arrival. The surface must not hide this behind a today summary; overdue doses should be prominent, and the user's ability to mark them late should be preserved where the missed threshold has not been crossed.
Re-entry conditions compose. Arrival at a dose window from a notification, after the app has been backgrounded across a timezone change, during battery-saver suppression, and with pending sync failures is a plausible Tuesday.
The map
The artefact. Every state with its description, layers, cause, renders-on surfaces, and re-entry variants. Click any cell to inspect.
First use, or the user has removed all medications. The home surface has no scheduled obligations.
Renders on
- In-app today view
- Home-screen widget (compact)
- Home-screen widget (medium)
- Screen-reader rendering
Transitions in
- Medication discontinued → last medication discontinued and deleted
Transitions out
- user starts adding a medication → Adding a medication
Re-entry variants
- after-removing-all
Render faithfully rather than persisting a stale schedule view.
- deep-link-to-deleted-medication
Arrival from an expired notification or share link should land here with a brief explanation of what happened.
Configuration flow for a new medication: name, strength, schedule, preconditions, duration.
Renders on
- In-app medication detail
- Screen-reader rendering
Transitions in
- Medication list empty → user starts adding a medication
Transitions out
- configuration completed successfully → Medication scheduled, idle between doses
- configured schedule fails daily-total safety policy → Daily dose exceeds safe total
- configured schedule overlaps an existing medication unsafely → Interaction warning
- configured time coincides with another medication → Schedule conflict
Re-entry variants
- abandoned-mid-flow
Preserve partial configuration locally; on return, prompt to resume or discard.
- after-validation-failure
A validation failure such as daily-dose-exceeds-safe-total must not clear entered fields.
Between dose windows for this medication; the obligation exists but is not yet due.
Renders on
- In-app today view
- Home-screen widget (compact)
- Home-screen widget (medium)
- Watch complication
- Screen-reader rendering
Transitions in
- Adding a medication → configuration completed successfully
- Dose taken on time → dose recorded; return to idle
- Dose taken late → dose recorded; return to idle
- Dose skipped by user → skip recorded; return to idle
- Dose missed → missed status recorded; return to idle
- Dose auto-skipped by system → auto-skip recorded; return to idle
- Medication paused → user resumes medication
Transitions out
- next dose window within preview horizon → Dose window pending
- user opens app → Daily schedule view
- user pauses medication → Medication paused
- user discontinues medication → Medication discontinued
- device timezone changes → Travel across time zones mid-day
- device enters low-power mode → Battery saver suppressing background tasks
Re-entry variants
- return-later-same-day
Next-dose time renders from absolute scheduled time, not a stale relative duration computed at leave-time.
- schedule-changed-elsewhere
On focus, re-fetch schedule and re-render the next-dose indicator.
The next dose is within view but the window has not opened. A "coming up" rendering, not an "act now".
Renders on
- In-app today view
- Home-screen widget (medium)
- Watch complication
- Screen-reader rendering
Transitions in
- Medication scheduled, idle between doses → next dose window within preview horizon
Transitions out
- window opens at scheduled time → Dose window open
- medication paused before window opens → Dose auto-skipped by system
Re-entry variants
- arrival-from-pre-window-notification
Arrival from a pre-window reminder must show the same information as entering via the today view.
- prior-dose-sync-failed
This view must render the upcoming dose even if a prior dose has not yet synced.
The dose is due now, within its acceptable window. The primary action, mark as taken, is available.
Renders on
- In-app today view
- Home-screen widget (compact)
- Home-screen widget (medium)
- Lock-screen live activity
- Watch complication
- Push notification, first reminder
- Screen-reader rendering
Transitions in
- Dose window pending → window opens at scheduled time
- Daily schedule view → user taps an open dose
- Notification tapped from lock screen → deep-link to specific dose
Transitions out
- dose has an unverified precondition → Dose precondition unmet
- user marks taken within window → Dose taken on time
- user skips → Dose skipped by user
- window closes with no action → Dose overdue
- window opens → Push notification, first reminder
- mark-as-taken fails to sync → Backend sync failure
- device off at window open → Phone off at reminder time
- DND active at window open → Do Not Disturb at reminder time
- airplane mode at window open → Airplane mode at scheduled dose
- concurrent action on another device → Cross-device action race
Re-entry variants
- return-mid-window
Render reflects the current window status; time-remaining indicator updates on focus.
- return-after-window-closed
The state has transitioned to dose-overdue or dose-missed; the return surface must show the transitioned state, not the state at leave-time.
- arrival-from-push-notification
Surface must be self-sufficient: show which medication, which dose, and the take/skip actions without assuming the user saw the today view first.
- arrival-from-another-device
Render optimistically from local state, then reconcile with backend; if the dose was taken on the other device, transition to dose-taken-on-time and surface a lightweight confirmation.
- medication-paused-in-interim
Revalidate against current configuration before accepting mark-as-taken; if paused, route to medication-paused rendering rather than recording a dose.
- reminder-never-fired
If reminder failed (permission, DND, battery saver), the open dose must still render prominently on re-open regardless of reminder delivery.
The window has passed but not by enough to count as missed. Still takeable; the system prompts more urgently.
Renders on
- In-app today view
- Home-screen widget (compact)
- Home-screen widget (medium)
- Lock-screen live activity
- Watch complication
- Push notification, overdue escalation
- Screen-reader rendering
Transitions in
- Dose window open → window closes with no action
Transitions out
- user marks taken after window → Dose taken late
- user skips → Dose skipped by user
- missed threshold reached → Dose missed
- overdue escalation fires → Push notification, overdue escalation
Re-entry variants
- return-check-transition
On return, check whether the missed threshold has been crossed and transition to dose-missed if so.
- arrival-from-escalation-notification
Deep-linked from push-overdue-escalation; render the dose with take-late and skip actions foregrounded.
Past the missed threshold. No longer takeable for this window; recorded as missed in the ledger.
Renders on
- In-app today view
- In-app history view
- Screen-reader rendering
Transitions in
- Dose overdue → missed threshold reached
Transitions out
- missed status recorded; return to idle → Medication scheduled, idle between doses
Re-entry variants
- policy-change-retroactive
If a schedule edit retroactively changes the missed status, the history rendering must reflect it coherently.
Recorded within the window. Terminal state for a successfully reconciled dose.
Renders on
- In-app today view
- In-app history view
- Screen-reader rendering
Transitions in
- Dose precondition unmet → user confirms precondition and marks taken
- Dose window open → user marks taken within window
- Dose double-confirmed within short window → double-tap reconciled to single confirmation
- Backend sync failure → sync succeeds on retry
Transitions out
- dose recorded; return to idle → Medication scheduled, idle between doses
- user marks taken again within short window → Dose double-confirmed within short window
Re-entry variants
- revisit
Safe to revisit; does not re-commit.
- reversal-within-grace-period
If the user reverses within a short window, the dose may return to dose-window-open; handle explicitly.
Recorded after the window but before the missed threshold. Distinct from on-time in the ledger.
Renders on
- In-app today view
- In-app history view
- Screen-reader rendering
Transitions in
- Dose overdue → user marks taken after window
Transitions out
- dose recorded; return to idle → Medication scheduled, idle between doses
User explicitly chose to skip. Optionally records a reason.
Renders on
- In-app today view
- In-app history view
- Screen-reader rendering
Transitions in
- Dose window open → user skips
- Dose overdue → user skips
Transitions out
- skip recorded; return to idle → Medication scheduled, idle between doses
Re-entry variants
- reason-rendering-in-history
Recorded reason persists through history rendering.
System skipped because the medication is paused or discontinued during the window.
Renders on
- In-app history view
- Screen-reader rendering
Transitions in
- Dose window pending → medication paused before window opens
Transitions out
- auto-skip recorded; return to idle → Medication scheduled, idle between doses
Re-entry variants
- history-rendering-without-prior-prompt
Rendered in history without the user having seen an in-app prompt. Copy must explain the skip cause (paused medication).
Aggregate rendering of today's obligations: taken, pending, overdue. Default home surface once medications are configured.
Renders on
- In-app today view
- Home-screen widget (medium)
- Watch complication
- Screen-reader rendering
Transitions in
- Medication scheduled, idle between doses → user opens app
- App backgrounded through multiple dose windows → user reopens app
- Battery saver suppressing background tasks → user reopens app after suppression
- User opens app days later → user reopens after a long gap
- Notification permission revoked after onboarding → user re-grants or dismisses banner
Transitions out
- user navigates to history → History view
- user taps a medication → In-app medication detail
- user taps an open dose → Dose window open
- app backgrounded with open windows pending → App backgrounded through multiple dose windows
- foreground detects revocation → Notification permission revoked after onboarding
Re-entry variants
- return-later-same-day
Reflect current state of all doses rather than cached state; doses that transitioned must render correctly.
- return-on-subsequent-day
Render the new day's schedule; previous day's ledger moves to history-view.
- arrival-from-notification-tap
Notification taps typically deep-link to a specific dose; a return-to-home brings the user here.
- on-another-device-during-sync
May render stale data briefly; show a subtle 'updating' affordance rather than blocking the view.
- data-changed-between-visits
Reconcile on foreground; surface a lightweight indication for surprising changes (e.g. a dose marked taken from elsewhere).
- multiple-missed-after-suppression
After battery-saver or similar suppression, several overdue doses must render prominently; the user's ability to mark them late where possible must be preserved.
Ledger view across days or weeks. Aggregates taken, late, skipped, missed.
Renders on
- In-app history view
- Screen-reader rendering
Transitions in
- Daily schedule view → user navigates to history
Transitions out
- user edits a dose more than a day old → Dose marked in distant past
Re-entry variants
- revisit
Append-only from the user's perspective; revisiting shows the same data plus any new entries.
- deep-linked-by-date
Arrival from a weekly summary or export link scrolls to the referenced date.
User or provider has paused this medication. Scheduled doses do not surface as obligations; configuration persists.
Renders on
- In-app medication detail
- In-app today view
- Screen-reader rendering
Transitions in
- Medication scheduled, idle between doses → user pauses medication
Transitions out
- user resumes medication → Medication scheduled, idle between doses
Re-entry variants
- paused-by-user-vs-provider
Rendering distinguishes pause cause; user-pause is editable, provider-pause (out of scope but retained as out-with-implication) is not.
Future doses are removed from the schedule; historical doses remain in the ledger.
Renders on
- In-app medication detail
- In-app history view
- Screen-reader rendering
Transitions in
- Medication scheduled, idle between doses → user discontinues medication
Transitions out
- last medication discontinued and deleted → Medication list empty
- user deletes discontinued medication with history → Medication deleted with doses in history
Re-entry variants
- arrival-via-deep-link
Decision typically initiated from medication detail; deep links from external systems must explain the current state clearly.
The dose has a precondition (take with food, take on empty stomach) requiring user confirmation of context.
Renders on
- In-app today view
- Push notification, first reminder
- Screen-reader rendering
Transitions in
- Dose window open → dose has an unverified precondition
Transitions out
- user confirms precondition and marks taken → Dose taken on time
Re-entry variants
- confirmation-lost-on-retry
If the user confirms the precondition and then fails to complete (network drop), the confirmation must persist on retry.
At onboarding the user did not grant permission to send reminders.
Scope note
Handled at onboarding by a permissions primer. Implication: the today view must render meaningfully without assuming reminders have fired.
User granted then revoked in OS settings. The app must detect this and surface it explicitly on foreground.
Transitions in
- Daily schedule view → foreground detects revocation
Transitions out
- user re-grants or dismisses banner → Daily schedule view
Two doses scheduled at identical times across different medications.
Transitions in
- Adding a medication → configured time coincides with another medication
User configured a schedule whose daily sum exceeds a safety threshold for the medication. Policy reject at configuration time.
Transitions in
- Adding a medication → configured schedule fails daily-total safety policy
Push or local notification did not reach the device (service failure, device offline past TTL).
Scope note
Not reliably detectable device-side. Implication: the today view must not assume a reminder fired; act-now affordances remain visible even when a reminder was expected.
User's actions (mark taken, skip) have not synced to backend. Local state diverges from remote.
Transitions in
- Dose window open → mark-as-taken fails to sync
Transitions out
- sync succeeds on retry → Dose taken on time
User attempts to mark a dose taken that is more than a day old. Data-integrity policy.
Transitions in
- History view → user edits a dose more than a day old
System time disagrees with server time by more than a threshold.
Scope note
Rare; no dedicated rendering. Implication: server-time reconciliation on sync; a generic 'something looks off with your device's time' surface reuses the sync-failure rendering.
Device timezone updated but schedule has not been reconciled against the new zone.
Transitions in
- Travel across time zones mid-day → schedule not yet reconciled
The DST transition either doubles a dose or skips one, depending on direction.
Scope note
Handled by the schedule engine rather than by a rendered state. Implication: the engine's decision (skip vs double-dose) is baked into the data model, documented so it is not rediscovered later.
User marked the same dose taken twice within seconds, likely a double-tap.
Transitions in
- Dose taken on time → user marks taken again within short window
Transitions out
- double-tap reconciled to single confirmation → Dose taken on time
Two medications scheduled within an unsafe window for a known interaction.
Transitions in
- Adding a medication → configured schedule overlaps an existing medication unsafely
The user was not looking; several windows opened and some closed without action.
Transitions in
- Daily schedule view → app backgrounded with open windows pending
Transitions out
- user reopens app → Daily schedule view
Device timezone changes between dose windows. Subsequent doses now computed against a different zone.
Transitions in
- Medication scheduled, idle between doses → device timezone changes
Transitions out
- schedule not yet reconciled → Time zone change not reconciled
Device was off at reminder time. OS delivers on boot, possibly after the window has passed.
Transitions in
- Dose window open → device off at window open
Notification suppressed by OS. App cannot distinguish 'user saw it' from 'OS withheld it'.
Transitions in
- Dose window open → DND active at window open
Local notifications fire but network sync is unavailable; remote state diverges.
Transitions in
- Dose window open → airplane mode at window open
Many dose windows have passed. Daily schedule view is showing history, not today.
Transitions out
- user reopens after a long gap → Daily schedule view
Deep link into a specific dose. System must handle arrival at the dose without the preceding schedule-view context.
Transitions out
- deep-link to specific dose → Dose window open
User marks a dose on one device; opens another device seconds later. Second device may not have synced yet.
Transitions in
- Dose window open → concurrent action on another device
Device OS has suppressed the app's background work. Reminders do not fire; sync lags.
Transitions in
- Medication scheduled, idle between doses → device enters low-power mode
Transitions out
- user reopens app after suppression → Daily schedule view
User deletes a medication that has recorded doses. History must survive the deletion.
Transitions in
- Medication discontinued → user deletes discontinued medication with history
One-line summary: next dose name and time.
Today's schedule condensed, with a primary action.
Live activity surface (iOS) or persistent notification (Android) for an open dose window.
Smallest surface; typically a single next-dose indicator.
Initial reminder at the window open.
Transitions in
- Dose window open → window opens
Follow-up reminder after a user-configured snooze.
Stronger reminder once the window has closed but the dose is not yet missed.
Transitions in
- Dose overdue → overdue escalation fires
Canonical today surface within the app.
Ledger view.
Detail surface for a single medication: schedule, recent history, preconditions.
Transitions in
- Daily schedule view → user taps a medication
Semantic rendering of the today view; live-region announcements for dose-window transitions.
Printable summary for sharing with a clinician.
Scope note
Not designed this iteration. Implication: data model must preserve enough history to support export later; per-dose entries must carry their medication name rather than an id that might later be deleted.
Assistant integration. Becomes in-scope when a specific integration is committed to.
Scope note
Platform integrations deferred.
OS-default grouping is accepted for this iteration.