Push-notification boundaries
Push-notification behavior is source-only for this documentation wave. Treat every notification state as a separate contract; one state never proves the next.
Responsibility and state model
| State | Responsible owner | What it can establish | What it does not establish |
|---|---|---|---|
| Purpose and consent | Privacy and product owners | Whether a particular data use has an approved purpose | Device permission, channel preference, or delivery |
| Marketing preference | Customer and Ordering preference owners | Whether optional marketing is currently allowed for that channel | Permission for operational messages or provider registration |
| Operating-system permission | Operating system | Whether the device allows notification presentation | Marketing consent, current account ownership, or resource authorization |
| Provider installation | Customer App and notification-service owners | Whether the provider returned an installation state for this app | That Ordering bound it to the current project, account, or session |
| Ordering binding | Ordering identity and notification owners | Which current app, project, account, session, and purpose may use the installation | That a message is authorized, minimal, or delivered |
| Audience and content | Ordering product, privacy, and resource owners | Who may receive one category and what minimal content may leave Ordering | Provider delivery, OS display, or in-app authorization |
| Delivery | External notification service and operating system | A bounded transport or presentation result | That the customer saw, opened, understood, or acted on it |
| Open intent | Customer App routing and Ordering authorization owners | A request to open a typed in-app destination | Resource ownership, freshness, or successful application action |
A notification is not a single Boolean. Permission, preference, installation, binding, audience, content, delivery, and open intent must be inspected independently.
Marketing and operational categories
Optional marketing and necessary operational messages require separate purpose and preference rules. Enabling one category must not silently enable the other. A preference must be checked when a message is sent, not only when it is first scheduled.
Operational content should remain generic outside the authenticated app. The Customer App must fetch sensitive order, message, wallet, account, or payment details only after it revalidates the current session and resource.
Required lifecycle
A future accepted implementation must:
- Resolve the approved app variant, project, account, session, purpose, and notification category.
- Keep optional provider work inactive until the required purpose and consent gate has passed.
- Keep marketing preference and operating-system permission separate.
- Bind one current provider installation to the exact Ordering lifecycle.
- Resolve audience and minimal content again immediately before sending.
- Attach only a short-lived, typed open intent that grants no resource access.
- Re-authorize the destination inside the app before navigation or data fetch.
- Rotate or remove installation, identity, callbacks, queued work, and local state after logout, withdrawal, account change, project change, or reinstall.
The current pinned paths do not establish this complete lifecycle. Source presence does not prove configuration, permission, delivery, opening, or teardown.
Delivery, opening, and unknown outcomes
A provider acceptance or delivery result is not evidence that the customer saw or opened a notification. An open event is not evidence that its destination is authorized or that an order, message, payment, or other action completed.
Duplicate, delayed, out-of-order, expired, or replayed intents must fail closed. The app must not reuse an intent after the account, project, session, category, or referenced resource changes.
Verify without registering a device
A safe documentation plan substitutes the operating system, provider, installation store, Ordering API, queue, and routing boundary. It should prove:
- zero provider, permission, registration, send, display, open, navigation, or resource effects;
- optional categories remain off without a current explicit preference;
- operational and marketing categories never authorize each other;
- a late installation, delivery, or open callback cannot cross account or project changes;
- sensitive content and resource details never leave the authenticated app;
- invalid, expired, duplicate, foreign, or malformed intents are rejected without revealing whether a resource exists; and
- cleanup removes every reserved listener, timer, queue, installation binding, cached identity, and test value.
Provider delivery needs a separately authorized isolated integration test. It is not part of documentation verification.
Troubleshoot by observable state
Start with the owner of the state that is visible. Do not infer a later state from an earlier one.
| Observable state | First responsible owner | Safe disposition |
|---|---|---|
| A notification entry point is absent | Release, product, and public-configuration owners | Keep it unavailable; do not infer a provider outage or permission denial. |
| Marketing preference is off | Customer preference and marketing-purpose owners | Do not schedule or send marketing; evaluate operational categories separately. |
| Operating-system permission is denied or blocked | Operating-system and native-platform owners | Show a local unavailable state; do not repeatedly prompt or treat it as a marketing choice. |
| Provider installation is absent or stale | Customer App installation and provider-identity owners | Do not bind, send, or navigate; establish one current lifecycle or remain unavailable. |
| Ordering cannot bind the installation | Ordering identity and notification owners | Keep the installation unauthorized; provider state alone is insufficient. |
| A queued message remains after withdrawal | Consent, notification-policy, and queue owners | Cancel it before send; do not rely on the preference that existed when it was scheduled. |
| The provider accepted a message but no visible result exists | Provider transport and operating-system owners | Keep delivery, display, view, and open unverified. |
| An open intent is invalid, expired, or already used | Routing and Ordering-authorization owners | Reject it locally without mounting a destination or revealing resource existence. |
| Logout, account change, or project change occurs | Session, installation, and integration-lifecycle owners | Remove or rotate the prior binding, callbacks, queue, identity, and cached state. |
Recertification triggers
Repeat this review after changes to:
- App, shared-components, Ordering-service, or deployed release authority;
- consent purposes, marketing preferences, operational categories, or withdrawal behavior;
- OS permission APIs, native manifests, notification SDKs, or build variants;
- provider installation identity, token storage, Ordering binding, rotation, or deletion;
- audience resolution, content minimization, lock-screen presentation, or sensitive resource categories;
- queueing, send-time preference checks, retries, expiry, deduplication, or delivery receipts;
- open-intent parsing, freshness, one-time use, in-app authorization, or destination navigation; or
- logout, account/project switching, reinstall, offline recovery, logging, redaction, retention, or deletion.
Public documentation boundary
Do not register a live device, send a notification, expose notification data, or publish setup values, identifiers, credentials, tokens, endpoints, payload shapes, callback formats, or live delivery procedures.
For related boundaries, see Native integration boundaries, Consent and privacy choices, Account settings, App-link boundaries, and Use the app offline and reconnect.