Keryx go-to-market roadmap

Last audited: 29 August 2026

This document is the source of truth for taking Keryx from a working SafeCall companion application to a publicly distributed, supportable first-party notification client for SafeCall administrators on iPhone/iPad and Android. Execution status belongs in GitLab; this roadmap owns the rationale, dependencies, launch gates, and accepted risks.

The roadmap is planning only. It does not claim that a store record, production signing setup, privacy page, push service, or listed remediation already exists.

Scope

Public Apple App Store distribution for iPhone and iPad.
Public Google Play distribution for Android phones and tablets.
Initial public availability in the Czech Republic only, with complete English and Czech app, administrator, listing, asset, and support parity.
Keryx as an included, administrator-only companion to a separately contracted SafeCall deployment, not an independently marketed product.
A SafeCall administrator/operator selects friendly alert categories, scans a SafeCall-generated QR code on their own device, and receives notifications without manually configuring a server, subscription, or topic.
Keryx as the SafeCall-branded replacement for asking administrators to install and configure the generic ntfy app. ntfy remains an implementation detail in normal SafeCall and Keryx flows.
The SafeCall administrator QR flow, customer notification infrastructure, support process, and public web surfaces required for a client to install and operate the app.
Public store listings as a SafeCall client installation channel, not a standalone demand-generation or self-service acquisition channel.
First release, routine updates, urgent fixes, deprecation, and end of life.

Out of scope:

Shipping Keryx for macOS, Windows, Linux, or web. Those Flutter scaffold directories do not make them supported products.
Implementing the gaps listed here.
Submitting a binary or changing a production ntfy, Apple, or Google account.
Creating a standalone Keryx market, SKU, lead-generation campaign, or consumer acquisition motion.
Requiring ordinary administrators to understand or manually enter ntfy server URLs, topic names, subscriptions, or other transport configuration.
Treating Keryx as a certified emergency service or regulated medical device without an explicit legal and regulatory decision.

Document	Role
Keryx adoption strategy	Installed-base adoption, SafeCall-led positioning, enablement, and measures
Keryx QR and ntfy threat model	P1-01 abuse cases, ratings, and treatment handoffs for QR and topic access
Authenticated provisioning protocol	P1-02 HTTPS-only, per-QR subscribe tokens, publish token, and v2 QR
Android delivery architecture	P1-03 FCM `poll_request` + authenticated poll; perpetual `dataSync` FGS deprecated
iOS APNs delivery architecture	P1-04 client-ntfy token registration; upstream APNs `poll_request` for iOS bundle `com.sourcectl.keryxapp`
Data classification and local storage	P1-05 inventory, SharedPreferences + full lock-screen launch policy, retention/offboarding
Legal drafts (privacy, terms, support)	P1-06 DRAFT policies and planned `{public_base}/keryx/*` URL paths; not yet live
Apple privacy compliance	P1-07 manifests, purpose strings, nutrition-label draft, HTTPS-only export answer
Play Data Safety	P1-08 Data Safety draft, permissions, FGS posture, app-content checklist, reviewer-access plan
Dependency ownership	P1-09 direct-dep inventory, vendored ntfy ownership, privacy-manifest checklist, advisory cadence
Safety claims	P1-10 supplemental posture, delivery limits, no Critical Alerts at launch, prohibited claims
Visual identity	P2-01 mark, wordmark rules, palette, asset inventory, store kit gaps
Store listing copy	P2-02 bilingual Apple/Google fields, reviewer notes, release-note templates
Store screenshot kit	P2-03 device matrix, shot list, sample data, capture/redaction checklist, captions
Public web pages	P2-04 URL map, landing copy, deployment/monitoring/a11y checklists
Keryx application	Current behavior, QR contract, and delivery model
Operator actions	Human/portal/secret-store checklist; bulk verification; GitLab close bars
Publishing Keryx	Repeatable release, update, and emergency-release runbook
Mobile overview	SafeCall mobile product index
GitLab issue workflow	SafeCall issue API and commit conventions
Manual testing	Existing SafeCall UI test checklist
Bug collector	Existing field issue intake

GitLab tracking

Resource	Link
Parent work item	#81 — Keryx public App Store and Google Play launch
Milestone	Keryx public launch
P0 — Product and governance	#82
P1 — Trust, security, privacy, and delivery	#83
P2 — Brand, client enablement, and store content	#84
P3 — Build, signing, and release engineering	#85
P4 — Product and client readiness	#86
P5 — Store submission and launch	#87
P6 — Updates and post-launch operations	#88

All actionable work items use gtm, product::keryx, one phase::pN, one type::*, and exactly one open workflow::* label. The priority::launch-blocker label means that the public launch cannot pass its go/no-go review until the item is closed or its risk is explicitly accepted in this document.

Status vocabulary

Ready — implemented and supported by current evidence.
Partial — a useful implementation or document exists, but an exit criterion is not met.
Missing — no production-ready artifact or process was found.
Decision required — implementation should not start until the product owner records a choice.
Externally owned — completion depends on an account, counsel, store, client, or service outside this repository.
Accepted risk — the product owner has recorded the risk, rationale, owner, and review date.
Deferred — intentionally excluded from this launch with a linked work item or written rationale.

Executive audit verdict

Keryx has a credible product core: QR provisioning, local notification history, Active/Archive UX, Android boot recovery, iOS push hooks, and an admin QR flow covered by web E2E tests. It also has a source icon and an initial publishing checklist.

The product model is fixed: Keryx is SafeCall's administrator-only, branded replacement for the generic ntfy client. SafeCall must present friendly alert categories and generate all transport configuration in the QR; the administrator scans it on their own device and should not need to know that ntfy topics or subscriptions exist. The current implementation only partially matches that target: the provisioning card is named Ntfy Notifications, setup is described in terms of topics, and some documentation models a separate administrator-to-end-user handoff.

It is not ready for public stores. The most important unresolved points are:

Android release builds still use the debug signing configuration.
Android no longer uses a perpetual dataSync FGS. Killed-state delivery is FCM wake + authenticated poll. Deployer Firebase / notify-host firebase-key-file (#119), Play form paste, and physical-device evidence (#117) remain open.
iOS hands the APNs token to Firebase Messaging and subscribes to FCM topics (not /v1/account/device). Production entitlement (#110) is proven on store IPAs. Deployer Firebase + APNs .p8 (#119) and physical-device evidence (#117) remain open. Do not use upstream-base-url: https://ntfy.sh for Keryx.
Provisioning currently accepts HTTP and carries no ntfy credential. Topic names derived from a server ID are not an authorization boundary.
Alert bodies, topic names, device names, and MAC addresses can be stored locally and shown on the lock screen. P1-05 classifies those flows and approves SharedPreferences plus full lock-screen preview for launch with mandatory disclosure; privacy pages and store forms (#99–#101) must match. Existing “no personal data” wording still cannot be reused without that disclosure work.
Public privacy, support, terms, listing metadata, review access, screenshots, and SafeCall client install pages are missing or placeholders. P1-06 provides DRAFT English source and planned URL paths in docs/gtm/keryx/legal/; live HTTPS publication and bilingual pages remain #107/#108.
There is no Keryx release pipeline, release evidence record, CI gate, integration suite, client pilot gate, or supported update/hotfix process.
P0-01 approves sourcectl as publisher and Keryx for SafeCall as the public name under the Wantok/SafeCall hierarchy, but the current lowercase launcher labels, SafeCall Flutter title, website, legal, account, and store surfaces have not yet been propagated or verified.
Administrator-facing provisioning terminology and guidance still expose ntfy/topics and a generic end-user model instead of the intended friendly category, scan-on-own-device workflow.

Current baseline

Area	State	Evidence and consequence
Product role	Ready	Keryx is fixed as SafeCall's administrator-only, first-party replacement for the generic ntfy client; it is not a standalone offer or acquisition channel
Product identity	Partial	P0-01 approves `sourcectl` as publisher, `Keryx for SafeCall` as the store/in-app name, `Keryx` as the launcher label, Android `com.sourcectl.keryx` / iOS `com.sourcectl.keryxapp` (29 August 2026 amendment), and the wider hierarchy; current platform, website, legal, account, and store surfaces still require propagation and verification
Platform support	Partial	P0-04 approves iOS/iPadOS 17+, Android 12/API 31+, phone/tablet orientations, Android OEM tiers, camera requirement, non-target platforms, and exception/stop policy; source still permits iOS 13/Android API 24 and no physical support matrix has passed
Version	Partial	`keryx/pubspec.yaml` is `1.0.0+3`; P3-05 (#113) — versioning.md + `keryx/CHANGELOG.md`; no store tag history yet
Core UX	Partial	QR onboarding, Active/Archive, detail, pause/resume, rescan, reset, and badges are implemented, but unconfigured guidance assumes a separate end user and must be aligned to the administrator-only persona
Administrator provisioning	Partial	SafeCall generates a versioned QR and has E2E coverage, but the `Ntfy Notifications` card and topic-oriented setup expose implementation concepts; friendly categories, security, lifecycle, guidance, and Czech strings are incomplete
Android delivery	Partial	P1-03 FCM wake + authenticated poll is in code; no perpetual FGS (android-delivery-architecture.md). #119 Firebase/`firebase-key-file`, Play form paste, and #117 evidence remain open
iOS delivery	Partial	P1-04 Firebase-for-Keryx topic subscribe is in code (ios-delivery-architecture.md, ntfy-fcm-apns.md). #110 entitlement is proven. #119 Firebase/APNs host config and #117 evidence remain open
Android signing	Done	P3-01 (#109) — android-signing.md; Play App Signing enrolled 30 August 2026; MiniVan recovery matched
iOS distribution	Done	P3-02 (#110) — ios-signing.md; App ID `com.sourcectl.keryxapp`; GLaDOS and MiniVan-3 signed IPAs verified; ASC app Keryx for SafeCall CZ-only; `.p12` backup on NAS (1 September 2026)
Privacy manifests	Partial	P1-07 packet (apple-privacy-compliance.md) approves UserDefaults reason CA92.1, purpose strings, nutrition/encryption answers, and privacy-link plan; P1-09 (dependency-ownership.md) inventories SDK/manifest coverage; source manifests, signed Xcode report, and ASC submission remain open (#110/#125)
Automated tests	Partial	Three Dart test files and web provisioning E2E exist; no native, integration, upgrade, or delivery-soak automation exists
Release automation	Missing	Root scripts analyze/test Keryx and build only an AAB; the existing mobile release pipeline belongs to SafeCall Nav
Store metadata	Missing	P0-02 approves Czech-only availability and classification; P0-03 approves the free-companion, QR-configuration, payment-free, reviewer, and installation-only MDM facts, but final bilingual copy, screenshots, forms, URLs, and reviewer access are absent
Legal and support	Partial	P0-02/P0-05 ownership and support class are set; P1-06 DRAFT privacy/terms/support texts and planned URL paths exist in legal/; live HTTPS pages, counsel review, public contacts verification, and app/store wiring remain open (#107/#100/#101/#125)
Localization	Missing	P0-02 requires complete English/Czech launch parity and makes Czech blocking; Keryx UI is hard-coded English, most SafeCall provisioning copy is hard-coded English, and Keryx-specific Czech catalog entries are incomplete
Accessibility	Missing	P0-04 approves a launch-blocking WCAG 2.2 AA, VoiceOver/TalkBack, 200% text, contrast, focus, target-size, reduced-motion, orientation, and permission-recovery baseline, but no implementation audit, automated coverage, or physical-device acceptance evidence exists
Client enablement	Missing	P0-03 approves reviewer/listing/sales/support facts, but final SafeCall client installation/support material, administrator migration guidance from the generic ntfy app, MDM prerequisites, and required store links are absent; an independent Keryx marketing campaign is intentionally out of scope
Update lifecycle	Partial	P3-05 (#113) approves version/tag/changelog/QR/downgrade policy (versioning.md); full EOL matrix (#130), release train, and renewal calendar remain open

Current store-policy baseline

Store rules change. Every submission issue must re-check the official source on the day it starts.

Apple requires iPhone/iPad submissions from 28 April 2026 to use Xcode 26 and the iOS/iPadOS 26 SDK or later: Apple submission requirements.
Apple requires complete privacy details, a working privacy policy link in metadata and in the app, and responsibility for third-party SDK behavior: App Review Guidelines.
Apple review must receive full access. For Keryx, that means a durable sample QR, reachable test ntfy service, test messages, and review notes.
Apple privacy-impacting SDK and required-reason API requirements include Flutter and several Flutter plugins used by Keryx: third-party SDK requirements.
From 31 August 2026, new Google Play apps and updates must target Android 16 / API level 36: target API requirements.
Native Android dependencies in the release AAB must support 16 KB page-size devices: 16 KB page-size guidance.
Google requires a Data Safety form for testing and production tracks and holds the developer responsible for third-party code: Data Safety.
Android 14+ foreground services require an accurate service type and Play declaration. A perpetual network listener does not automatically qualify as dataSync: foreground-service requirements.
Android 15+ applies an aggregate six-hour timeout to dataSync foreground services in a 24-hour period and imposes background/boot-start restrictions: foreground-service timeouts.
Google review access that uses a QR code must include durable instructions and a static URL for the QR: review access requirements.

Decision gates

Fixed decisions below are constraints, not fields to reopen during implementation. Closing the matching P0 work item must replace each remaining TBD with a dated decision and named owner.

Decision	Current value	Why it blocks work
Product role and app audience	Fixed: administrator-only SafeCall companion; not independently marketed	All UX, listing, support, and adoption work must preserve this boundary
Provisioning experience	Fixed: friendly SafeCall alert categories plus scan-on-own-device QR; ntfy/topic configuration hidden	Admin UI, QR tests, screenshots, and guides must not require transport knowledge
Legal publisher and store-account owner	Approved 13 August 2026: `sourcectl` is the legal publisher, seller/copyright identity, and intended owner of both store accounts; P3 verifies the actual account records, roles, and registered details	Controls contracts, store identity, privacy controller, support, and signing custody
Public product name and casing	Approved 13 August 2026: `Keryx for SafeCall` in stores and in-app, `Keryx` for iOS/Android launcher labels, `Copyright © 2026 sourcectl`. Identifiers amended 29 August 2026: Android/Play `com.sourcectl.keryx`; iOS/App Store `com.sourcectl.keryxapp` (Apple would not release the original iOS App ID, case 102915938031)	Controls bundle metadata, screenshots, web copy, review notes, and support language
Relationship to SafeCall / AlertHub / BleuVista	Approved 13 August 2026: sourcectl publishes; Wantok is the product umbrella; SafeCall is the contracted platform; Keryx for SafeCall is its administrator companion; BleuVista is a separate market-facing portfolio/channel; AlertHub is its SafeCall-powered emergency-alerting solution and does not own Keryx; NavBeacon remains separate	Final brand architecture must explain the wider portfolio without presenting Keryx as standalone
Commercial model	Approved 13 August 2026: free companion for administrators of a separately contracted SafeCall physical/building deployment; no Keryx account, checkout, subscription, paid SKU, in-app purchase, external purchase link, or purchase call to action; QR configures connectivity and selected alert categories rather than purchasing/licensing/unlocking paid digital content	Reviewer, listing, sales, support, and onboarding copy must preserve the same facts
Public distribution and MDM	Approved 13 August 2026: the public App Store/Google Play binary may be assigned or installed through Apple Business Manager/standard MDM or managed Google Play; interactive permissions and SafeCall-generated QR provisioning remain required; no managed app configuration, injected credentials, deep-link provisioning, zero-touch setup, custom/private binary, or silent configuration is supported at launch	Prevents installation support from being mistaken for managed-device configuration or validated restrictive-profile compatibility
Initial countries/regions	Approved 13 August 2026: Czech Republic only on Apple App Store and Google Play	Controls legal review, availability, content rating, and localization
Initial app/store languages	Approved 13 August 2026: English primary/default plus complete Czech localization across app, SafeCall provisioning, listings, screenshots, release notes, permission/help copy, and install/support material; missing Czech parity blocks launch	Controls app localization and listing asset production
Apple category and medical-device answer	Approved 13 August 2026: Business, no Health & Fitness or Medical category, adult administrator audience, not in Kids, expected questionnaire result 4+, no health functionality, and not a regulated medical device	Final questionnaire answers and P1-10 safety claims must remain consistent with this classification
Android category and target audience	Approved 13 August 2026: Business, target age 18+ only, not designed for children or Families, expected IARC result Everyone, no health functionality, and not a medical device	Final Play forms, tested behavior, and public policies must remain consistent with this classification
Minimum iOS/iPadOS and Android versions	Approved 13 August 2026: iOS/iPadOS 17+ and Android 12/API 31+ on Google Play-certified devices; test iOS/iPadOS 17, 18, 26 and Android 12/12L through 16/API 31–36; target/compile API 36; verify 16 KB native-page support	Current source floors of iOS 13/API 24 must not be treated as support promises and must be aligned before release
Supported device/OEM matrix	Approved 13 August 2026: iPhone/iPad and Android phone/tablet with the approved orientations and functioning camera; Tier 1 Pixel/AOSP and Samsung; Tier 2 model-specific Xiaomi/Redmi/POCO, Motorola/Lenovo, OnePlus/Oppo/Realme after evidence; all others unsupported until qualified	Background reliability, managed-device policy, and battery exceptions require physical-device evidence
Accessibility and permission recovery	Approved 13 August 2026: launch-blocking WCAG 2.2 AA critical flows, VoiceOver/TalkBack, English/Czech 200% text, 4.5:1 normal and 3:1 large/UI contrast, 44 pt/48 dp targets, logical visible focus, reduced motion, supported orientations, and camera/notification Settings recovery without dead ends	P4-02 must prove the app meets this baseline before any conformance/support claim
Launch owner and go/no-go authority	Approved 25 August 2026: Thomas Minitsios is go/no-go authority and backup; he is Responsible and Accountable across product, app, SafeCall, ntfy/push, security/privacy, legal, stores, content, support, and incidents; single-person concentration is a named risk reviewed at P3-06/#114 and the first P5 go/no-go	A release must have one accountable decision maker
Target beta and production dates	Approved 25 August 2026: no invented calendar dates; no beta or production date until remaining P1–P4 `priority::launch-blocker` items are closed or explicitly accepted; the Keryx public launch milestone stays dateless	Prevents premature store dates while preserving a measurable target policy
Support mailbox, hours, and response target	Approved 25 August 2026: Keryx uses the existing SafeCall support channel; Czech business hours Mon–Fri CET/CEST; next-business-day first response; same-business-day acknowledgment of supported-tier core-path incidents by the go/no-go owner; no standalone Keryx mailbox, public status page, 24/7 desk, or emergency-dispatch SLA; actual contacts remain in controlled records	Required for store metadata and client expectations
Telemetry posture	Approved 25 August 2026: no analytics or crash SDK at launch; no administrator identifiers in this repository; field diagnosis is client-reported until P6-05/#132 approves minimum signals	Balances privacy claims with incident diagnosis without inventing collection

Phase status and dependency flow

Phase	Name	Status	Exit summary
P0	Product and governance decisions	Ready	Fixed companion positioning preserved; publisher, markets, support, ownership, dates, telemetry, and launch bar approved
P1	Trust, security, privacy, and delivery	In progress	Delivery architectures and disclosures are lawful, secure, testable, and supportable
P2	Brand, client enablement, and store content	Not started	Approved SafeCall relationship, install/support pages, listing copy, and localized asset packet complete
P3	Build, signing, and release engineering	Not started	Reproducible production-signed AAB/IPA and release evidence process proven
P4	Product and client readiness	Not started	Test matrix, client prerequisites, guides, pilot, and operational handoff pass
P5	Store submission and launch	Not started	Both stores approve; controlled rollout and launch sign-off complete
P6	Updates and post-launch operations	Not started	Routine and emergency lifecycle is owned, exercised, and measured

mermaid

flowchart LR
  P0[P0_Product_Governance]
  P1[P1_Trust_Delivery]
  P2[P2_Brand_Content]
  P3[P3_Build_Release]
  P4[P4_Client_Readiness]
  P5[P5_Store_Launch]
  P6[P6_Post_Launch]

  P0 --> P1
  P0 --> P2
  P0 --> P3
  P1 --> P4
  P2 --> P5
  P3 --> P4
  P4 --> P5
  P5 --> P6

P1 architecture research and P2 creative discovery may run in parallel after P0 decisions. Production store submission cannot begin until P1 through P4 have passed their exit gates.

P0 — Product and governance decisions

Goal: establish who is publishing what, for whom, where, under which promises, and who can authorize release.

ID	State	Work item	Exit criterion
P0-01	Ready	#89 — Confirm publisher, brand hierarchy, and product name	Dated decision names legal publisher, store-account owner, public app name/casing, and corporate hierarchy while preserving Keryx as a subordinate SafeCall companion
P0-02	Ready	#90 — Define launch markets, languages, and store categories	Countries, app/store locales, category, age rating, target audience, and medical-device answer are approved
P0-03	Ready	#91 — Define public distribution and commercial review narrative	Store-review explanation confirms an included administrator-only SafeCall companion, contracted deployment, QR-hidden transport configuration, no independent sale, and no in-app digital purchase
P0-04	Ready	#92 — Set supported OS, device, OEM, and accessibility baseline	Minimum OS versions, phone/tablet support, Android OEM tiers, assistive technologies, and exception policy are written
P0-05	Ready	#93 — Assign launch owners, target, support model, and go/no-go authority	RACI, support mailbox/hours/response target, beta and production targets, escalation contacts, and one go/no-go owner are recorded

P0-01 identity decision — 13 August 2026

Status: approved.
Owner and approver: Thomas Minitsios.
Publisher and accounts: sourcectl is the legal publisher, seller/copyright identity, and intended owner of both the Apple and Google store accounts. Use Copyright © 2026 sourcectl where a full copyright line is required. P3 must still verify the real account records, registered details, roles, custody, and recovery; the bundle namespace is not evidence that those external controls already exist.
Names and metadata: use Keryx for SafeCall in store listings and in-app product naming, and Keryx for iOS and Android launcher labels.
Platform identifiers (amended 29 August 2026): Android / Google Play / Firebase remain com.sourcectl.keryx. iOS / App Store Connect is com.sourcectl.keryxapp because Apple Developer Support (case 102915938031) will not release com.sourcectl.keryx for team 8P59575P2K. The macOS Flutter scaffold keeps com.sourcectl.keryx and is not a launched product. Name, publisher, and hierarchy are otherwise unchanged.
Hierarchy: sourcectl publishes; Wantok is the product umbrella; SafeCall is the separately contracted platform; Keryx for SafeCall is SafeCall's administrator-only mobile notification companion. BleuVista is a separate market-facing portfolio/channel. AlertHub is BleuVista's emergency-alerting solution powered by SafeCall capabilities and does not own Keryx. NavBeacon remains a separate navigation product.
Rationale: this preserves the fixed SafeCall companion model, resolves the current sourcectl/Wantok/BleuVista signals without renaming the Android identifier, gives stores and client material one public name, and keeps Keryx out of standalone product or acquisition positioning. The iOS bundle ID split is an Apple-forced exception, not a brand rename.

The decision is authoritative; implementation remains with the affected workstreams:

Surface	Current evidence	Handoff
SafeCall brand configuration and footer	`config/brands/safecall.ts` and the SafeCall footer identify Wantok; there is no Keryx brand profile	P2-01 #104 brief: visual-identity.md; #89 does not change build-time branding
Keryx Flutter, Android, and iOS metadata	Launcher/bundle names are lowercase `keryx`, Flutter titles say `SafeCall`; Android is `com.sourcectl.keryx` and iOS is `com.sourcectl.keryxapp`	P2-01 #104 / visual-identity.md rules; P2-02 #105, P2-05 #108, and P3-02 #110 propagate and verify affected metadata
BleuVista/AlertHub website	Public pages present AlertHub as a BleuVista solution and do not explain its SafeCall relationship	P2-04 #107 applies the approved relationship without creating a standalone Keryx funnel
Store copy, assets, and records	No approved listing packet or final store records exist	P2-01 #104 / visual-identity.md; P2-02 #105; P3-06 #114 verify external ownership
Privacy, terms, install, and support surfaces	Permanent Keryx URLs and final legal/support text are missing	P1-06 #99 and P2-04 #107 use the approved publisher and hierarchy

P0-02 launch classification decision — 13 August 2026

Status: approved.
Owner and regulatory/DSA reviewer: Thomas Minitsios. External counsel is mandatory if product scope, health functionality, medical claims, or the regulatory assumptions below change.
Availability: publish in the Czech Republic only on Apple App Store and Google Play.
Locales: use English as the primary/default store locale and provide a complete Czech localization. English and Czech are required across Keryx, SafeCall administrator provisioning, listings, screenshots, release notes, relevant permission/help copy, and install/support material. Missing Czech parity blocks launch rather than becoming an accepted mixed-language risk.
Audience: SafeCall administrators aged 18 or older. Keryx is not designed for children, does not enter Apple's Kids category or Google Play Families, and does not broaden the fixed administrator-only persona.
Apple classification: primary category Business, no secondary Health & Fitness or Medical category, and an expected 4+ questionnaire result. The content rating describes content suitability, not the adult target audience.
Google Play classification: app category Business, target age 18+ only, and an expected IARC result of Everyone.
Medical and health position: Keryx provides no health functionality and is not a regulated medical device. It does not diagnose, treat, cure, prevent, or clinically monitor a condition. P1-10 (safety-claims.md) locks supplemental-notification, delivery-limitation, and safety claims.
Rating rule: Apple and Google assign ratings from the final honest questionnaires. If the tested binary, payload model, copy, or questionnaire produces a higher rating, reopen this decision; do not tailor answers to force the expected value.
EU trader decision: sourcectl acts as an EU trader for Czech distribution. Apple requires a verified public business address, phone number, and email on the EU product page. The Google organization account requires verified legal identity/address details and public developer phone/email, plus app support contacts. Actual values remain in controlled account records rather than Git.
Rationale: Czech-only availability matches the current SafeCall/Wantok operating signal and limits initial legal, support, localization, and rollout scope. Business classification reflects a contracted administrator tool. Requiring bilingual parity avoids offering Czech administrators an English-only or topic-oriented setup while preserving conservative, non-medical store claims.

The decision sets launch requirements; it does not claim they are implemented:

Surface	Current evidence	Handoff
Keryx app and platform copy	Flutter UI and permission/help strings are hard-coded English with no localization infrastructure	P2-05 #108 implements and tests English/Czech parity
SafeCall administrator provisioning	Only a few English Keryx keys exist; most provisioning copy is hard-coded English/topic-oriented and reviewed Czech values are incomplete	P2-05 #108 owns canonical English/Czech catalogs and UI wiring
Listings, screenshots, release notes, and public pages	No approved bilingual packet, localized assets, or Keryx install/legal/support pages exist	P2-02 #105, P2-03 #106, and P2-04 #107 implement the approved scope
Privacy, medical, audience, rating, and safety forms	Final answers must be generated from the release candidate and approved claims	P1-06 through P1-08 #99, #100, #101, and P1-10 #103 provide evidence
EU trader, organization, and public contact records	`sourcectl` trader status and required contact classes are decided; verified values are not stored in this repository	P3-06 #114 verifies controlled account evidence and P5-03 #125 verifies final console disclosure

P0-03 commercial review decision — 13 August 2026

Status: approved.
Owner and approver: Thomas Minitsios.
Canonical fact pattern: Keryx for SafeCall is a free mobile companion for administrators of a separately contracted SafeCall physical/building deployment. Downloading Keryx does not buy or provide SafeCall.
QR meaning: the SafeCall-generated QR carries connectivity settings and the administrator's selected alert categories for that deployment. It does not purchase, subscribe to, license, or unlock paid digital content.
No app commerce: Keryx has no user account, checkout, subscription, paid Keryx SKU, in-app purchase, external purchase link, or in-app purchase call to action. Without compatible SafeCall configuration, it remains unconfigured.
Reviewer/listing rule: explain the SafeCall dependency before describing features. Reviewer instructions use an isolated SafeCall-style environment, durable sample QR, and safe test notifications; they do not use client data or ask reviewers to configure ntfy/topics.
Sales rule: present Keryx only inside SafeCall/AlertHub opportunities and quote the wider deployment, implementation, infrastructure, and support, never a Keryx SKU. Do not direct an unqualified prospect to download it.
Support rule: explain that a free download alone cannot receive alerts. Route contracted clients to SafeCall provisioning/support and non-clients to the wider SafeCall commercial path, without an in-app purchase link.
MDM installation: clients may assign or install the same public store apps (com.sourcectl.keryxapp on Apple Business Manager; com.sourcectl.keryx on managed Google Play) through Apple Business Manager/standard MDM or managed Google Play.
MDM limits: MDM is an installation channel only. Launch does not support managed app configuration, MDM-injected credentials, deep-link provisioning, zero-touch setup, custom/private binaries, or silent configuration. An administrator must grant permissions and scan their SafeCall-generated QR on the device.
Managed-device qualification: restrictive device policies require client IT review for camera, notifications, network access, Android background/power behavior, and other platform controls. No blanket managed-device compatibility claim is made before P0-04 and P4 evidence pass.
Rationale: the facts distinguish enterprise connectivity setup from a QR that unlocks externally purchased digital content, give reviewers a complete test path, prevent misleading consumer installs, and allow standard public app assignment without promising unimplemented managed configuration.

The decision approves facts and message boundaries, not final public artifacts:

Surface	Current evidence	Handoff
Keryx onboarding and app copy	The app has no account, checkout, billing, or IAP, but first launch does not yet explain the SafeCall commercial dependency and still refers to a separate administrator	P2-01 #104 and P2-05 #108 propagate approved identity and bilingual in-app wording
SafeCall QR generation	QR data configures ntfy connectivity/topics, but the current administrator UI exposes transport language and manual fallback	P1-01/P1-02 #94, #95 secure the contract; P2-05 #108 replaces public transport wording
Listings, sales, support, and client onboarding	No approved final English/Czech listing, public Keryx pages, or client handbooks exist	P2-02 #105, P2-04 #107, P4-06 #120, and P4-07 #121 implement the approved facts
MDM and managed devices	Public apps can be assigned through standard enterprise stores, but Keryx has no managed-configuration/deep-link reader and restrictive profiles are untested	P0-04 #92 defines the device baseline; P4 readiness and client IT guidance validate supported policy conditions
Reviewer environment and final console copy	Durable QR/test services and final review notes are missing	P5-01 #123 provides isolated access and P5-03 #125 verifies the final bilingual narrative

P0-04 support baseline decision — 13 August 2026

Status: approved.
Owner and approver: Thomas Minitsios.
OS support: iOS/iPadOS 17 or later and Android 12/API 31 or later on Google Play-certified devices. Test iOS/iPadOS 17, 18, and 26 and Android 12/12L, 13, 14, 15, and 16/API 31–36. Keep Android target/compile API 36 and verify 16 KB native-page support from the release candidate.
Source-floor gap: current source permits iOS 13 and Android API 24. Those are implementation defaults, not support promises. P3/P4 must set and verify explicit iOS 17/API 31 floors before release.
Form factors: support iPhone, iPad, Android phones, and Android tablets with a functioning camera for QR provisioning.
Orientations: iPhone supports portrait and landscape left/right, not upside-down; iPad supports all four orientations; Android phones/tablets support portrait and landscape.
Not separately certified: foldables and Chromebooks may install but have no launch support commitment until qualified.
Unsupported launch platforms: macOS, Windows, Linux, web, visionOS, wearables, Android Auto, CarPlay, Fire OS, devices without supported Google Play distribution, and devices without a functioning camera.
Tier 1 Android: Google Pixel/AOSP baseline and Samsung Galaxy. Full delivery, foreground/background/terminated, reboot, Doze, upgrade, soak, orientation, tablet, and accessibility matrices must pass.
Tier 2 Android: Xiaomi/Redmi/POCO, Motorola/Lenovo, and OnePlus/Oppo/Realme are supported only for the tested model/OS combination after documented battery/background exceptions pass. A family name alone is not evidence.
Tier 3 Android: no-GMS Huawei, Fire OS, uncertified/unknown OEMs, rooted/custom ROMs, end-of-life OS/devices, and restrictive profiles that block required capabilities remain unsupported until separately qualified.
Battery exception policy: exceptions are evidence-driven, least-privilege, device-specific, documented in English/Czech, and approved by client IT. Tier 1 must not silently depend on undocumented exceptions. Tier 2 is removed from support when approved settings cannot pass.
Platform limitations: force-stop/force-quit prevents background delivery until platform recovery or reopen and must be documented. It is not evidence for a guaranteed-delivery claim.
Stop and waiver policy: any supported-tier core alert-path failure, unresolved Android FGS/iOS APNs blocker, inaccessible critical flow, or failed permission recovery is a no-go, not “best effort.” A waiver requires the P0-05 go/no-go authority, named owner, rationale, expiry, and review date.
Accessibility scope: all criteria apply on physical supported devices in English and Czech to onboarding, QR scan, permission recovery, Active/Archive, notification detail, pause/resume, rescan, and reset.
Assistive technology: complete the critical flows with VoiceOver and TalkBack. Actionable controls, status/error feedback, emoji/timestamps, and scanner controls need meaningful spoken names.
Visual/layout: meet WCAG 2.2 AA on critical flows; at least 4.5:1 contrast for normal text and 3:1 for large text/UI components; remain complete and reachable at 200% text scale across supported form factors/orientations; provide at least 44×44 pt iOS and 48×48 dp Android action targets.
Interaction: provide logical visible focus, keyboard/switch access where platform-supported, no critical task dependent on animation, and honored reduced-motion settings.
Permission recovery: camera and notification denial or later revocation must produce a clear explanation, route to system Settings, and successful return/recovery without a dead end.
Evidence boundary: this is a requirement, not a current-conformance claim. P4-02/P4-03 own the pass/fail evidence.

The decision narrows support; it does not claim the current product passes:

Surface	Current evidence	Handoff
Platform projects and release artifacts	Xcode sets iOS 13; Android inherits Flutter API 24–36; iPhone/iPad and all selected orientations are declared; 16 KB compatibility is unproven	P3 release work aligns explicit floors and proves artifact compatibility; P1-03 #96 and P1-04 #97 close delivery blockers
Flutter accessibility and permissions	No explicit semantics program or accessibility tests exist; camera and notification outcomes lack complete denial/revocation recovery	P4-02 #116 implements/audits the full baseline; P2-05 #108 supplies English/Czech UI
Device, OEM, orientation, and soak evidence	Phone/tablet support is declared but layouts, OEM behavior, battery exceptions, restrictive profiles, and long-running delivery are unproven	P4-03 #117 executes the physical matrix and P4-04 #118 verifies reboot/upgrade/network recovery
Administrator/client guidance	Current docs mention OEM battery behavior but do not provide approved device-specific English/Czech exception and permission-recovery procedures	P4-06 #120 and P4-07 #121 publish the support boundaries and recovery steps

P0-05 launch ownership decision — 25 August 2026

Status: approved.
Owner and approver: Thomas Minitsios.
Go/no-go authority and backup: Thomas Minitsios is both the go/no-go authority and the named backup. Waivers under P0-04 still require this authority, rationale, expiry, and review trigger.
Single-person risk: authority and backup are the same person. This is a named concentration risk, not a silent acceptance. Review when P3-06/#114 verifies account recovery and at the first P5 go/no-go; reopen if a second named person becomes available.
RACI: Thomas Minitsios is Responsible and Accountable for product, Keryx app, SafeCall platform, ntfy/push, security/privacy, legal, stores, content, support, and incidents. Consulted: external counsel if product scope, health functionality, medical claims, or P0-02 regulatory assumptions change; client IT for device-policy and battery exceptions. Informed: SafeCall account owners and affected administrators via the SafeCall path. Later issues have this accountable owner even while GitLab assignees remain unset.
Date policy: do not invent beta or production calendar dates, and do not set the GitLab milestone due date. No beta or production date until remaining P1–P4 priority::launch-blocker items are closed or explicitly accepted in this roadmap. The Keryx public launch milestone stays dateless; P5-05/#127 executes go/no-go only after that gate.
Support model: Keryx uses the existing SafeCall support channel. There is no standalone Keryx mailbox, public status page, 24/7 desk, or emergency-dispatch SLA. Hours and response class: Czech business hours (Monday–Friday, CET/CEST); first response next business day; supported-tier core-path incidents acknowledged the same business day by the go/no-go owner. Actual mailbox, phone, and store support URLs stay in controlled records.
Status and incident channel: internal GitLab plus the SafeCall account/support path. No public status page at launch. P5-05/#127 and P6-05/#132 operationalize coverage, severity, and client communications.
Telemetry: no analytics or crash SDK at launch; no administrator identifiers in this repository. Field diagnosis is client-reported until P6-05/#132 approves minimum signals. P1 privacy work must not add collection before purpose, minimization, retention, and disclosure are approved.
Rationale: naming one accountable person closes the P0 exit gate without inventing dates or a separate support organization, keeps Keryx inside the SafeCall operating model, and records the single-person and no-telemetry trade-offs for later review.

The decision assigns accountability; it does not claim operating artifacts already exist:

Surface	Current evidence	Handoff
Public privacy, terms, and support URLs	P1-06 DRAFT source and path plan exist in legal/; live pages and verified contacts are missing	P2-04 #107 publishes HTTPS pages; P3-06/#114 and P5-03/#125 verify contacts and console URLs
Controlled organization and support contacts	`sourcectl` trader status is decided; verified mailbox, phone, and store contacts are not in this repository	P3-06 #114 verifies controlled evidence and P5-03 #125 verifies console disclosure
Administrator and client support handbooks	Strategy requires SafeCall-channel support, but final guides and escalation material are incomplete	P4-06 #120 and P4-07 #121 publish them
Go/no-go execution and client communications	No release candidate or staged rollout has run	P5-05 #127 executes after P1–P4 launch blockers close
Monitoring, intake, and incident communications	No privacy-safe monitoring or dedicated intake process exists	P6-05 #132 owns operational signals and communications
Account recovery and second-person review	Go/no-go authority and backup are the same person	P3-06 #114 verifies recovery and triggers named-backup review

Exit gate P0: every open decision table field is approved or explicitly deferred; the fixed product model has not been reopened; all later issues have an accountable owner even if dates remain unset. P0 exit gate passed 25 August 2026 under the P0-05 ownership, date, support, and telemetry decisions above.

P1 — Trust, security, privacy, and delivery architecture

Goal: make alert delivery and data handling defensible before creating public claims or production release artifacts.

ID	State	Work item	Exit criterion
P1-01	Ready	#94 — Threat-model QR provisioning and ntfy topic access	Reviewed data-flow and abuse-case model covers QR disclosure, topic guessing, unauthorized subscribe/publish, replay, device loss, debug access, and client offboarding
P1-02	Ready	#95 — Design TLS-only authenticated ntfy provisioning	Approved protocol defines HTTPS enforcement, least-privilege subscription credentials, publishing credentials, rotation/revocation, QR version migration, and legacy handling
P1-03	Ready	#96 — Resolve Android background delivery and Play foreground-service compliance	The perpetual `dataSync`/boot design is replaced or proven valid against API 35/36 timeout/start rules and Play policy; declaration, demo, OEM limits, fallback, and physical-device evidence are approved
P1-04	Ready	#97 — Productize iOS APNs and ntfy killed-state delivery	APNs token registration/rotation reaches an authenticated provider; production delivery is documented, monitored, and proven on physical devices in foreground/background/terminated states
P1-05	Ready	#98 — Define alert data classification, retention, and secure local storage	Alert fields are classified; retention/deletion, backup behavior, screen/lock exposure, storage protection, device loss, and offboarding controls are approved
P1-06	Ready	#99 — Publish Keryx privacy, terms, and support commitments	Counsel-reviewed or explicitly draft-marked policies exist at permanent URLs, match actual data flows, and are reachable in app and store metadata
P1-07	Ready	#100 — Complete Apple privacy, encryption, and SDK compliance	Xcode privacy report, app/SDK manifests, required-reason APIs, nutrition label, encryption answer, permission strings, and in-app privacy link are verified
P1-08	Ready	#101 — Complete Play Data Safety, permissions, and foreground-service declarations	Data Safety, app access, ads, audience, content rating, permissions, and FGS declarations match the tested AAB and public policies
P1-09	Ready	#102 — Audit dependencies, licenses, privacy manifests, and vendored ntfy ownership	Dependency inventory, licenses/notices, update ownership, vulnerability response, SDK privacy evidence, and vendored plugin maintenance plan are approved
P1-10	Ready	#103 — Define safety claims, delivery limitations, and regulatory position	Store/client/support copy states whether Keryx is supplemental, documents Do Not Disturb/OEM/network failure limits, defines escalation, and records legal/regulatory review

P1-01 threat model — 25 August 2026

Status: approved as analysis; treatments remain open.
Owner and reviewer: Thomas Minitsios (product, mobile, server, ops, and privacy roles under P0-05 RACI).
Artifact: Keryx QR and ntfy threat model.
Findings: current safecall.keryx.ntfy.v1 QR and SafeCall publish path carry no ntfy credential; Keryx accepts HTTP and HTTPS; topics are predictable {server_id}-{topic_id}; local SharedPreferences retain config and alert bodies; debug QR access can expose transport metadata; offboarding has no remote revocation handle.
Launch posture: abuse cases A1–A7 and A10 are launch blockers. Closing #94 does not accept anonymous or cleartext production designs and does not implement TLS or credentials.
Handoff: #95 owns HTTPS, subscribe/publish credentials, QR versioning, rotation, revocation, and v1 migration; #98 owns local data controls; #99– #101 own disclosures; #103 owns safety claims; #119 owns deployer ntfy prerequisites; #120/#121 own admin offboarding guidance.

P1-02 provisioning protocol — 25 August 2026

Status: approved as protocol design; implementation remains open.
Owner and approver: Thomas Minitsios.
Artifact: Authenticated provisioning protocol.
TLS: HTTPS only for production, test, and reviewer ntfy. No private-network or loopback HTTP exception.
Credentials: per-QR read-only ntfy access tokens scoped to selected topics; separate SafeCall-side publish token and token-manager credential; publish token never enters a QR.
Lifecycle: mint on QR generate; revoke/rotate by token id; local reset is not sufficient offboarding; no default wall-clock expiry.
QR contract: safecall.keryx.ntfy.v2 with subscribe_auth and optional token_id; fail-closed rejection of v1 and stored HTTP/v1 config; no production dual-run of anonymous plus authenticated topics.
Launch posture: closing #95 does not claim ntfy ACL, tokens, or v2 QR exist in code. Residual A1–A7/A10 remain launch blockers until implementation and related treatments land.
Handoff: later implementation for config/publisher/QR/Keryx auth wiring; #98 local secret storage; #99–#101 disclosures; #103 claims; #119 deployer prerequisites; #120/#121 revoke/offboarding guidance.

P1-03 Android delivery architecture — 25 August 2026

Status: approved as architecture design; implementation and device proof remain open.
Owner and approver: Thomas Minitsios.
Artifact: Android delivery architecture.
Primary path: ntfy upstream FCM poll_request wakes Keryx; bounded authenticated HTTPS poll recovers cached alerts (same semantic as iOS APNs poll_request).
Foreground path: in-app stream or short poll while UI is open; no perpetual background FGS and no indefinite wake lock for launch.
Deprecated: perpetual dataSync FGS with START_STICKY, indefinite wake lock, and automatic boot/locked-boot/package-replaced FGS restart.
Fallbacks: Tier 2 poll-on-resume without FCM/upstream; Tier 3 documented OEM battery exceptions per P0-04 only.
Launch posture: closing #96 does not claim FCM wiring, FGS removal, Play forms, or the P4-03 physical matrix exist. Residual delivery risk remains until implementation, #119 upstream config, #101 declarations, and #117 evidence land.
Handoff: later plugin/Keryx FCM and FGS removal; #119 FCM/upstream prerequisites; #101 Play declarations; #103 claims; #117 device matrix; #120/#121 troubleshooting.

P1-04 iOS APNs delivery architecture — 25 August 2026

Status: approved as architecture design; implementation, signing, and device proof remain open.
Owner and approver: Thomas Minitsios.
Artifact: iOS APNs delivery architecture.
Token provider: provisioned client ntfy HTTPS host with per-QR subscribe_auth; not a SafeCall token API.
Wake path: client ntfy cache + upstream poll_request + APNs for iOS bundle com.sourcectl.keryxapp; sourcectl owns APNs credentials; client ntfy uses upstream-base-url (or equivalent) to an APNs-capable upstream.
Token contract: forward on register/refresh; delete on reset/invalidation; no raw tokens in ordinary UI.
Fallbacks: Tier 2 foreground/resume without upstream; honest Focus, force-quit, cache-expiry, and network limits.
Launch posture: closing #97 does not claim token POST, upstream, or production entitlement exist in code. Residual risk remains until implementation, #110 signing, #119 upstream checklist, and #117 evidence land.
Handoff: later iOS plugin token wiring; #110 entitlements; #119 deployer prerequisites; #103 claims; #117 device matrix; #120/#121 troubleshooting.

P1-05 data classification and local storage — 25 August 2026

Status: approved as policy design; privacy pages and store forms remain open; optional secure-storage hardening is deferred.
Owner and approver: Thomas Minitsios.
Artifact: Data classification and local storage.
Lock-screen: full title + body OS preview for launch; must be disclosed.
Storage: SharedPreferences approved for config (including future subscribe_auth) and alert history; treat subscribe auth as a secret in docs/support; Keychain/EncryptedSharedPreferences not a launch blocker.
Retention: 200 visible messages; 500 deleted tombstones for cache-poll suppression only.
Offboarding: local reset is not enough; require ntfy token revoke (P1-02) plus wipe/reset guidance (#120/#121).
Backups: default OS prefs backup accepted; disclose alert/config secret exposure.
Launch posture: closing #98 does not implement encrypted storage, redacted lock-screen, privacy URLs, or store forms. Residual A7/A10 remains until revoke UX and related treatments land.
Handoff: #99–#101 disclosures; #103 claims; #120/#121 offboarding; #132 support redaction.

P1-06 privacy, terms, and support drafts — 25 August 2026

Status: approved as DRAFT source package; not counsel-reviewed; not live on a public host.
Owner: Thomas Minitsios.
Artifact: Legal drafts (privacy, terms, support + index).
URL plan: {public_base}/keryx/privacy, /keryx/terms, /keryx/support where {public_base} comes from controlled records; #107 publishes.
Content: matches P1-05 inventory, P0 publisher/support class, delivery architectures; non-medical / supplemental wording approved in safety-claims.md (P1-10).
Launch posture: closing #99 does not claim URLs are live, contacts are in git, app About links exist, or counsel has signed off.
Handoff: #107 live pages; #108 Czech; #100/#101/#125 forms and metadata; #103 claims packet (approved); later app Settings/About wiring.

P1-07 Apple privacy compliance packet — 25 August 2026

Status: approved as compliance packet; manifests/purpose-string implementation and signed privacy report remain open.
Owner and approver: Thomas Minitsios.
Artifact: Apple privacy compliance.
Manifests: app-level privacy manifest required; vendored ntfy must declare UserDefaults reason CA92.1; Flutter/plugin coverage completed via #102.
Purpose strings: approved English camera/notification copy (administrator QR / SafeCall alerts); Czech via #108.
Nutrition label: draft answers from P1-05/#99; no tracking; no analytics SDK; disclose on-device history.
Encryption: HTTPS-only / standard export exemption.
Privacy link: in-app About/Settings → {public_base}/keryx/privacy after #107.
Launch posture: closing #100 does not claim source fixes, signed report, ASC submission, or production aps-environment.
Handoff: implementation of manifests/strings; #102 inventory; #110 report; #107 URL; #125 ASC; #108 Czech.

P1-08 Play Data Safety compliance packet — 25 August 2026

Status: approved as compliance packet; signed-AAB inspection, Play Console submission, FGS removal in source, and live reviewer QR remain open.
Owner and approver: Thomas Minitsios.
Artifact: Play Data Safety.
Data Safety: disclose on-device config/history and client-deployer ntfy/FCM roles; no ads/analytics SDK; HTTPS in transit; full lock-screen disclosure; do not answer “no collection.”
FGS: launch target has no perpetual dataSync / boot FGS (P1-03); demo only if residual declared FGS remains in the submitted AAB.
App content: no ads; 18+; expected IARC Everyone; QR companion access narrative; privacy URL after #107; reviewer QR via #123.
Launch posture: closing #101 does not claim signed AAB inspection, Play submission, FGS already removed, live reviewer QR, or IARC certificate.
Handoff: FGS/FCM implementation; #102 inventory; #109 signing; #107 URL; #123 reviewer env; #125 Play Console; #103 claims.

P1-09 dependency and vendored-ntfy ownership — 25 August 2026

Status: approved as ownership packet; machine SBOM, CI gates, signed privacy verification, and NOTICE packaging remain open.
Owner and approver: Thomas Minitsios.
Artifact: Dependency ownership.
Inventory: direct Dart deps from pubspec.lock plus path ntfy1.0.2-keryx.1 (MIT); privacy-impacting plugins listed; transitive Gradle/Pods deferred to #112.
Privacy manifests: checklist aligned to P1-07 (ntfy CA92.1 required); not claimed fixed or signed-verified.
Cadence: quarterly + pre-submission advisory review; critical/high unmitigated blocks go/no-go.
Launch posture: closing #102 does not claim SBOM, CI gates, full transitive license dump, or pub.dev publication of the fork.
Handoff: #112 CI/SBOM; P1-07 source manifests; #109/#110 signing; #125 archive; #133 quarterly; #103 claims.

P1-10 safety claims and regulatory position — 25 August 2026

Status: approved as claims packet; listings, live legal pages, support runbooks, and device matrix remain open.
Owner and approver: Thomas Minitsios.
Artifact: Safety claims.
Role: supplemental administrator companion; clients retain non-Keryx operational paths; not sole alarm channel.
Critical Alerts: not sought at launch; ordinary notifications only.
Medical / category: reaffirm P0-02 Business / non-medical; prohibited diagnose/treat/cure/emergency-dispatch claims.
Limits: Focus/DND, permissions, force-stop, OEM battery, network/ntfy, push latency, pause — catalog in packet.
Escalation: SafeCall support class (P0-05); in-app ack is local only.
Launch posture: closing #103 does not claim Critical Alerts, counsel sign-off, listings updated, or #117 complete.
Handoff: #105 listings; #107 counsel/live pages; #120/#121 support; #117 matrix; #125 console; #108 Czech.
P1 exit: with #103 closed, all P1 design/compliance packets (#94–#103) are approved; implementation residuals remain on later phases.

Exit gate P1: no anonymous or unencrypted production design is accepted by default; Apple and Play disclosure packets match the actual tested binary; Android and iOS killed-state delivery have evidence and honest limitations; safety claims are approved and supplemental.

P2 — Brand, client enablement, and store content

Goal: present Keryx consistently as part of SafeCall and provide every client, administrator, and reviewer-facing artifact needed for installation and both stores, without creating an independent acquisition campaign.

ID	State	Work item	Exit criterion
P2-01	Ready	#104 — Create approved visual identity and store asset kit	Approved SafeCall-related wordmark, app icon QA, Android adaptive/monochrome assets, Apple icon, palette/type guidance, ownership/source files, and usage rules exist without implying a standalone product
P2-02	Ready	#105 — Produce canonical App Store and Google Play listing copy	Approved copy, categories, release-note templates, contact data, and review narrative state the SafeCall dependency, administrator audience, QR setup, and absence of manual ntfy/topic configuration in every locale
P2-03	Ready	#106 — Produce privacy-safe store screenshots and preview assets	Required screenshots show friendly SafeCall alert categories, administrator QR provisioning, and first-party Active/Archive UX with redacted test data; sources and repeatable capture steps pass brand/privacy review
P2-04	Ready	#107 — Publish Keryx product, install, privacy, and support web pages	Permanent HTTPS install, privacy, terms, and support pages serve SafeCall clients and store metadata, state that Keryx requires SafeCall, and do not act as an independent lead-generation campaign
P2-05	Ready	#108 — Localize Keryx, admin provisioning, and store content	Approved locale list is implemented across app UI, permission/help copy, friendly-category SafeCall provisioning UI, listings, screenshots, release notes, and support docs without ordinary-administrator ntfy/topic terminology

Exit gate P2: a reviewer, client, and SafeCall administrator see the same publisher, SafeCall relationship, audience, QR workflow, capabilities, limitations, support channel, and privacy story everywhere; no artifact presents Keryx as independently usable or marketed.

P2-01 visual identity and store asset kit — 26 August 2026

Status: approved as identity brief. Mark revised 7 September 2026 (white megaphone on #003087). Android adaptive / round / monochrome and launch images are in source. Wordmark artwork files and leftover launcher metadata casing remain open.
Owner and approver: Thomas Minitsios.
Artifact: Visual identity.
Hierarchy: sourcectl / Wantok / SafeCall / Keryx for SafeCall / launcher Keryx; mark-only icon; no standalone positioning.
Mark: keryx/assets/icon/keryx_icon.svg + opaque 1024 PNG (#003087 / #FFFFFF); previous shield archived as keryx_icon_v1_shield.png.
Gaps: wordmark artwork; launcher casing fixes.
Launch posture: closing #104 does not claim store graphics final or wordmark shipped.
Handoff: wordmark files; #108.

P2-02 canonical store listing copy — 26 August 2026

Status: approved as listing-copy packet; live URLs, verified contacts, and console paste remain open.
Owner and approver: Thomas Minitsios.
Artifact: Store listing copy.
Locales: English + Czech field parity for Apple and Google listing fields, reviewer notes, and release-note templates.
Narrative: SafeCall dependency first; free companion; QR configures connectivity not purchase; supplemental limitations per P1-10; Business / administrator 18+.
Gaps: {public_base} and contact placeholders; Czech app/provisioning UI implementation; screenshot PNG exports.
Launch posture: closing #105 does not claim listings are live, URLs resolve, counsel sign-off, or store consoles filled.
Handoff: screenshot kit #106; public web packet #107; #108 app Czech; #114 contacts; #125 console paste.

P2-03 privacy-safe store screenshot kit — 26 August 2026

Status: approved as screenshot-kit specification; PNG exports, design sources, and console upload remain open.
Owner and approver: Thomas Minitsios.
Artifact: Store screenshot kit; planned exports under keryx/store-assets/.
Coverage: iPhone 6.9", iPad 13", Android phone (+ optional tablet), Play feature graphic; EN + CS captions; seven-frame narrative including optional SafeCall provisioning.
Privacy: fictional sample data catalog; pre-export redaction checklist; no production client QR or credentials.
Launch posture: closing #106 does not claim PNGs committed, #123 live, Czech UI captured, or store graphics uploaded.
Handoff: #123 capture env; #108 Czech UI; PNG export; #125 console paste; #114 release evidence.

P2-04 public web pages publication packet — 26 August 2026

Status: approved as publication packet; HTTPS deploy, counsel sign-off, and store URL verification remain open.
Owner and approver: Thomas Minitsios.
Artifacts: Public web pages; install draft; legal privacy/terms/support unchanged (P1-06 DRAFT).
URL map: {public_base}/keryx, /keryx/privacy, /keryx/terms, /keryx/support.
Narrative: SafeCall companion landing; no BleuVista/AlertHub ownership; no standalone consumer funnel; EN + CS landing copy approved.
BleuVista site: relationship rules documented; website/ not updated in this close.
Launch posture: closing #107 does not claim URLs resolve, DNS/TLS live, Czech HTML published, or in-app/store links wired.
Handoff: HTTPS deploy; #108 Czech HTML; #114 {public_base} and contacts; #123 reviewer path; #125 console verify; in-app About link.

P2-05 localization policy and EN/CS implementation — 26 August 2026

Status: approved as localization policy; Flutter ARB, web catalogs, platform strings, and legal CS DRAFT bodies implemented in source.
Owner and approver: Thomas Minitsios.
Artifact: Localization; keryx/l10n/ ARB files; lib/src/ui_translation_*_catalog.ts provisioning keys.
Locales: English primary/default + Czech parity across Keryx app, SafeCall admin provisioning, iOS/Android permissions, and legal DRAFT public texts.
Narrative: friendly alert categories; no ordinary-admin ntfy/topic jargon; QR labels follow admin UI locale.
Gaps: Czech screenshot PNGs; live Czech HTTPS pages; store console paste; counsel review of legal CS.
Launch posture: closing #108 does not claim Czech HTML is live, screenshots exported, listings pasted, or counsel sign-off.
Handoff: #106/#123 Czech capture; #107 deploy; #125 console; #114 contacts; counsel review.

P3-01 Android production signing — 26 August 2026

Status: closed. Signing packet, fail-closed Gradle, and verify:keryx-aab landed 26 August 2026. Operator complete 30 August 2026: Play app Keryx for SafeCall, Czech Republic only, internal-testing AAB draft, upload SHA-256 0D:AC:61:B1:5F:85:91:3F:2B:21:20:5E:46:14:81:90:20:13:85:8B:76:D2:00:91:36:FD:30:9D:18:D8:0D:AA (supersedes the 26 August cert; do not register the old fingerprint). MiniVan-3 recovery matched the same upload cert.
Owner and approver: Thomas Minitsios.
Artifact: Android signing; keryx/android/key.properties.example; keryx/android/app/build.gradle.kts; scripts/release/keryx-verify-aab.ts.
Model: Google Play App Signing (app key) + operator-held upload key; release never uses debug signing.
Gaps: CI secret injection (#112); store paste (#125).
Launch posture: closing #109 does not claim Internal/Production track promotion, CI gates, or iOS signing.
Handoff: #112 CI; #114 org roles / EU trader; #125 console.

P3-02 iOS distribution signing — 26 August 2026

Status: signing packet and repo wiring approved; App ID unblocked 29 August 2026 as com.sourcectl.keryxapp (Apple case 102915938031 will not release com.sourcectl.keryx). Primary signed IPA verified with aps-environment = production. MiniVan-3 recovery IPA verified 30 August 2026. ASC app Keryx for SafeCall exists (Czech Republic only). Distribution .p12 backup of both Macs is on the NAS share (OA-110-cert-backup, 1 September 2026).
Owner and approver: Thomas Minitsios.
Artifact: iOS signing; keryx/ios/ExportOptions.plist; scripts/release/keryx-verify-ipa.ts.
Model: distribution cert + App Store profile; signed IPA proves aps-environment = production; source entitlements may stay development.
App ID: com.sourcectl.keryxapp on team 8P59575P2K. Android remains com.sourcectl.keryx.
Gaps: CI (#112); store paste (#125); APNs .p8 on the NAS share (OA-110-apns-p8 / #119).
Launch posture: P3-02 / #110 signing packet is complete (IPA proof, MiniVan recovery, .p12 backup). TestFlight soak is #124.
Handoff: operator checklist in ios-signing.md and operator-actions.md; #112 CI; #114 org roles / EU trader; #125 ASC.

P3-03 Keryx AAB and IPA release pipeline — 1 September 2026

Status: recorded full bun run release:keryx -- --contracts on GLaDOS (version 1.0.0+1, commit 6665a480). CI secret injection remains #112.
Owner and approver: Thomas Minitsios.
Artifact: bun run release:keryx (scripts/release/keryx.ts); operator-actions.md OA-111-pipeline.
Model: analyze/test, optional contracts, signed AAB+IPA, verify scripts, local checksum file under gitignored keryx/build/release-evidence/. No store upload, no git push. --bump / --tag follow versioning.md.
Gaps: CI (#112); symbols/SBOM archive (#112); #114 org roles / EU trader; store paste (#125). --bump/--tag unused on this first recorded run.
Launch posture: P3-03 / #111 is complete for the local pipeline.
Handoff: #112 CI; #114 org roles / EU trader; #125 console paste.

P3-05 Versioning and QR compatibility — 26 August 2026

Status: approved versioning, changelog, tag, QR compatibility, migration, downgrade, and launch support-window policy.
Owner and approver: Thomas Minitsios.
Artifact: versioning.md; keryx/CHANGELOG.md skeleton.
Model: semver + monotonic shared build number; annotated keryx-v* tags; EN changelog → store templates; v2 QR cutover is coordinated gate (code still v1).
Gaps: first recorded pipeline did not use --bump/--tag; {min_safeCall} numeric value at G2 (#114); QR v2 implementation; full EOL matrix (#130).
Launch posture: closing #113 does not claim automated versioning, QR v2 code, store release notes pasted, or production promotion.
Handoff: #112 CI; #114 org roles / EU trader; #125 console paste; #130 EOL lifecycle.

P3 — Build, signing, and release engineering

Goal: produce repeatable, attributable, recoverable store artifacts without depending on one workstation or an undocumented key.

ID	State	Work item	Exit criterion
P3-01	Done	#109 — Configure Android production signing and key recovery	Play App Signing enrolled; upload SHA-256 `0D:AC:61:B1:…:0D:AA`; fail-closed Gradle; MiniVan recovery matched; Czech Republic only; internal-testing draft (no production rollout)
P3-02	Done	#110 — Configure iOS distribution signing and production entitlements	Distribution team, App ID `com.sourcectl.keryxapp`, profiles/certificates, production APNs entitlement, export options, capabilities, access, backup, and renewal are proven — GLaDOS + MiniVan-3 IPAs, ASC CZ-only record, NAS `.p12` backup (1 September 2026)
P3-03	Done	#111 — Create a reproducible Keryx AAB and IPA release pipeline	`bun run release:keryx -- --contracts` recorded 1 September 2026 on GLaDOS (`1.0.0+1`); CI/SBOM is #112
P3-04	Missing	#112 — Add Keryx CI quality, dependency, and supply-chain gates	Protected CI runs static tests, app tests, provisioning contracts, native compile checks, dependency/license checks, and artifact integrity checks
P3-05	Ready	#113 — Define versioning, changelog, tagging, and QR compatibility policy	Version/build/tag rules, changelog ownership, release-note derivation, QR schema compatibility, migrations, minimum compatible SafeCall version, and downgrade behavior are documented — versioning.md
P3-06	Partial	#114 — Establish store records, account roles, and release evidence archive	App Store Connect/Play records exist (CZ-only). NAS evidence archive and MiniVan access proven (OA-114-archive). Still owed: least-privilege org roles, 2FA/recovery verification, EU trader.

Exit gate P3: a second authorized operator can build, verify, upload, and recover both artifacts using documented access without exposing secrets.

P4 — Product and client readiness verification

Goal: prove that the whole SafeCall-to-device service works for real clients, not just that Flutter can compile.

ID	State	Work item	Exit criterion
P4-01	Partial	#115 — Build requirements-to-test coverage for app and provisioning flows	Traceability covers the administrator-only persona, friendly-category selection, QR-hidden transport configuration, absence of normal ntfy/topic terminology, persistence, notification lifecycle, debug gating, permissions, platform services, API contract, and regression ownership
P4-02	Missing	#116 — Complete accessibility and permission-denial readiness review	VoiceOver/TalkBack, text scaling, contrast, focus/order, motion/orientation, camera denial, notification denial, and recovery paths pass the P0 baseline
P4-03	Missing	#117 — Execute real-device, OEM, and long-running delivery matrix	Approved iOS/Android versions and OEM tiers pass foreground/background/terminated/reboot/battery/Doze and sustained-delivery tests with recorded results
P4-04	Missing	#118 — Verify upgrade, reboot, network, cache, and reprovisioning behavior	Store-like upgrade preserves config/history; package replacement, reboot, offline/cache expiry, network changes, clock skew, pause/reset, rescan, and server migration have expected outcomes
P4-05	Partial	#119 — Publish client ntfy and push infrastructure prerequisites	Restricted deployer/support checklist covers TLS, auth, APNs/FCM, caching, retention, firewall/DNS, monitoring, test messages, ownership, backup, rotation, and acceptance evidence without making transport setup part of the ordinary administrator workflow
P4-06	Partial	#120 — Publish administrator provisioning and support handbook	Admin guide covers friendly alert-category selection, scan-on-own-device QR setup, test alert, secure replacement/revocation, troubleshooting, escalation, and translations without requiring ntfy/topic knowledge
P4-07	Missing	#121 — Publish administrator app onboarding, troubleshooting, and offboarding guide	Public SafeCall client guide covers store install, permissions, QR scan, expected persistent indicators, battery settings, pause, replacement device, reset, support, privacy, uninstall/offboarding, and migration from a manually configured ntfy client
P4-08	Missing	#122 — Complete a client pilot and operational handoff	Named pilot administrators provision from friendly SafeCall categories without transport assistance, pass agreed scenarios and soak period, report defects, and hand support/go-no-go evidence to the named owners

Exit gate P4: the pilot environment passes its full matrix with production architecture, signed release candidates, final docs, and staffed support.

P5 — Store submission and launch

Goal: give reviewers durable access, complete both review loops, and release gradually with an explicit stop decision.

ID	State	Work item	Exit criterion
P5-01	Missing	#123 — Build permanent reviewer QR and isolated test notification environment	Non-expiring SafeCall-style QR page with friendly categories, isolated HTTPS/authenticated test notification service, safe sample alerts, administrator instructions, monitoring, and owner survive the review window without requiring reviewers to configure ntfy
P5-02	Missing	#124 — Complete TestFlight and Play internal/closed beta	Representative testers install from store channels, execute the release matrix, report no unresolved blockers, and approve candidate build numbers
P5-03	Missing	#125 — Complete store metadata, policy forms, and review instructions	Final artifacts, URLs, privacy/data answers, FGS evidence, access instructions, contacts, availability, pricing, and release notes are peer-reviewed in both consoles and consistently describe an included SafeCall administrator companion
P5-04	Missing	#126 — Submit to Apple and Google and resolve review findings	Candidate is submitted to both stores; questions/rejections are logged and resolved without unreviewed scope changes; both builds are approved
P5-05	Missing	#127 — Execute go/no-go, phased production rollout, and launch communications	Gate sign-off, support coverage, status/incident channel, staged percentages, observation windows, stop thresholds, SafeCall client communications, and install/support links are executed without a standalone Keryx campaign

Exit gate P5: approved versions are publicly available in selected regions, the rollout completed without crossing a stop threshold, and clients have a supported installation path.

P6 — Updates and post-launch operations

Goal: keep Keryx installable, compatible, secure, and supportable after the launch project ends.

ID	State	Work item	Exit criterion
P6-01	Missing	#128 — Establish normal release train and staged update process	Cadence, intake/freeze, release branch/tag, test channels, approvals, notes, staged rollout, monitoring window, docs, and closure evidence are exercised
P6-02	Missing	#129 — Establish hotfix, security release, stop-rollout, and rejection response	Severity/authority, patch path, expedited tests, disclosure, rollout halt, unavailable rollback behavior, superseding release, rejection response, and client communications are rehearsed
P6-03	Missing	#130 — Define compatibility, minimum-version, deprecation, and end-of-life policy	Keryx/SafeCall/QR/ntfy compatibility matrix, support window, old-version behavior, minimum-version mechanism decision, notices, store removal, and data/offboarding steps are approved
P6-04	Missing	#131 — Schedule signing, credential, SDK, and store-policy renewals	Named owners and reminders cover Apple membership/certs/APNs keys, Google accounts/upload key, ntfy credentials, SDK/target API deadlines, policies, domains, and support URLs; recovery drill passes
P6-05	Missing	#132 — Establish privacy-safe monitoring, support intake, and incident communications	Delivery/support signals, crash strategy, consent/data minimization, alerting, dashboards, triage severity, escalation, status updates, postmortems, and retention are operational
P6-06	Missing	#133 — Review KPIs, store feedback, dependencies, and roadmap quarterly	Quarterly owner reviews reliability, adoption, support, ratings, policy changes, dependencies, security advisories, accepted risks, and backlog priorities with recorded decisions

Exit gate P6: normal and emergency release drills have been completed, all renewal dates have owners, and the quarterly product review is scheduled.

Go/no-go gates

Gate	Required evidence
G0 — Strategy approved	P0 decisions signed; every artifact preserves the administrator-only SafeCall companion, QR-hidden configuration, and non-standalone commercial story
G1 — Trust architecture approved	Threat model closed; transport/auth, Android delivery, iOS delivery, data handling, legal disclosures, and platform forms approved
G2 — Release candidate reproducible	Production-signed AAB/IPA, CI evidence, checksums, symbols, changelog, and recovery procedures archived
G3 — Client readiness passed	Administrators provision friendly categories by QR without ntfy/topic knowledge; device matrix, upgrades, delivery soak, accessibility, docs, infrastructure checklist, and client pilot are accepted
G4 — Submission ready	Permanent reviewer environment, final metadata/assets/forms, store-channel beta, and support coverage are verified without implying standalone use
G5 — Production release authorized	Both stores approved; change record, phased rollout, observation windows, stop thresholds, and communications signed
G6 — Handoff complete	Routine/hotfix runbooks exercised; monitoring, renewals, support, KPI review, compatibility, and EOL ownership transferred

No single green build can substitute for these gates.

Risk register

Risk	Impact	Treatment and decision owner
Android stops or rejects the perpetual `dataSync` foreground service	Android 15+ can time out the service after aggregate use and restrict boot starts; Play can reject the declared use	Perpetual FGS removed. Residual risk is missing Firebase/`firebase-key-file` (#119), Play form paste, and #117 evidence
iOS APNs token is not registered with a provider	No provider can address the device for terminated-state wake delivery	Client subscribes via Keryx Firebase. Residual risk is placeholder client files, missing APNs `.p8` in Firebase (#119), and #117 evidence
Predictable unauthenticated topics permit unauthorized subscribe/publish	Confidentiality, integrity, nuisance alerts, and trust risk	P1-01 threat model (threat-model.md) rates A1–A7/A10 as launch blockers; P1-02 protocol (provisioning-protocol.md) approves HTTPS-only per-QR subscribe tokens and a server-side publish token; residual risk remains until implementation, ntfy ACL (#119), and revoke UX land
Alert content can contain device/person/location-like identifiers	Store privacy answers and local-device risk may be understated	P1-05 policy (data-classification.md) inventories payloads, approves SharedPreferences + full lock-screen for launch with disclosure; #99–#101 must match; residual device-loss risk until revoke UX (#120/#121)
Approved Keryx identity is not propagated consistently	Review delay, client confusion, or incorrect external account/legal metadata	P0-01 fixes the publisher, name, casing, and hierarchy; P1/P2/P3 must propagate them and verify external account and legal details while preserving Keryx as a subordinate SafeCall companion
Czech launch is approved before bilingual parity exists	Czech administrators, reviewers, and support can encounter English-only or topic-oriented flows	P2-02 through P2-05 must deliver and review English/Czech copy, assets, pages, and application/admin localization before launch
EU trader and public contact evidence is incomplete	Store setup or Czech availability can be blocked, or incorrect contact data can be published	P3-06 verifies controlled organization/account evidence and P5-03 verifies the final Apple and Google disclosures
QR setup is mistaken for an external digital purchase or unlock	Store rejection or a demand for in-app purchase can result despite Keryx having no paid digital content	P0-03 fixes the factual explanation; P2-02, P5-01, and P5-03 must present and prove it consistently without external purchase calls to action
MDM installation support is overstated as managed configuration	Client IT expects zero-touch setup, injected credentials, or compatibility with restrictive profiles that Keryx does not implement or prove	P0-03 limits MDM to public-app assignment/install; P0-04 and P4 define and verify managed-device policy support
Source minimums are mistaken for supported OS versions	Legacy iOS 13/API 24 installs create an unbounded, untested support promise	P0-04 fixes iOS/iPadOS 17+ and Android API 31+; P3/P4 must align artifacts, listings, and evidence before release
Android OEM or battery exceptions are generalized without evidence	Missed alerts, excessive power use, or client-policy conflicts can occur on an untested model/profile	P0-04 uses Tier 1 required and Tier 2 model-specific evidence; P4-03 and client IT own qualification, and failed models are removed from support
Accessibility baseline is claimed before implementation passes	Administrators can be blocked from provisioning, permission recovery, or notification handling and public claims can be misleading	P0-04 defines measurable launch criteria; P4-02 must provide English/Czech physical-device evidence before a support/conformance claim
Administrator flow exposes ntfy/topics or assumes a separate generic end user	Recreates the third-party setup burden Keryx exists to remove and increases onboarding/support failures	P2 and P4 must use friendly categories, scan-on-own-device provisioning, guarded diagnostics, and administrator usability evidence
No durable reviewer environment	Apple/Google cannot exercise the configured experience	P5-01 creates a monitored, non-production test path
Signing or account access is held by one person/device	Updates can become impossible	P3-01/P3-02/P3-06 and P6-04 require custody and recovery drills; P0-05 also names the single-person go/no-go concentration for review at #114 and the first P5 go/no-go
No telemetry reduces privacy risk but limits field diagnosis	Delivery incidents may be invisible or slow to resolve	P0-05 records no analytics/crash SDK at launch; P6-05 chooses minimum necessary signals after client-reported diagnosis
Store or OS policy changes after launch	Updates can be blocked and listing visibility reduced	P6-04/P6-06 schedule policy and target-SDK review
Administrators treat Keryx as a guaranteed emergency channel	Harm can result from network, OS, focus mode, power, or service failures	P1-10 (safety-claims.md) locks supplemental claims, fallback, training, and escalation; listings/support copy via #105/#120/#121

Launch and operating measures

Targets are set in P0/P4; no numeric SLO is invented here. At minimum, the launch review must define and collect:

eligible SafeCall installations and administrator adoption by client;
successful onboarding rate from friendly category selection through QR scan to first verified test notification, including failures requiring transport knowledge or support intervention;
foreground, background, terminated, reboot, and upgrade delivery results by supported platform/OEM tier;
notification delivery latency and missed/duplicate rate in the controlled pilot;
crash-free sessions or an explicitly approved privacy-preserving alternative;
support contacts by severity, first-response time, and time to resolution;
beta and production adoption by supported version;
store review/rating themes and policy warnings;
release lead time, rejection rate, and emergency-fix drill time;
credential/certificate renewal status and dependency/security advisory age.

Metrics must not introduce analytics or identifiers. P0-05 prohibits an analytics or crash SDK at launch; P1 privacy work must approve purpose, collection, retention, and disclosure before any later signal is added.

Accepted and deferred risks

No launch risk is accepted yet. An accepted entry must include:

risk ID and linked GitLab work item;
decision date and decision maker;
affected clients/platforms and administrator impact;
compensating controls and support wording;
expiry/review date;
trigger that reopens the work.

Desktop/web distribution, optional promotional video, automated store upload, critical-alert entitlement, and in-app update enforcement may be deferred only after their owning issue records why they are unnecessary for the selected launch.

Audit evidence

Primary repository evidence:

keryx/pubspec.yaml
keryx/lib/
keryx/test/
keryx/android/app/build.gradle.kts
keryx/android/app/src/main/AndroidManifest.xml
keryx/vendor/ntfy/android/src/main/AndroidManifest.xml
keryx/ios/Runner/Info.plist
keryx/ios/Runner/Runner.entitlements
keryx/ios/Runner/AppDelegate.swift
keryx/vendor/ntfy/
web/src/admin/tools/mobile-access/mobile-access.ts
web/tests/e2e/mobile-access.spec.ts
server/src/ntfy.ts
server/src/ntfy_topics.ts
server/src/events.ts
docs/mobile/keryx.md
docs/mobile/keryx-publishing.md
package.json
scripts/release/mobile.ts
website/

GitLab was checked across all current issue states before bootstrap. No existing issue, label, or milestone matched Keryx GTM, app-store, Google Play, release, branding, privacy, or update-process work.

Keryx go-to-market roadmap ​

Scope ​

Related documentation ​

GitLab tracking ​

Status vocabulary ​

Executive audit verdict ​

Current baseline ​

Current store-policy baseline ​

Decision gates ​

Phase status and dependency flow ​

P0 — Product and governance decisions ​

P0-01 identity decision — 13 August 2026 ​

P0-02 launch classification decision — 13 August 2026 ​

P0-03 commercial review decision — 13 August 2026 ​

P0-04 support baseline decision — 13 August 2026 ​

P0-05 launch ownership decision — 25 August 2026 ​

P1 — Trust, security, privacy, and delivery architecture ​

P1-01 threat model — 25 August 2026 ​

P1-02 provisioning protocol — 25 August 2026 ​

P1-03 Android delivery architecture — 25 August 2026 ​

P1-04 iOS APNs delivery architecture — 25 August 2026 ​

P1-05 data classification and local storage — 25 August 2026 ​

P1-06 privacy, terms, and support drafts — 25 August 2026 ​

P1-07 Apple privacy compliance packet — 25 August 2026 ​

P1-08 Play Data Safety compliance packet — 25 August 2026 ​

P1-09 dependency and vendored-ntfy ownership — 25 August 2026 ​

P1-10 safety claims and regulatory position — 25 August 2026 ​

P2 — Brand, client enablement, and store content ​

P2-01 visual identity and store asset kit — 26 August 2026 ​

P2-02 canonical store listing copy — 26 August 2026 ​

P2-03 privacy-safe store screenshot kit — 26 August 2026 ​

P2-04 public web pages publication packet — 26 August 2026 ​

P2-05 localization policy and EN/CS implementation — 26 August 2026 ​

P3-01 Android production signing — 26 August 2026 ​

P3-02 iOS distribution signing — 26 August 2026 ​

P3-03 Keryx AAB and IPA release pipeline — 1 September 2026 ​

P3-05 Versioning and QR compatibility — 26 August 2026 ​

P3 — Build, signing, and release engineering ​

P4 — Product and client readiness verification ​

P5 — Store submission and launch ​

P6 — Updates and post-launch operations ​

Go/no-go gates ​

Risk register ​

Launch and operating measures ​

Accepted and deferred risks ​

Audit evidence ​