Attention and Notification Interaction Design Guidelines
Make what is worth knowing visible in time, give what needs handling a clear next step, and let users return to their own work once they are done.
5 principles · 14 rules · MUST 0 · SHOULD 0
Contents
Make what is worth knowing visible in time, give what needs handling a clear next step, and let users return to their own work once they are done.
Applies to in-app prompts, system notifications, digests, background-task interventions, and multi-channel reminders. For designers, product, and engineering: each rule states the design decision to make, the feedback the user can perceive, and the evidence implementation should provide. Companion files: Design Token and configuration dictionary · Sources and evidence boundaries.
1. Scope and how to read
These guidelines cover the complete process of "subscription and permission → event determination → queuing and delivery → presentation and handling → return to the original task → burden review," and do not prescribe a single component, recommendation algorithm, or messaging protocol. They do not apply to reliability certification for dedicated alert systems such as medical alarms, emergency broadcasts, or driving alerts; ordinary products MUST NOT borrow these scenarios as justification for arbitrary do-not-disturb bypass.
MUST / MUST NOT are acceptance baselines: without them, an explicit user promise would fail under foreseeable circumstances. SHOULD is recommended practice; when deviating, record the rationale and an equivalent alternative. MAY is optional implementation. The unit of judgment is the independent obligation clause in the main text; examples and paired counterexamples help surface problems and add no obligation or scope expansion.
Rules are this project's necessity-driven derivation, not the original text of external literature. External standards state applicable requirements, platform documentation provides implementation reference, and research offers directions that need testing; none of the three proves that a given reminder frequency or waiting duration is universally optimal.
1.1 Concepts that must be kept separate
| Concept | Meaning | Not the same as |
|---|---|---|
| Event | One meaningful change to a business object | Every poll or every content refresh producing a new event |
| Notification category | A kind of reminder purpose the user can understand and manage | The delivery service's internal technical queue |
| Delivery mode | Record only, defer, request notification | An urgency level; deferring is not low priority |
| Reminder round | One logical reminder issued for the same event | Each device, channel, or retry getting a fresh quota |
| Delivery evidence | Staged evidence — requested, service accepted, device received, actually presented | The user having noticed, understood, or handled it |
| Business state | Business facts such as pending, handled, or invalidated | Read, dismissed, or the badge reset to zero |
| Last-useful reminder point | The point before a deadline that still leaves reasonable time to react and act | The business deadline itself |
| Settings scope | A single event / a category / all optional notifications, and the account, device, and channel scope | One toggle automatically standing for every endpoint and every medium |
"Handled" refers to the matter this particular notification concerns; it does not directly copy a background task's status. For example, an export task completing produces a new event that still has notice value; the event must not be judged as needing no reminder simply because the export has completed. A pure-notice event ends according to its relevance, validity period, and user choice, without forcing a business to-do into existence.
2. Principles and rule quick reference
| Principle | Object and direction of regulation | Rules |
|---|---|---|
| N1 A reminder has a reason | Reminder eligibility: why reach this person, when interruption is worthwhile | N1-1, N1-2 |
| N2 Timing stays with the user | Requesting permission, quiet hours, and preferences: choices take effect | N2-1, N2-2, N2-3 |
| N3 Queues have a lifecycle | Aggregation, deferral, and action freshness: stale messages do not govern the present | N3-1, N3-2, N3-3 |
| N4 Intervention is understandable and recoverable | Content, actions, and the return path: handling a notification loses no work | N4-1, N4-2, N4-3 |
| N5 Total burden is governable | Cross-channel coordination, burst totals, and long-term effect | N5-1, N5-2, N5-3 |
3. Full rules
N1-1Prove first that the reminder is worth happening
Applies toadding a category, a background trigger, or a proactive suggestion that may produce a notification.
Requirement: The recipient, trigger condition, user benefit, consequence of not reminding, basis for validity, and next step MUST be made explicit. A purely informational category may write the next step as "acknowledged, no action needed," while still explaining the value of being informed. Record-only, non-intrusive awareness, and active interruption MUST be distinguished, choosing the approach that can actually deliver the benefit; the less disruptive approach SHOULD be preferred. Marketing MUST NOT disguise itself as a task failure, account risk, or a pending approval.
Design decision: Ask first "what will this reminder help the user know or change," then choose the entry point. Subscribing to a notification does not equal consenting to the system automatically executing a new task proposed inside the notification; the user's non-response MUST NOT be treated as consent.
User-side verification: The user can explain why they received it and whether action is needed; a purely informational notification carries no confirmation button the user is forced to click.
Implementation-side verification: A sample event can be traced back to its category, receipt basis, and trigger condition; polling with no change produces no new reminder.
Paired counterexamples: pushing on every background step ↔ hiding an important result the user subscribed to deep in a log in pursuit of zero interruption.
Basisthis project's necessity-driven derivation; NR01 and NR02 provide reference for classification and interruption mechanisms.
N1-2Let consequence and time decide urgency
Applies toreminders with different intensities, deadlines, or exception bypass.
Requirement: The impact of not acting, the business deadline, and the last-useful reminder point MUST be recorded separately before deciding the presentation intensity. Time sensitivity MUST NOT be decided solely by the business side's "important" label. Escalation MUST have an allowed category, factual conditions, a bounded number of rounds, intervals, and stop conditions; urgency MUST NOT be automatically raised simply because nothing was clicked.
Exception bypass MUST simultaneously satisfy category eligibility, genuine platform capability, and applicable user permission; a product label grants no authority. Marketing MUST NOT use exception bypass. Approaching a deadline does not license crossing beyond the scope the user has turned off or paused.
Design decision: Distinguish "important but can be known later," "useful to handle now," and "already too late to handle." The third case shows the current outcome and a remedy entry, without a pointless nudge for something that has lost its meaning.
User-side verification: For the same task under different amounts of remaining time, the user can understand why a reminder fires or why it stops.
Implementation-side verification: Inject deadline changes, missing platform eligibility, and user opt-outs; check the escalation reason and the actual allowed scope.
Paired counterexamples: every message at the highest level ↔ letting a still-actionable important matter miss its window in order to respect the aggregation duration.
BasisNR02; the last-useful point and escalation boundaries are this project's derivation.
N2-1Ordinary notifications do not seize the current task
Applies towhile the user is editing, dragging, confirming, reading, or performing another continuous operation.
Requirement: An ordinary notification MUST NOT automatically shift focus, cover a key control currently being operated, or block submission. It SHOULD surface at a task boundary, a user-designated time slot, or in a digest; when context is unknown, keep a non-intrusive entry rather than treating a brief pause as evidence of idleness. If continuing the current operation genuinely requires a user decision, the question MUST be placed at the relevant task, stating the blocked step and the available paths.
Design decision: Choose the position and timing first, then choose a form such as a banner. A result already visible in the foreground SHOULD be fed back in place, without also sounding a notification for the same fact; "silent" does not hide the current submission's failure or pending-confirmation state.
User-side verification: When an ordinary completion message arrives during input, focus, input, and the submission position are preserved; when blocked, the reason can be found.
Implementation-side verification: Test focus, keyboard order, continuous reading, and the absence of context signals; record the actual presentation path.
Paired counterexamples: popping a modal window when an export completes ↔ putting every failure into a digest, leaving the user believing the submission succeeded.
N2-2Turning off and snoozing MUST take effect within the declared scope
Applies towhen a product offers optional notifications or the user adjusts notification settings.
Requirement: Entries to turn off by meaningful category, to snooze, and to reach settings MUST be provided, showing the events, accounts, devices, and channels affected. "No push on this device" and "stop contacting me about this kind of event" MUST be distinguished. Bypassing the choice by creating a new channel, switching category, or sending through a different medium is forbidden; an independent subscription outside the turned-off scope MUST NOT be mistakenly canceled either.
After a settings submission, the actual scope that took effect MUST be reported back; while sync is incomplete, show pending-sync rather than claiming every device has taken effect. Turning off MUST intercept affected reminders not yet submitted, and make a best effort to recall in-flight notifications the platform allows recalling; when already-sent content such as email cannot be recalled, state the limitation honestly.
Necessary account-security notices are handled separately only when the product explicitly lists the applicable basis, events, recipients, independent channel, limits on turning off, and failure disposition; "security" MUST NOT be used to expand the scope of ordinary notifications. Dedicated notices are likewise bound by platform permissions and content protections.
User-side verification: After turning off a category from Notifications, the user can state what will stop and what remains; when a capability is unavailable, no false success is shown.
Implementation-side verification: Separately test single-device turn-off, all-channel turn-off for a category, an independent email subscription, a necessary security notice, and settings sync on offline endpoints.
Paired counterexamples: quietly sending an SMS after phone push is turned off ↔ turning off one device incidentally canceling an independently subscribed email.
BasisNR01; scope adjudication and effect feedback are this project's derivation.
N2-3Request permission when the user understands the purpose
Applies toneeding system notification permission, or re-enabling a capability that was previously denied.
Requirement: The notification purpose SHOULD be explained and permission requested when the user subscribes, creates a reminder, or uses the related capability. Not-yet-decided, allowed, denied, and unavailable MUST be distinguished; dismissing an explanation page or not responding MUST NOT be recorded as allowed. After denial, the core task not dependent on this permission and an entry to view results MUST be kept available; repeated pop-ups, blocking unrelated flows, or misleading copy pressuring authorization are forbidden.
For a feature genuinely dependent on notifications, the capability gap and a workable alternative MUST be explained when the user sets it up; showing "you'll be notified on time" with no usable channel is forbidden. Re-requesting SHOULD be triggered by a clear functional need or the user's own action, and follow platform limits.
User-side verification: After denying notifications, the user can still complete the original task and knows where to check the result; they can proactively re-enable it from settings.
Implementation-side verification: Test allow, deny, canceling the request, and out-of-app permission changes; record the application-side toggle and the actual platform state separately.
Paired counterexamples: requesting every permission at first launch ↔ still not explaining why notification is unavailable even though the user has actively created a reminder.
BasisNR07.
N3-1Aggregation must preserve exceptions and release on time
Applies tocontinuous updates to the same task or object, or handling them together as a digest.
Requirement: Aggregation by task SHOULD occur, and unresolved exceptions, distinct deadlines, and per-item detail entries MUST be preserved. Groups MUST NOT mix content from different accounts or different visibility scopes. A preview-item count limits only the preview and does not delete the original record; a failed digest MUST fall back to a deterministic list, and a generative summary MUST NOT fabricate a resolved conclusion.
Aggregation MUST have a bounded release point. A fixed window starts from the group's first valid candidate; later arrivals do not extend it. If a trailing window is used, there MUST be a separate, non-extendable upper bound on waiting. When the window elapses, preferences and validity MUST be re-checked; when active delivery is not allowed, fall back to a reviewable silent result or an explicit next-permission point, never an indefinite postponement.
Design decision: The digest title states the object and the important change; items retain the earliest pending deadline; resolved matters do not crowd out matters still pending.
User-side verification: An unresolved exception can be found within a long list; after expanding, its own consequence and deadline can be distinguished from others.
Implementation-side verification: Continuously inject updates, conflicting states, revocation, and digest-generation failure; check the release upper bound and group permissions.
Paired counterexamples: a final success masking earlier failures ↔ ringing for every single item to avoid missing anything, losing the point of aggregation.
BasisNR05 provides reference on the update mechanism; the full aggregation contract is this project's derivation.
N3-2Re-verify current facts before release and before an action
Applies toqueuing, offline redelivery, expired notifications, deep links, or quick actions.
Requirement: The account, business object, current content, validity, and business state MUST be re-checked before releasing from the queue and before executing an action. An event already handled, withdrawn, or invalidated MUST stop active reminding and escalation; history may remain, but the current status MUST be labeled. When freshness is unknown, redelivery MUST NOT carry an outdated action promise.
View permission and action permission MUST be verified separately. A notification button MUST NOT skip a confirmation the business itself requires; once the target object or key content has changed, an old decision MUST NOT be applied directly to the new action. Double-clicks, cross-device duplicates, and timeout retries MUST NOT produce duplicate side effects; when the result is unknown, verify first — never display "completed."
User-side verification: Opening an expired item shows "ended" plus an available next step; repeated clicks produce only one business result.
Implementation-side verification: Inject revocation, account switch, withdrawal, out-of-order messages, lost post-submission receipts, and concurrent actions; check submission-side deduplication and result evidence.
Paired counterexamples: re-ringing an already-ended appointment confirmation after reconnecting ↔ deleting all history, leaving the user unable to understand what was missed.
BasisNR05; action verification and deduplication are this project's necessity-driven derivation.
N3-3Deferral SHOULD form a checkable arrangement
Applies tooffering "remind me later," a custom time, or quiet hours.
Requirement: The candidate reminder time, time zone, effective scope, and an editable or cancelable entry MUST be reported back; only when the scheduling mechanism has actually accepted the arrangement is it called "set," and acceptance does not guarantee delivery at that time. Relative durations and local clock times MUST be explained separately, and cross-time-zone and daylight-saving conflicts MUST have determinate rules.
A user deferral is a new, explicit request; it neither consumes nor resets the automatic-reminder quota; not clicking MUST NOT be treated as deferring. A deferral is still bound by user turn-off, platform permission, and business freshness. If the candidate time is later than the last-useful point, the possibility of missing the window MUST be stated before confirmation, offering an earlier time, viewing now, or canceling; the user may still choose to look later, but an already-invalid action MUST NOT be retained, nor a promise that it can still be handled at that time.
User-side verification: After deferring, the user knows when they will be reminded again and how to cancel; when a reminder could not be scheduled, they are not led to believe it succeeded.
Implementation-side verification: Restart, go offline, change time zone, confirm repeatedly, and have an old task callback after cancellation — each case can be traced to a unique arrangement and its current status.
Paired counterexamples: "later" with no time and no record ↔ refusing a user-initiated reminder because the automatic quota is exhausted.
Basisthis project's necessity-driven derivation; platform scheduling outcomes must be tested on the actual target product.
N4-1Information can be read, perceived, and reviewed
Applies towhen a banner, badge, sound, haptic, or notification center conveys information.
Requirement: The source, object, change, and necessary next step MUST be expressed as text or an equivalent; relying on color, sound, vibration, or a brief appearance alone is forbidden. States and actions MUST have an accessible name, role, and state; a dynamic status message MUST be perceivable by assistive technology without moving focus. Ordinary continuous updates SHOULD be merged to avoid repeated announcements; urgent announcement is used only for messages that genuinely require immediate perception.
After a transient prompt disappears, reachable equivalent content MUST exist; a critical action MUST NOT have only a brief entry. A processing deadline the product itself sets MUST provide a mechanism to close, adjust, or extend it, or record the applicable real-time / necessity exception. An ordinary review entry does not substitute for checking a time-limited business matter itself. When the system controls the banner's duration, a custom duration is not guaranteed to have taken effect.
A badge MUST define its counted object and clearing condition; unread count, pending count, and unsynced count MUST NOT be conflated. When text is enlarged, on narrow screens, or with long text, access to key information and actions MUST be preserved; notification motion SHOULD support the reduced-motion preference.
User-side verification: With mute, screen reader, keyboard operation, enlarged text, and a missed banner, the user can still understand and act; opening it does not incorrectly zero out a pending count.
Implementation-side verification: Check the accessibility tree, focus order, continuous announcement, hidden content, and time limits; record the parts owned by the platform and by the application separately.
Paired counterexamples: only a red dot lighting up, with no text and no record ↔ urgently announcing every percentage point of progress.
N4-2Return to the original task after handling a notification
Applies towhen a notification opens details, jumps to another page, or launches a handling flow.
Requirement: Input allowed to be saved, the entry to the original task, and the resume position MUST be protected, with an understandable return path provided. Persisting credentials or other disallowed input without authorization, merely for the sake of recovery, is forbidden. When recovery is not possible, what will be lost MUST be stated before leaving, offering a viable choice such as staying put, saving first, or viewing in place.
The genuine business result MUST be reported after handling; when the result is unknown, provide a verification entry. Permission and the object's current state SHOULD be re-checked before returning, protecting any new edits the user has made, without automatically replaying an action that has an external effect. Jumping to an in-site page requires these same protections.
User-side verification: Handling a notification midway through editing and returning preserves input, reading position, and focus; failure and pending-verification can be distinguished.
Implementation-side verification: Test paths where the page unloads, the session expires, the original object is modified or deleted, or a sensitive field cannot be saved.
Paired counterexamples: clicking a notification clears the draft ↔ forcing a full replay of the operation history just to restore the task.
BasisNR03; the concrete recovery mechanism is this project's derivation.
N4-3Presentation scope matches the current audience
Applies tolock screen, screen casting, external audio, shared devices, or notifications containing sensitive content.
Requirement: The title, body, thumbnail, summary, and announced content MUST be adjudicated by content sensitivity, account permission, current audience, and platform settings. An unknown audience MUST NOT default to public; a meaningful redacted hint SHOULD be used, with an entry to view details after verification. A notification digest MUST NOT expand the visible scope of the original event.
After signing out or having permission revoked, subsequent sensitive presentation MUST stop and previews the application can control MUST be cleared; content already delivered to an unrecallable medium MUST NOT be claimed as deleted. Lock-screen quick actions still MUST satisfy the identity verification the action requires.
User-side verification: A shared screen shows only necessary information such as "one item pending confirmation"; once authorized to view, the specific content can be understood.
Implementation-side verification: Check all presentation surfaces and caches under lock screen, screen casting, screen-reader external audio, account switching, and unknown audience.
Paired counterexamples: the body is redacted but the title exposes the customer's name ↔ forcing strong authentication for every low-sensitivity reminder, leaving the user unable to quickly learn the status.
BasisNR05; audience and the constraint on the full presentation surface are this project's derivation.
N5-1The same event shares one reminder plan and one stop condition
Applies towhen in-app, push, email, sound, or multiple devices jointly participate in reminding.
Requirement: The primary channel, active-reminder target, fallback conditions, and stop condition MUST be coordinated by account, event, and round. The same round MUST NOT be interrupted preemptively by multiple channels or devices acting independently; an unknown receipt MUST NOT be treated as undelivered and blanket-resent. Cross-device deduplication and escalation share the same event identity and the same stop basis; being unread does not by itself make an event more urgent. Without reliable coordination capability, a predetermined single active target or a silent fallback MUST be used; a guarantee of "only rings once" MUST NOT be promised.
Content refreshes and transport retries MUST NOT increase the reminder quota; duplicate submissions must share a deduplicatable identifier. Already handled, expired, and turned off take priority in blocking new rounds. After a definite failure, a bounded, already-permitted plan MAY redirect delivery; cross-device read state and business-handled state MUST be synced separately. The condition for automatically re-reminding after the user dismisses the current notification MUST be made explicit in advance; when undeclared, automatic interruption for that event stops. This rule governs the declared scope of general-purpose notification policy; the closable scope and fallback for dedicated functions such as industrial alarms or vehicle warnings are decided by their own domain's contract, and MUST NOT be overridden by consumer-grade silent defaults that supersede an already-assumed dedicated obligation.
User-side verification: After handling it in one place, no new nudge appears on other endpoints; the reviewable record remains, and an unknown state is expressed honestly.
Implementation-side verification: Test concurrent scheduling, lost receipts, offline recovery, content updates after turn-off, and sequential handling across multiple endpoints; check the round ledger and the deduplication mechanism.
Paired counterexamples: phone, computer, and email all nudging the same matter at once ↔ deleting the history entry on every endpoint to avoid duplication.
Basisthis project's necessity-driven derivation; platform acceptance and actual presentation capability must be verified separately.
N5-2Evaluate notifications by task benefit and long-term burden
Applies tonotification categories in sustained use.
Requirement: Observable requests, presentations, deferrals, dismissals, invalidations, and effective handling MUST be recorded by category, stating the unit, statistical subject, window, dedup key, denominator, and handling of missing data. Read, dismissed, or successfully sent MUST NOT be treated as effective handling, and value MUST NOT be proven by click rate alone; an unobservable portion MUST be labeled unknown and its coverage reported, not counted as zero.
Task outcome, missed deadlines, recovery cost, and subjective burden SHOULD be combined to check the same user's total cross-category burden. Collection MUST be limited to the minimum information the purpose needs, with the retention scope and accessors specified; continuously collecting screen content merely to measure disturbance is forbidden. The product MUST have an owner who can disable an unhelpful category or adjust the policy.
User-side verification: After adjustment, the user finds it easier to handle useful matters and can express a sense of disturbance; low-click awareness-only categories are evaluated separately.
Implementation-side verification: Check the denominator, observation coverage, sample variance, and missing values; comparisons must report task effect alongside, not just a drop in volume sent.
Paired counterexamples: raising frequency because click rate went up ↔ hiding a critical failure to reduce notification volume, leaving the user to keep checking on their own.
BasisNR03; the metrics contract is this project's derivation.
N5-3Burst events must not break through the total-burden ceiling
Applies towhen batch events, multiple categories, or multiple producers may remind simultaneously.
Requirement: A burst-handling policy MUST be defined for the same recipient, capping the cumulative count of active-reminder requests, and stating the statistical scope, window, quota, queuing upper bound, and overflow disposition. Limiting only single-event rounds while letting a large number of different events interrupt simultaneously is forbidden; the quota MUST cover concurrent competition, and splitting into categories or retrying MUST NOT evade it.
Beyond the quota, items SHOULD be merged, silenced, or deferred, keeping an entry for important pending items; ending quiet hours or reconnecting after being offline MUST NOT release every past reminder at once. A critical exception MUST list an independent basis and a bounded plan, and MUST NOT become an unlimited exit. Reminders the user has explicitly scheduled MUST be identified independently; when several coincide, there MUST still be a previously declared merging or ordering method, rather than silently dropping them.
User-side verification: During a batch failure, the user can see the scope of impact, the most important pending item, and the complete list, without experiencing continuous banners or ringing.
Implementation-side verification: Inject multiple categories, a large number of independent events, and concurrent sends at the same time; check the quota reservation, release upper bound, and whether important matters remain discoverable.
Paired counterexamples: each item reminding only once, yet ringing a hundred times within a minute ↔ dropping everything, leaving the user unaware a batch task failed.
Basisthis project's necessity-driven derivation; no universal daily ceiling is proven by any cited material.
4. Decision method from event to handling
4.1 Choose the behavior first, then the component
| Situation | Recommended handling | User capability that MUST be preserved |
|---|---|---|
| No meaningful change or a duplicate fact | Do not create a new reminder; update the existing record | View the current result |
| Success/failure of an action on the current page | In-place status feedback; attach a recovery method to errors | Understand the result, continue, or correct |
| Has notice value, no immediate action needed | Notification center, a silent entry, or a digest | Find the result, adjust the subscription |
| A decision is needed, but there is ample time | Task inbox and a digest within the permitted time window | View the consequence, defer, or turn off |
| Handling now can still avoid a loss | A timely reminder within the permitted scope | Understand the deadline, take action, or decline |
| Business confirmation is needed to continue | Present the decision request at the relevant matter | Explicit consent, refusal, or exit; no response does not proceed |
| Already invalidated, already handled, or currently unverifiable | Update the record, verify, or provide a remedy entry | Understand the current status; do not execute the old action |
Non-intrusive, ordinary reminder, and exception bypass are presentation intensities; immediate and deferred are time arrangements. The two are decided separately. Permission for notification does not automatically grant permission for a business action.
4.2 Lifecycle and adjudication order
A notification candidate can enter a silent record, a queue, or a delivery request. After a request, service acceptance, device receipt, and presentation are each recorded separately, per the evidence actually obtained; read, dismissed, and deferred are independent user actions. The business object separately maintains states such as pending, handled, and invalidated. An unknown stage does not erase a known stage, nor does it infer a subsequent stage.
Each candidate release is checked in sequence: business facts and account permission → user choice and platform gating → last-useful point → category and aggregation policy → cross-category budget and round → channel coordination → current audience and presentation. At the submission point, the stop condition that may have changed concurrently is checked again. When no viable delivery exists, return an explicit result of silent, invalidated, or insufficient capability, without retrying indefinitely.
The aggregation window, deferral point, business deadline, banner dwell, transport retry, and burden-statistics window are different time objects and MUST be managed separately.
4.3 One complete journey
While a user is editing a report, a background export needs the save location re-selected:
- The event is registered as "export pending," stating that the file has not yet been generated; the editing user's focus is not seized, and an accessible state appears at the task entry.
- Within the user's permission digest, the system aggregates repeated failures of the same export; a new failure does not reset the waiting upper bound, and the preview retains "location selection needed."
- The user defers; the interface shows the candidate time and the original task state; if the temporary file is about to be cleared, the time conflict is stated before confirmation.
- The user clicks the notification; the current account, temporary file, and permission are re-checked before the handling interface opens; the draft and the return position are protected.
- After the save location is submitted, the receipt is lost; the interface shows "verifying the export result"; the real result is checked first, without blindly re-writing.
- Once business confirmation completes, new reminders on other endpoints stop; the user returns to the report with the draft preserved; the notification history records "completed," never inferred from being read.
5. Acceptance matrix
Each entry retains the input facts, user settings, resolved configuration, expectation, user observation, implementation evidence, and limitations. Judge pass / fail / not applicable and record the reason; a failed required item cannot be offset by an average score.
| Scenario / fault injection | The user should observe | Implementation evidence | Rules |
|---|---|---|---|
| An ordinary completion message arrives during input | Focus is not seized; the result can be found later | Focus record, status semantics, and record entry | N2-1, N4-1 |
| Permission denied, request canceled | The original task continues; reminder capability is shown honestly | Permission state and subscription fact kept separate | N2-3 |
| Phone push turned off, an independent email subscription kept | Declared scope is accurate, neither bypassed nor wrongly turned off | Decision scope, actual channel adjudication | N2-2 |
| Continuous updates, digest generation failure | An understandable list on time, exceptions not lost | Group permission, release upper bound, fallback record | N3-1 |
| Deferral past the deadline, time-zone switch, restart | Conflict stated first; arrangement checkable and cancelable | Clock basis, unique arrangement, and re-verification | N3-3 |
| Offline redelivery when already handled / withdrawn | No further nudging; the old button no longer works | Current business state and submission verification | N3-2 |
| Account switch, revocation, double-click, and a lost submission receipt | No overreach, no duplication; unknown states can be verified | Action binding and concurrency deduplication | N3-2 |
| Lock screen / screen casting / unknown audience | All previews and announcements protect content consistently | Audience source, redaction, and permission adjudication | N4-3 |
| Screen reader, enlarged text, time-limited action | Information perceivable; critical action reachable | Semantics, focus, timing mechanism | N4-1 |
| Returning to the edit page after handling a notification | Draft and position preserved, or loss known in advance | Resume point and up-to-date object verification | N4-2 |
| Multi-endpoint concurrency, unknown receipt, update after turn-off | No blanket resend; no restarting automatic nudging | Same round, target coordination, stop condition | N5-1 |
| Multi-category burst, reconnection, or end of do-not-disturb | Digest handleable; no chain of consecutive rings formed | Cumulative budget and concurrency reservation, overflow result | N5-3 |
| Presentation unobservable | The report does not write missing data as zero | Metric denominator, coverage, and unknown values | N5-2 |
| A simple matter needing no immediate handling | Not slowed down by permission explanations, confirmations, or recovery steps | Minimal path and interaction-burden observation | N1-1, N2-3, N4-2 |
Document review can only prove the consistency of rules, fields, and references. Actual platform delivery, assistive-technology behavior, and net user benefit MUST be separately verified against target scenarios; a small number of passing samples does not prove notifications always arrive or never repeat.
Implementation acceptance scenarios
The scenarios below turn existing clauses into reviewable acceptance inputs and set no universal performance thresholds. Select by the product's applicable capabilities and supply real devices, users, input sequences, and evidence; record the reason when inapplicable — unexecuted MUST NOT be recorded as passed.
| Clause | Test input and anomaly | Expected behavior and failure criteria |
|---|---|---|
| N3-1 | Continuous updates keep pushing the trailing aggregation window further back. | The waiting upper bound still holds; permission and event freshness are re-checked at release. |
| N2-2 | The user turns off all channels for a category; unsent emails remain in the queue. | Interception happens within the declared controllable scope; the independent subscription is not wrongly deleted. |
| N5-1 | An ordinary completion notification and an industrial alarm occur concurrently. | Adjudication follows each one's own applicable contract; deduplication does not swallow the other's genuine risk. |
For each scenario, check separately the effective values of the configuration, execution records, and user-comprehensible results. Retain versions, goals, event timing, failure scope, and recovery outcomes; externally unknown outcomes are filled in as neither success nor failure.
Turn notification design decisions that have already been made into reusable, parsable, verifiable presentation values and behavior configuration.
For experience requirements see Design Guidelines; for external basis see Sources and evidence boundaries. Filling in a field does not mean a notification capability has come into being; every behavioral promise needs a real mechanism and operational evidence.
1. Types, decision authority, and usage rules
1.1 Four kinds of content stored separately
| Layer | Namespace | Content | Decision-maker and boundary |
|---|---|---|---|
| Visual Design Token | attention.visual.* | Color, typography, spacing, shape, and motion-semantics aliases | Design-system maintainers; themes affect only presentation |
| Interaction parameters | attention.interaction.* | Preview count, waiting duration, deferral candidates, etc. | Product chooses per task; a legal range does not represent the best experience |
| Policy configuration | attention.policy.* | Allowed behavior, capability dependencies, conflict adjudication, and fallback | Product and organizational constraints; user choice can only take effect within the allowed range |
| Operational facts | attention.runtime.* | User decisions, events, permissions, scheduling, delivery, and results | From users, platforms, and business services; MUST NOT be fabricated with default values |
Only the visual-token subtree uses DTCG's $type, $value, and alias forms. Behavioral parameters use this dictionary's own project types and do not fake DTCG types such as policy or permission; the combined configuration as a whole is not a DTCG file. The DTCG format specification is a community report, not a W3C Recommendation.
1.2 Required, default, and empty values
- Basic-required: MUST be made explicit once this notification capability is enabled; may explicitly inherit a product preset and does not require the user to fill it in.
- Conditionally required: filled in only when the corresponding capability is enabled; omitted when not enabled — a feature is not enabled just to fill in a field.
- Optional: configured when there is an explicit differentiation need.
- Inheritance MUST resolve to a determinate value, source, and applicable scope; an unknown field, circular reference, type conflict, illegal enum, or missing required dependency MUST raise an error and disable the affected capability. A configuration failure MUST NOT escalate interruption intensity, nor hide the online feedback the current operation needs.
nullis not allowed to stand in for unknown, off, or unlimited; examples and the dictionary do not usenull. An explicit off state uses an enum, unknown uses a fact state, and an inapplicable capability uses field omission plus a resolution note.- Durations in behavioral parameters use safe-integer milliseconds, with names ending in
Ms; counts use safe integers. Visualdurationfollows DTCG's value-and-unit structure and is not mixed with behavioral parameters. A calendar-day window usesDaysand specifies the reporting time zone; it must not be directly converted into continuous milliseconds. Arrays are deduplicated; enums are case-sensitive. - Absolute time uses an RFC 3339 timestamp with an offset; a recurring local time slot MUST additionally have an IANA time zone plus rules for crossing midnight and daylight saving. Relative waiting uses a reliable elapsed-duration basis; a business deadline uses a trusted business time; when the clock is uncertain, verify first.
1.3 Who may change it, and when it takes effect
A visual theme cannot modify policy, and policy cannot fabricate user consent. The user's text-scaling and reduced-motion preferences MUST reach actual presentation. Multiple effective hard limits take their common allowed range; the limits are not relaxed on a "last write wins" basis.
Turning off, revoking, and tightening a policy immediately constrain reminders not yet submitted; while settings sync is incomplete, show pending-sync. Relaxing configuration does not revive an already-turned-off or invalidated queue, and does not reset already-consumed rounds or user choices. A user decision within the same scope is superseded by an explicit new decision; when scopes overlap and the superseding relationship cannot be confirmed, take the stricter result, and provide an understandable adjustment entry for the user.
2. Visual Design Token
The table below gives semantic aliases, not a brand palette. {product.*} is an integration placeholder path that MUST be mapped to a real, type-compatible token that exists in the product. Every value takes effect only on presentation surfaces the application controls; a part the system template cannot customize is marked not applicable, and a requested value is never reported as the actual value.
| Full name | DTCG type | Referenced value | Design intent and acceptance |
|---|---|---|---|
attention.visual.title | typography | {product.typography.bodyStrong} | Object and primary state; must not truncate the sole basis for action after enlarging |
attention.visual.body | typography | {product.typography.body} | Change, reason, and next step; supports the user's text settings |
attention.visual.metadata | typography | {product.typography.caption} | Source, time, scope; necessary information must not be weakened to the point of being hard to read |
attention.visual.foreground | color | {product.color.textPrimary} | Body foreground; verify contrast against the actual background combination |
attention.visual.secondaryForeground | color | {product.color.textSecondary} | Secondary information; not a license to reduce readability |
attention.visual.surface | color | {product.color.surfaceRaised} | Notification container; verify against light/dark theme and high-contrast settings |
attention.visual.border | color | {product.color.borderDefault} | Group boundary; not used as the sole state signal |
attention.visual.actionRequired | color | {product.color.statusWarning} | Auxiliary color for something needing handling; MUST also have text or icon semantics |
attention.visual.focusRing | color | {product.color.focusRing} | Visible focus; stroke thickness etc. are guaranteed by the product's components, and the color alone does not guarantee accessibility |
attention.visual.inset | dimension | {product.space.containerInset} | Container inset; does not shrink the action target |
attention.visual.groupGap | dimension | {product.space.group} | Digest group spacing; does not affect list reading or focus visibility |
attention.visual.cornerRadius | dimension | {product.radius.surface} | Consistent with the product's container form |
attention.visual.enterDuration | duration | {product.motion.duration.fast} | Enter transition, not dwell duration; use the component's static path under reduced motion |
Corresponding rules: N3-1, N4-1. Font size, contrast, action target, focus, and motion MUST be verified in the actual combination; a token reference existing does not mean these properties are already satisfied. When a visual alias cannot be resolved, use the product's already-validated base component; do not fall back to transparency, zero font size, or hiding.
3. Interaction parameters
The initial values below are all prototype starting points pending validation against target scenarios, not research thresholds. A product may choose a different legal value and record the rationale and user-testing evidence.
| Full name | Level / type / unit | Legal value and initial value | Meaning, dependency, and rule |
|---|---|---|---|
attention.interaction.previewItems | Required when aggregating / integer / items | ≥1; initial value 3 | Limits the initial preview; full detail remains reachable; N3-1 |
attention.interaction.digestWindowMs | Required when aggregating / integer / ms | >0; initial value 300000 | A fixed window is timed from the first valid candidate; a trailing window is timed from the last update and is bounded by an independent upper bound; N3-1 |
attention.interaction.digestMaxWaitMs | Required for a trailing window / integer / ms | ≥ digestWindowMs; no universal initial value | Starts from the first valid candidate; subsequent arrivals do not extend it; left blank for a fixed window; N3-1 |
attention.interaction.snoozeOptionsMs | Required when offering deferral / integer[] / ms | Positive integers, ascending, deduplicated; initial value [900000, 3600000] | A candidate menu, not directly establishing an arrangement; an empty array is legal only when a separate custom-time entry exists; N3-3 |
attention.interaction.toastDurationMs | Required when the app self-controls an auto-dismissing prompt / integer / ms | >0; no universal initial value | Controls only the transient presentation; an equivalent reviewable content MUST exist; does not change the business time limit; omitted for persistent or system prompts; N4-1 |
attention.interaction.reviewWindowDays | Required when burden review is enabled / integer / calendar days | >0; initial value 14 | Takes complete calendar days by the reporting time zone's day boundary; N5-2 |
No "universally optimal banner seconds," "default daily ceiling," or sound-intensity constant is provided. When the application cannot control the system volume, system dwell time, or actual delivery time, a token MUST NOT be used to fabricate a control capability that does not exist.
4. Policy configuration
Short keys in the table below are all prefixed with attention.policy.. A contract reference is a structured decision record resolvable within the product, not a link to a separate specification; each item MUST have an owner, applicable categories, an actual implementation entry, and acceptance evidence.
4.1 Base and capability configuration
| Field | Level / type | Value and minimum content | Default or failure behavior | Rules |
|---|---|---|---|---|
categoryContract | Basic-required / ref | See §4.2; benefit, recipient, and trigger basis | Missing means no new notification is sent; only records with retention rights are kept | N1-1, N1-2 |
interruption | Basic-required / object | mode: record / defer / notify; the latter two additionally include level: passive / active / exception, platformMapRef; defer also needs scheduleRef | Conservative preset {mode: record}; record omits level and platform mapping | N1-2, N2-1 |
preferenceDefaultScope | Required when there is a settings entry / enum | event / category / global; only an initial UI suggestion | Initial value category; does not represent an actual decision | N2-2 |
permissionPrompt | Required when system permission is needed / object | trigger: contextual / userInitiated, rationaleRef, deniedFallbackRef | Missing means no automatic permission request; capability status can still be shown | N2-3 |
quietScheduleRef | Required when quiet hours exist / ref | Time zone, time slot, cross-midnight and daylight-saving handling, allowed scope, backlog disposition at the end | Not filled in does not mean the system do-not-disturb is off; the real user and platform limits are still followed | N2-1, N3-3 |
grouping | Required when aggregating / object | groupKey, clock: fixed / trailing, releaseConditionRef, summaryFallback: deterministicList; groupKey includes accountId, taskId, visibilityScopeId | A missing dependency disables aggregation, without raising the reminder intensity | N3-1 |
expiryContract | Basic-required / ref | Validity, trusted time, last-useful point, re-verification method, and history retention | Without a basis, no proactive delivery of a time-sensitive event, and no stale action enabled | N3-2 |
snooze | Required when offering deferral / object | customTimeEnabled: boolean, scheduleContractRef; a candidate or a custom entry MUST exist | Missing a scheduling mechanism means no deliverable deferral promise is shown | N3-3 |
presentation | Required when presenting a notification / object | surface: platform / persistent / transient, announcement: none / polite / urgent, historyRef, contentContractRef | Missing means no sensitive preview is shown; the current state is still fed back via an already-validated component | N4-1, N4-3 |
badge | Required when using a badge / object | meaning: unread / pending / unsynced, scopeRef, clearConditionRef | Undefined means no count badge is shown | N4-1 |
resumeContract | Required when leaving an editable task / ref | Save scope, return entry, verification method, and the protection path when saving is impossible | Missing means only in-place viewing, or the user chooses after being told of the leaving loss | N4-2 |
channelPlan | Required when mode is not record / ref | Primary target, allowed channels, deduplication scope, bounded fallback, unknown-receipt disposition | Missing means no active-delivery request is made; a single endpoint may implement a local plan | N5-1 |
escalation | Required when mode is not record / object | maxRounds a positive integer including the first; dismissal: stop / followDeclaredPlan; when greater than 1, also needs minIntervalMs a positive integer and eligibilityRef | Initial value maxRounds=1, dismissal=stop; missing dependency means no further automatic reminder | N1-2, N5-1 |
burstControl | Required for multi-category or burst active reminding / object | scope: accountAllCategories, windowMs a positive integer, maxInterruptions a positive integer, overflow: digest / record; digest additionally needs a bounded release plan | No universal quota; when the budget or coordination is unknown or fails, go silent without resetting the ledger | N5-3 |
burdenReview | Required for a category in sustained use / object | metricsRef, reportTimeZone, owner, retentionRef; the calendar-day window is in the interaction parameters | Without presentation evidence, only request counts and coverage gaps are reported | N5-2 |
ref is a non-empty string that MUST resolve to the minimum contract below. All *Ref and *Contract fields follow the same resolution requirement; an example placeholder does not count as satisfying the dependency. groupKey may add business dimensions but must not remove account and visibility-scope isolation.
announcement=none only means this presentation does not additionally trigger an automatic announcement; it must not hide a status message that requires perception. If the status is already conveyed by the current task's accessible feedback or a system template, that carrying path MUST be recorded and verified not to duplicate the announcement. Presentation details of the platform surface are decided by the system; the configuration only expresses the request and the capability requirement.
4.2 Minimum structure of referenced contracts
| Contract | Design content that MUST be made explicit |
|---|---|
| Category | Category identifier and user-facing name, owner, receipt basis, trigger and event-identity rules, notice/action benefit, consequence of not reminding, allowed channels, next step; a necessary independent notice additionally lists its own applicable basis, limits on turning off, and failure disposition |
| Platform mapping | The actual request method, capability check, and the more conservative fallback for passive/active/exception on the target platform; the eligibility and permission basis for exceptions, forbidding mapping every anomaly uniformly to the highest level |
| Validity | Business-state source, validity mode deadline / whileRelevant; the former has a deadline and processing margin, the latter has re-verification relevance conditions and a validity window; both have termination conditions — no ungrounded infinite TTL is used |
| Scheduling / release | Start point, allowed time slot, time zone, trusted clock, last-useful point, maximum wait, re-verification, accept/failure feedback, query and cancel entries; the silent or invalidated result when no viable time point exists |
| Permission-request rationale and denial fallback | The specific purpose, the functional trigger point, the task and result-viewing entry still usable without permission, the path requiring the user to actively re-enable |
| Content presentation | The displayable source, object, and state; content sensitivity and audience source; substitute expression for lock screen / casting / external audio / unknown audience; name, role, state semantics, and history entry; an action contract embedded when an action exists |
| Quick action | Binding to the object and current content, view/execute permission, required confirmation, a submission deduplication identifier, result verification, and a failure entry; "just call the button API" is not sufficient |
| Return to the original task | Fields allowed to be saved and their retention period, the original task's position, the return entry, re-verification of permission and object; advance notice and the optional path when saving is not possible |
| Channel plan | Account and event round scope, the predetermined active target, the recallable scope, suppression of repeated requests, and a bounded fallback for a definite failure; no redirect when unknown; degrades to a single target when there is no coordination capability |
| Automatic escalation eligibility | Allowed category, new factual conditions, the last-useful point; stops when already handled / invalidated / turned off / permission invalidated; followDeclaredPlan needs to state the bounded conditions for still reminding after turn-off |
| Metrics and retention | Metric name, unit, statistical subject, dedup key, denominator, observation coverage, missing-data handling, calendar-day boundary, retention period, accessors, review responsibility, and a disable entry |
| Badge scope and clearing | The counted business set, data freshness, the intersection with display permission, and which user action or business fact decreases the count; an unknown value shows no false zero |
5. Timing, quota, and coordination
5.1 Resolution order
- Validate configuration types and conditional dependencies; resolve all references, retaining the decision source and applicable scope.
- Obtain the current account, business state, content, and validity. Already handled, invalidated, withdrawn, or revoked events stop first.
- Apply the user's choice, system permission, and quiet hours. Unknown does not manufacture permission; when exception eligibility is unclear, bypass is not allowed.
- Compute the aggregation or deferral candidate time and compare it against the last-useful point; when no viable time exists, go silent or terminate the candidate.
- Check the event round and the cross-category budget, reserving a quota and confirming the primary target at a concurrency-safe submission point.
- Check the current audience, generate the corresponding content, and present it using the user's accessible settings and actual platform capability.
- Update the delivery facts per the evidence actually received; never jump from service acceptance to inferring presentation, still less to inferring that the user has handled it.
Fixed digest candidate: first valid candidate time + digestWindowMs.
Trailing digest candidate: min(last valid update time + digestWindowMs, first valid candidate time + digestMaxWaitMs).
The formula produces only a candidate; it does not authorize an interruption. If the permitted time slot is not satisfied, end this digest at the aggregation upper bound and generate a silent summary, or proceed to the next permitted time point per an already-declared plan; the latter MUST have an independent, bounded deadline. Restarting aggregation to indefinitely extend it is forbidden.
The last-useful reminder point is formed by subtracting a reasonable handling margin from the business deadline. The margin is decided by task research, accessibility needs, and the actual pipeline, with no universal default; when it cannot be estimated, a promise of timely delivery sufficient for handling MUST NOT be made.
5.2 The meaning of rounds and burst quota
maxRoundscounts the automatic logical reminder rounds for the same event, including the first; content refreshes and transport retries follow the same round. Within a single round, only one active target is allowed at any moment; after a definite failure, redirect delivery per an established bounded plan — do not redirect when the outcome is unknown. Retries and fallback within a single round are additionally bound by the channel plan's attempt cap.- A user's explicit deferral is saved as an independent arrangement with its own trigger reason; it neither consumes nor refreshes the automatic round. When multiple user arrangements coincide, they are merged or ordered per the scheduling contract, keeping each one visible.
maxInterruptionscounts the reserved count of automatic active-reminder requests within the window, across categories and across active channels for the same account — not the actual number of times attention occurred. Automatic active and exception reminders both count; a user's explicit arrangement and a dedicated independent notice each follow their own already-declared bounded plan and MUST NOT default to unlimited. The merging or ordering rule for user arrangements that conflict at the same moment MUST be stated when the arrangement is made, and MUST NOT silently drop them because the automatic budget is exhausted; a burden report counts both automatic reminders and user arrangements together, and MUST NOT treat separate accounting of the two as a reduced total burden.- The budget is reserved before the request. Only when evidence can prove no active presentation is possible at all is the corresponding reservation released; acceptance or an unknown result MUST NOT be refunded and followed by continued nudging. The same transport retry suppressed by deduplication adds no new logical quota, but MUST NOT bypass the attempt cap.
- The window in this dictionary is a continuous
windowMsrolling window, with endpoints(now-windowMs, now], not a calendar day. When a shared ledger is unavailable, the total across all endpoints MUST NOT be claimed as controlled; take the conservative path of going silent or a fixed single target.
5.3 Illegal combinations and acceptable results
| Input / combination | Verdict and result |
|---|---|
mode=record yet level=exception is filled in | Reject; a record-only mode has no platform interruption level |
mode=defer missing scheduleRef | Reject enabling the deferred notification; do not show it as set |
clock=trailing missing a bounded digestMaxWaitMs | Reject; continuous updates cannot extend indefinitely |
digestMaxWaitMs less than digestWindowMs | Reject; this dictionary requires the upper bound to be no shorter than a single waiting window |
snoozeOptionsMs empty and customTimeEnabled=false | Reject; deferral is promised with no entry |
surface=transient missing historyRef or toastDurationMs | Reject; use persistent presentation or complete the dependency |
| The sole entry for something needing handling placed in an auto-dismissing prompt | Reject; a persistent, equivalently reachable entry MUST also exist |
announcement=urgent used for ordinary progress | Reject; choose polite and merge repeated status |
maxRounds is 0, negative, or a fraction; or greater than 1 with no interval / eligibility | Reject; turn off with mode=record, not with an illegal value |
burstControl.overflow=digest with no release plan | Reject; record may be explicitly chosen |
| Platform state still allows it after the user turns it off | The user's turn-off takes effect; platform allowance does not restore the subscription |
| Receipt unknown, budget remaining unknown, clock uncertain | Each is kept as unknown; no indefinite resending, no filling with zero, no promise of punctuality |
| A draft cannot be saved but the notification demands navigation | View in place, or state the loss first and offer the user a choice |
6. Runtime fact contracts
Operational facts are not written into theme files. All external facts are expressed as an envelope:
| Envelope field | Type and constraint |
|---|---|
knowledge | known / unknown / stale / unavailable; known means currently available, stale means there is an outdated observation |
source | A non-empty source identifier, naming the user, platform, or business mechanism |
value | Present only when knowledge=known; an unknown MUST NOT be filled with an optimistic default |
observedAt | Filled in only when the current observation was actually obtained; required for known |
lastKnown | Required for stale, containing the old value and old observedAt; unknown / unavailable may retain a historical clue that does not participate in the current permission judgment |
attemptedAt | Optional; records the time a fact-retrieval attempt was made; does not impersonate an observation moment |
Whether a fact is fresh enough is specified by the consuming contract; it becomes stale once expired. This dictionary does not require the platform to provide evidence that cannot be observed. Event identifiers and internal ledgers are not user-adjustable tokens.
| Full name | Primary fact and source | Consumption boundary |
|---|---|---|
attention.runtime.event | Business service: accountId, eventId, taskId, visibilityScopeId, contentFingerprint, businessState, validity, and the last-useful point | Re-verified when the object's content changes; does not automatically produce a new event or a new quota |
attention.runtime.preference.decisions | User: decisionId, account, event/category/global selector, channel and device scope, effect, effectiveAt, source; a snooze additionally has until | effect is allow/disable/pause; a global choice is still limited to declared optional categories and is never generated from a default toggle |
attention.runtime.preference.platformState | System: application and channel permissions, available capabilities, actual settings | Platform allowance does not equal user subscription; unknown does not license a bypass request |
attention.runtime.taskContext | Current task: editing, confirming, reading, known task boundaries, and inference source | Unknown does not seize focus, nor does a pause infer idleness |
attention.runtime.audience | Current presentation environment: lock screen, sharing, casting, audio routing, and visible scope | Treated as unknown when the signal is unreliable; does not guarantee automatic identification of every audience |
attention.runtime.schedule | Scheduler: scheduleId, the bound user decision, candidate time, time zone, accept/failure/cancel/trigger and the actual time | Request and acceptance are stored separately; a callback after cancellation MUST be intercepted |
attention.runtime.delivery | Coordination service: eventId, roundId, attemptId, target; a separate fact envelope for each of requested/accepted/received/presented | Not merged into one mutually exclusive state; read and dismissed are independent facts; presentation does not equal attention |
attention.runtime.roundLedger | Reminder coordination mechanism: the event's automatic rounds used, the reason, turn-off handling, and the retry/fallback ledger | User deferrals are listed separately; a content refresh or restart does not zero it out |
attention.runtime.budget | Quota mechanism: statistical scope, window, reservation, submitted amount, explicit release, and basis | Concurrency-consistent; an unknown presentation is not treated as unconsumed |
attention.runtime.resume | Save mechanism: the original task's entry, the fields allowed to be saved, position, and binding to current content | Permission and any new edits are re-verified before recovery; sensitive credentials are not restored |
attention.runtime.burden | Minimal telemetry: per-metric result, denominator, unit, window, coverage, and unknown amount | Business completion is not inferred from opening or dismissing |
7. Readable configuration examples
Examples only illustrate field combinations; they do not prove a platform, contract, or component has been implemented. example.* and {product.*} are both integration placeholders that MUST be replaced and resolved before use. In the JSON, the short keys under interaction and policy each carry this dictionary's full prefix. All values below are prototype values.
7.1 A minimal record-only category
No external notification, aggregation, quick action, or navigation is enabled; a complete notification form need not be filled in. The example category includes an entry that shows the result on the current page and a legal retention scope.
{
"policy": {
"categoryContract": "example.export-result",
"interruption": { "mode": "record" },
"expiryContract": "example.export-result-validity"
}
}
If this category runs on an ongoing basis, burdenReview and a corresponding observation window are also needed; being record-only still MUST NOT hide feedback the user's current submission requires.
7.2 Deferred while editing, learned of through a silent digest
Applies to a product with an explicit subscription, a recoverable original task, and local aggregation and scheduling capability. The example channel plan allows only a single notification target and at most one automatic reminder, and does not redirect when the receipt is unknown. passive still requires checking real platform permission; a silent presentation does not equal unconditional approval.
{
"visualTokens": {
"attention": {
"visual": {
"title": {
"$type": "typography",
"$value": "{product.typography.bodyStrong}"
},
"foreground": {
"$type": "color",
"$value": "{product.color.textPrimary}"
},
"surface": {
"$type": "color",
"$value": "{product.color.surfaceRaised}"
}
}
}
},
"interaction": {
"previewItems": 3,
"digestWindowMs": 300000,
"snoozeOptionsMs": [900000, 3600000],
"reviewWindowDays": 14
},
"policy": {
"categoryContract": "example.export-complete",
"interruption": {
"mode": "defer",
"level": "passive",
"platformMapRef": "example.platform-notification-levels",
"scheduleRef": "example.allowed-digest-time"
},
"preferenceDefaultScope": "category",
"permissionPrompt": {
"trigger": "contextual",
"rationaleRef": "example.subscribe-export-results",
"deniedFallbackRef": "example.in-app-results"
},
"quietScheduleRef": "example.user-quiet-hours",
"grouping": {
"groupKey": ["accountId", "taskId", "visibilityScopeId"],
"clock": "fixed",
"releaseConditionRef": "example.digest-release",
"summaryFallback": "deterministicList"
},
"expiryContract": "example.export-validity",
"snooze": {
"customTimeEnabled": false,
"scheduleContractRef": "example.snooze-schedule"
},
"presentation": {
"surface": "platform",
"announcement": "polite",
"historyRef": "example.notification-history",
"contentContractRef": "example.redacted-export-content"
},
"resumeContract": "example.draft-return",
"channelPlan": "example.single-target-notification-plan",
"escalation": { "maxRounds": 1, "dismissal": "stop" },
"burdenReview": {
"metricsRef": "example.notification-outcomes",
"reportTimeZone": "Asia/Shanghai",
"owner": "example.product-team",
"retentionRef": "example.minimal-metrics-retention"
}
}
}
announcement is a semantic requirement, not an API switch guaranteeing that the system's screen reader will announce it in the specified way; the actual template behavior on system surfaces MUST be verified. When the target semantics are not satisfied, add an in-app accessible state and history instead, without falsely claiming the capability.
7.3 A decision example for bounded active reminding
For "a user-subscribed appointment needs confirmation," the following independent decisions are made, without directly turning an ordinary completion category into an urgent one:
| Decision | Example value | Evidence required before use |
|---|---|---|
| Delivery and presentation | mode=notify, level=active | Allowed category, a genuine subscription, platform mapping, last-useful point |
| Automatic rounds | maxRounds=1, dismissal=stop | The first-use ledger is consistent across endpoints; no new send after turn-off |
| Burst control | accountAllCategories, windowMs=600000, maxInterruptions=2, overflow=record | A prototype assumption; the account's active categories share a reservation mechanism, with an important-pending-item entry |
| User deferral | a custom time point adopted | The conflict with the deadline is stated first; the arrangement is durable, cancelable, and does not reset the automatic quota |
| Exception bypass | not enabled | active does not promise to break through do-not-disturb; when exception is genuinely needed, eligibility and user permission are re-verified |
"Twice in ten minutes" only illustrates how the window and quota are expressed; it is not a default recommended for every product. A user arrangement, a dedicated notice, and a silenced item must each be handled per their own declared bounded plan.
8. Validation and fixed baselines
| Validation layer | Checks that MUST be completed |
|---|---|
| Fields and references | Correct types, all necessary references resolvable, no cycles; JSON examples parsable; prototype values explicitly labeled |
| Coordination | Every illegal combination in §5.3 has an explicit rejection result; a missing capability does not quietly expand permission or escalate interruption |
| Time | Start point, release upper bound, time zone, deadline margin, and calendar-day window each correct; 0, negative, and fractional durations rejected |
| Scope and ledger | Turn-off scope accurate, single-round target coordinated, cumulative quota covers concurrency, restart/refresh does not zero it out |
| Content and action | Lock screen, casting, screen reader, long text, current account, and quick-action permission each verified |
| User understanding | Can know why it was received, when the next reminder comes, whether the setting took effect, and how to review and return to the original task |
| Real effect | Record the target device and operating environment; separately verify the request, actual presentation, and user benefit — a dictionary check is not treated as product acceptance |
The following baselines have no closable token: no response does not equal permission; opening, reading, or dismissing does not equal business completion; a notification entry does not reduce action authorization; unknown delivery does not equal non-delivery; a product's urgency label grants no platform eligibility; a visual theme grants no permission; an expired matter is not forcibly re-rung; no numeric configuration can substitute for real deduplication, scheduling, and recovery capability.
Configuration delivery and validation
A preview-item count limits only the initially visible items; it does not delete the complete record, unresolved exceptions, or each item's own deadline. Silent record, active delivery, and dedicated alerting are resolved separately; bypassing user choice by switching category is forbidden, and mechanically forcing another domain's protective obligation onto ordinary notifications is forbidden. The examples provide no universal daily ceiling.
The accompanying executable sample covers only attention.interaction.previewItems; the other fields are validated item by item per this dictionary; not being covered means neither not-applicable nor passed. The samples are format positives and negatives for the selected fields, not product presets that directly enable every capability. A complete product delivery additionally includes applicability, dependencies, evidence, execution mappings, and effect boundaries for in-progress operations.
When field names, types, or meanings change, update the referencing parties and acceptance samples; edits that only clarify wording without changing legal behavior keep the existing field names. Callers read the resolved effective configuration and do not back-infer authority, measurements, or completion facts from UI controls, animations, or model text. See the corresponding scenarios.
References
Serves Design Guidelines and Design Token and configuration dictionary. Source verification date: 2026-09-16.
How to use these sources
The sources below are verified against the actually obtained relevant body text; a search abstract is never substituted for reading, and completion of a full-site audit is never claimed. Standard body text, explanatory documents, platform implementation references, and historical research each have their own applicable boundary. A rule's binding force comes from this project's necessity-driven derivation of user commitments, not from the number of citations.
This topic's rule numbering, event contract, reminder rounds, total-burden budget, and initial parameter values are all this project's design; they are not a unified system proposed by the sources. Adopting a platform capability still requires verification in the actual target environment; external material does not prove this project's configuration has already been implemented or that user benefit has already been established.
NR01 — Android notification channels
- Source: Create and manage notification channels, official platform documentation.
- Scope read: creating channels, importance, user modification, reading the actual settings, and the settings entry.
- Support: channels let users control notifications by category; an application cannot arbitrarily rewrite the importance and reminder behavior of an established channel, and the user can still modify the actual settings.
- Landing points: N1-1, N2-2; category definition, permission state, and platform mapping.
- Boundaries: does not support the claim that all platforms adopt the same levels; a channel's existence does not prove the user subscribed to a business category, nor that the notification has value.
NR02 — Apple notification interruption levels and Focus
- Source: Send communication and Time Sensitive notifications, Apple official technical talk.
- Scope read: the summary of the official transcript, Focus, Passive/Active/Time Sensitive/Critical, and their allowed conditions.
- Support: silent presentation, ordinary reminder, and bypass have different conditions; time-sensitive requires a reason needing immediate attention, Critical has platform eligibility limits, and the user can turn off the related reminders.
- Landing points: N1-1, N1-2; separating delivery time from presentation level, and requiring that exceptions not be enabled by a product label alone.
- Boundaries: this is a historical mechanism explanation and does not guarantee the behavior of all current devices; this dictionary's enums are not a direct copy of the platform's enums and require an independently established mapping.
NR03 — Field research on task interruption and recovery
- Source: Iqbal, Horvitz, Disruption and Recovery of Computing Tasks: Field Study, Analysis, and Directions, CHI 2007, paper hosted by the authors' institution.
- Scope read: the paper's abstract, task-recovery observations, and the relevant Design Implications section; statistics not recomputed.
- Support: recovery after an interruption is an independent cost; the original task's visible cues, windows, and working position are worth protecting in design.
- Landing points: N2-1, N4-2, N5-2; returning to the original task and evaluating recovery cost.
- Boundaries: historical desktop research does not prove the optimal reminder timing for mobile or all populations, and cannot be used to derive a uniform aggregation duration, recovery seconds, or a daily ceiling.
NR04 — WCAG standard body text
- Source: Web Content Accessibility Guidelines, W3C Recommendation.
- Scope read: the relevant success criteria and levels for interruption control, time limits, continuity after re-authentication, focus visibility and not being obscured, and status messages.
- Support: 4.1.3 Status Messages is AA; 2.2.4 Interruptions is AAA; 2.2.1 Timing Adjustable is A. The applicability conditions and levels of these requirements must not be mixed together.
- Landing points: N2-1, N4-1; focus, status semantics, review, and time limits.
- Boundaries: this topic is not a complete WCAG conformance checklist; an AAA-only item is not described as an AA requirement for all products, and native notifications are not directly certified by it. The project may propose a stricter experience baseline, but it must be labeled as this project's own derivation.
NR05 — Android notification presentation, updating, and removal
- Source: Create a notification, official platform documentation.
- Scope read: quick reply and urgent presentation, lock-screen visibility, alternative content, updating a notification with the same ID, first-time-only alerting, and the removal mechanism.
- Support: the platform provides content-protection and lifecycle tools; the same ID can update a notification, but updating an already-dismissed notification again may create a new notification. Content refresh and user dismissal therefore need product-level coordination.
- Landing points: N3-1, N3-2, N4-3, N5-1; content contract, stop condition, and channel plan.
- Boundaries: platform removal does not prove business completion; its lock-screen capability does not automatically resolve casting, external audio, or judging every audience. The authorization and deduplication of quick actions are this project's necessity-driven derivation.
NR06 — Design Tokens format
- Source: Design Tokens Format Module, Design Tokens Community Group document.
- Scope read: document status, types, and value-and-alias expression.
- Support: typed values and references can express interchangeable design tokens; the document explicitly states it is not a W3C standard or W3C Recommendation.
- Landing points: the dictionary's visual-token subtree, type compatibility, and reference resolution.
- Boundaries: does not define authorization, user choice, urgency, queuing policy, or delivery facts for the product; the overall project configuration does not conform to DTCG merely by using
$value. Full format-conformance testing was not performed.
NR07 — Notification permission request timing
- Source: Notification runtime permission, Android official documentation.
- Scope read: allow/deny/dismiss the request, actual permission state, and contextual-request best practice.
- Support: permission choices have different outcomes; notification permission can be requested when the user has already understood the specific value of the feature, and not making a choice does not automatically change to allowed.
- Landing points: N2-3;
permissionPrompt, the platform permission fact, and the denial fallback. - Boundaries: a launch-count example from one platform is not treated as a cross-platform default threshold, no additional layer of permission-rationale dialog is required for every product, and a platform exemption is not expanded into a universal product license.
NR08 — Accessible semantics of status messages
- Source: Understanding SC 4.1.3: Status Messages, WAI explanatory document.
- Scope read: the criterion, its intent, the scope of status messages, and the distinction from a context change.
- Support: dynamic information meeting the definition of a status message should be presentable by assistive technology without moving focus; not all new content needs to be automatically announced.
- Landing points: N4-1; the semantic choice of
announcementand merging ordinary updates. - Boundaries: explanatory material that adds no new standard obligation, and does not guarantee consistent behavior across every platform and screen-reader combination.
NR09 — Focus and frequency of Alert
- Source: Alert Pattern, WAI-ARIA Authoring Practices Guide.
- Scope read: About This Pattern, focus, auto-dismissal, and interruption-frequency notes.
- Support: an alert should not take keyboard focus; brief disappearance and frequent interruption can make notifications hard to use. Situations that must block the workflow differ from an ordinary alert.
- Landing points: N2-1, N4-1; non-intrusive feedback, a persistent entry, and moderating announcements.
- Boundaries: a pattern reference, not equivalent to a notification system having passed an accessibility check, and it provides no uniform display duration.
NR10 — Timing adjustable and exceptions
- Source: Understanding SC 2.2.1: Timing Adjustable, WAI explanatory document.
- Scope read: the criterion, the turn-off/adjust/extend paths, the real-time and essential exceptions, and the applicable intent.
- Support: a time limit a content itself sets needs an applicable time-control path, or must meet one of the exceptions the criterion lists; reading and operating need sufficient time.
- Landing points: N4-1; distinguishing prompt dwell time, an operating opportunity, and a business deadline.
- Boundaries: reading that a notification exists somewhere does not mean a time-limited operation is already accessible; "platform limitation" or "important business" cannot broadly exempt all time limits. This topic does not replicate the complete conformance criteria; check the applicable original text at implementation time.
Project derivations and matters pending validation
| Project design | Type of basis | Product evidence still required |
|---|---|---|
| The last-useful reminder point and the handling margin | Derived from the promise that "the notification can still help action" | Actual task duration, accessibility needs, pipeline latency, and the impact of a missed delivery |
| Rounds, cross-device deduplication, and unknown-receipt handling | Derived from the promise of "bounded reminding without duplicate side effects" | Multi-endpoint concurrency, duplicate requests, lost receipts, and post-submission-crash testing |
| User deferral, cancellation, and time-zone handling | Derived from the promise that "a later arrangement can be delivered" | Scheduling acceptance, cross-time-zone, daylight saving, restart, and cancellation-race testing |
| Cross-category burst budget and backlog release | Derived from the promise that "total disturbance is controllable" | Concurrent multiple producers, the discovery rate of important matters, and actual burden feedback |
| Three preview items, a five-minute digest, deferral candidates, and a fourteen-calendar-day review | Prototype example values | Specific task cycles, screen capacity, freshness, and sample coverage; no external source proves these values are optimal |
| Configuration coverage, dependency, and a conservative fallback | A project contract made to keep design decisions explainable | Consumer-side resolution, missing configuration, and illegal-combination testing |
No device-delivery experiment, user study, complete accessibility audit, or production-statistics recomputation has been performed. Source verification, documentation-consistency checks, mechanism testing, and user-effect verification are different kinds of evidence and do not substitute for one another.