You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The state where notifications are enabled but no Schedule Notification is currently armed for an upcoming schedule.
82
+
_Avoid_: Pending, waiting, permission pending
83
+
84
+
**Approximate Notification Timing**:
85
+
The state where OnTime may notify the user for a schedule but cannot guarantee delivery at the exact preparation time.
86
+
_Avoid_: Disabled notifications, alarm denied
87
+
88
+
**Precise Notification Status**:
89
+
The user-facing status for a Schedule Notification that can be delivered with Precise Notification Timing.
90
+
_Avoid_: Native alarm, exact alarm
91
+
92
+
**Notification Status**:
93
+
The user-facing status for schedule delivery through notifications when Alarm delivery or Precise Notification Timing is unavailable.
94
+
_Avoid_: Fallback, degraded, time sensitive
95
+
96
+
**Alarm Status**:
97
+
The user-facing status for schedule delivery through an Alarm.
98
+
_Avoid_: Notification, native alarm
99
+
48
100
## Relationships
49
101
50
102
- A **Product Usage Event** may describe a schedule, preparation, notification, alarm, onboarding, or account action without storing the user's raw schedule names, notes, place names, credentials, tokens, or free text.
- An **Analytics Event Parameter** must not contain user-authored text, direct identifiers, tokens, raw exception strings, request bodies, or response bodies.
55
107
- A **Product Usage Event** uses a stable snake_case name and includes a schema version.
56
108
- A changed **Product Usage Event** meaning requires a new event name or schema version.
109
+
- User-facing copy should call a scheduled notification a **Schedule Notification**, not an **Alarm**, unless it opens an OnTime screen without the user first tapping a notification.
110
+
- The profile setting for upcoming schedule preparation delivery should be called **Schedule Notification Setting**.
111
+
- On iOS, user-facing copy may say **Alarm** only when OnTime can deliver an **iOS AlarmKit Alarm**.
112
+
- iOS permission prompts should use alarm language only when requesting an **iOS AlarmKit Alarm**; otherwise they should use notification language.
113
+
- When an **iOS AlarmKit Alarm** is unavailable or denied but notifications are allowed, user-facing status should say notification rather than expose Time Sensitive terminology.
114
+
- A **Schedule Notification** should use **Precise Notification Timing** when the user's device supports it and **Exact Timing Permission** is granted.
115
+
- A **Fallback Notification** may back up a **Schedule Notification**, but it does not satisfy **Exact Timing Permission**.
116
+
- On Android, OnTime should use an **Android Schedule Notification** unless **Alarm** policy approval is available.
117
+
- Android permission prompts for scheduled preparation delivery should say notification, not alarm, unless OnTime is requesting or explaining an **Alarm** experience.
118
+
- Android **Exact Timing Permission** copy should explain that the permission is needed to notify the user at the exact preparation time.
119
+
-**Exact Timing Permission** is granted only when the device reports it as granted, not when the user taps a permission request button.
120
+
-**No Scheduled Notification** does not indicate a missing **Exact Timing Permission**.
121
+
- Missing **Exact Timing Permission** means **Approximate Notification Timing**, not disabled notifications, when notification permission is granted.
122
+
- Android with **Precise Notification Timing** should show **Precise Notification Status**.
123
+
- Android without **Precise Notification Timing** but with notification permission should show **Notification Status**.
124
+
- iOS with an **iOS AlarmKit Alarm** should show **Alarm Status**.
125
+
- iOS without an available **iOS AlarmKit Alarm** but with notification permission should show **Notification Status**.
126
+
-**No Scheduled Notification** should be the user-facing empty state across platforms, even when future delivery may use an **Alarm**.
57
127
- Active first-release **Analytics Purposes** are product improvement, debugging and operations, and experimentation.
58
128
- A first-release **Experiment** must not be used for marketing targeting, sensitive segmentation, or personalized treatment.
59
129
- Marketing and personalization are **Deferred Analytics Purposes**.
- "Event payload" was too open-ended; resolved: events use allowlisted **Analytics Event Parameters** only.
156
+
- "Alarm permission" was ambiguous between **Exact Timing Permission** and notification permission; resolved: notification permission may enable a **Fallback Notification**, but does not mean **Exact Timing Permission** is granted.
157
+
- "Pending" was ambiguous for notification status; resolved: the canonical state is **No Scheduled Notification** when notifications are enabled but no upcoming Schedule Notification is armed.
158
+
- "Allowed" was ambiguous for permission requests; resolved: a request action is not the same as granted **Exact Timing Permission**.
159
+
- "Native alarm" was ambiguous on Android; resolved: Android can use an **Android Schedule Notification** without promising an **Alarm**.
160
+
- "Fallback" was ambiguous as either a backup delivery path or permission bypass; resolved: Android's notification-only path should not be labeled fallback when it is the intended policy-safe path.
161
+
- "Notification-only alarm" was ambiguous as either approximate or precise; resolved: Android should keep **Precise Notification Timing** while using an **Android Schedule Notification** presentation.
162
+
- "Notification" was ambiguous as either a user-facing alarm concept or a platform presentation; resolved: user-facing copy should say **Schedule Notification** unless the experience is an **Alarm**.
163
+
- "Allow alarms" was ambiguous on Android; resolved: permission prompts should say notifications when the resulting user experience is notification-based.
164
+
- "Denied exact timing" was ambiguous as either disabled delivery or degraded delivery; resolved: with notification permission granted, it means **Approximate Notification Timing**.
165
+
- "Schedule alarm setting" was ambiguous after Android moved to notification-based delivery; resolved: the profile control is **Schedule Notification Setting**.
166
+
- "iOS alarm" was ambiguous across OS versions; resolved: iOS copy may say **Alarm** only when **iOS AlarmKit Alarm** is available.
167
+
- "iOS alarm permission" was ambiguous across OS versions; resolved: iOS permission prompts use alarm language only for **iOS AlarmKit Alarm**.
168
+
- "Time Sensitive" was too platform-specific for default user-facing status; resolved: fallback iOS delivery should be called notification.
169
+
- "Status label" was ambiguous across platforms; resolved: Android uses precise notification or notification status, while iOS uses alarm status only for **iOS AlarmKit Alarm**.
170
+
- "No scheduled alarm" was too capability-specific for an empty state; resolved: use **No Scheduled Notification** across platforms.
-[Schedule Notification Flow](./Schedule-Notification-Flow.md) - OS-specific notification/alarm permission flows, status labels, and copy rules
30
31
-[Schedule Preparation Flow SRD](./Schedule-Preparation-SRD.md) - End-to-end requirements, diagrams, and branch coverage for preparation start through finish, including early start
31
32
-[Schedule Timer & Runtime Flow (v2)](./Schedule-Timer-System.md) - Official behavior for early start, timer transitions, cache coherence, and verification matrix
0 commit comments