Keryx go-to-market

This section coordinates adoption and public iPhone/iPad App Store and Google Play distribution of Keryx as SafeCall's first-party notification companion for SafeCall administrators. Keryx replaces the generic ntfy client in the administrator workflow; it is not independently marketed.

The program separates adoption strategy, launch readiness, application behavior, and release operations:

Adoption strategy — fixed product model, installed-base rollout, SafeCall-led positioning, enablement, and measures.
Go-to-market roadmap — audited baseline, decisions, phases, risks, launch gates, and GitLab work items.
QR and ntfy threat model — P1-01 abuse cases, ratings, and treatment handoffs for provisioning and topic access.
Authenticated provisioning protocol — P1-02 HTTPS-only, per-QR subscribe tokens, publish token, and v2 QR contract.
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 com.sourcectl.keryxapp.
Data classification and local storage — P1-05 SharedPreferences + full lock-screen launch policy; retention and offboarding.
Legal drafts — P1-06 DRAFT privacy, terms, and support texts with planned public 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, escalation.
Visual identity — P2-01 mark, wordmark rules, palette, asset inventory, and store kit gaps.
Store listing copy — P2-02 bilingual Apple/Google fields, reviewer notes, and release-note templates.
Store screenshot kit — P2-03 device matrix, shot list, sample data, capture checklist, and captions.
Public web pages — P2-04 URL map, landing copy, deployment checklist, and monitoring rules.
Localization — P2-05 EN/CS policy, glossary, surface matrix, and release workflow.
Android signing — P3-01 Play App Signing, upload-key custody, fail-closed Gradle wiring, AAB verification, recovery drill.
iOS signing — P3-02 distribution signing, ExportOptions, IPA verification; App ID com.sourcectl.keryxapp registered; primary signed IPA verified; recovery drill passed on MiniVan-3 (30 August 2026); ASC app record exists (CZ-only). Both Macs’ Distribution .p12 files are on the NAS share (OA-110-cert-backup, 1 September 2026).
Internal TestFlight — Internal install of 1.0.0+3 is done (OA-124-testflight, 10 September 2026). Next FCM candidate is GLaDOS 1.2.0+7. Soak and App Review stay in the publishing runbook; do not close #124.
ntfy auth dual-run and Play Internal — first Play Internal install of 1.0.0+3 is done (OA-124-play-internal). Next FCM candidate is GLaDOS 1.2.0+7. ntfy auth dual-run (Parts A–D) is still owed. Deny-anonymous cutover and production Play stay later.
Firebase / FCM / APNs closed-app wake — Client files for keryx-for-safecall are in repo (1.2.0+7). Notify-host Firebase (OA-119-ntfy-fcm) is proven on hetest2 (13 September 2026). Upload Internal 1.2.0+7 and first-device swipe-away proof remain; do not close #119/#117. Installed Internal 1.0.0+3 is superseded for FCM proof.
Secret store — LAN NAS CT 500 (nas, 192.168.178.213): gocryptfs + File Browser / SFTP; secrets/keryx/ and evidence/keryx/. OA-114-archive is done. After a NAS reboot, unlock gocryptfs before using the share.
NAS unlock after reboot — gocryptfs + File Browser after CT 500 restarts (passphrase not in git).
Operator actions — human/portal/secret-store checklist (blocking vs later); keep in sync with GitLab close bars.
Versioning and compatibility — P3-05 semver/build/tag rules, changelog ownership, QR schema migration, downgrade and support window.
Keryx application — current product behavior and QR contract.
Alert topics — staff ntfy categories, triggers, tags, and send cadence.
Publishing Keryx — first release, routine update, hotfix, submission, and lifecycle runbook.
GitLab issue workflow — SafeCall issue and commit conventions.

Fixed launch scope

Public Apple App Store distribution for iPhone and iPad.
Public Google Play distribution for Android.
An included companion for administrators of a configured, contracted SafeCall deployment.
Friendly SafeCall alert-category selection followed by scan-on-own-device QR provisioning; no ordinary administrator needs to configure ntfy or topics.
A SafeCall-branded replacement for the generic ntfy app.
Store distribution as a client installation path, not a standalone product, SKU, self-service sale, or demand-generation channel.
No macOS, Windows, Linux, or web product launch.

The roadmap and GitLab backlog are planning artifacts. They do not authorize a store submission or claim that signing, privacy, push, security, or support gaps are already fixed.

GitLab program

How to use this program

Start with the fixed product model in the adoption strategy. P0 product and governance decisions are approved in the roadmap. Do not reopen the administrator-only, non-standalone relationship while executing later phases. Pick up ready P1, P2, or P3 work items next.
Do not build public claims, legal pages, or release automation around an unresolved delivery architecture, privacy packet, or unverified support contact evidence.
Pick up one actionable GitLab work item. Keep it in exactly one workflow::* state and preserve its stated scope.
Use the strategy for adoption intent and message guardrails. Use the roadmap for rationale and gate criteria. Use GitLab for ownership, dependencies, implementation discussion, and execution state.
Move an item to review only after its measurable acceptance criteria have evidence.
Close a phase only when its exit gate passes or every remaining risk is explicitly accepted with an owner and review date.
Use Publishing Keryx for each release candidate. A successful build alone is not launch approval.

Status rules

workflow::ready — scoped and queued.
workflow::doing — actively owned.
workflow::blocked — waiting on a documented dependency.
workflow::review — acceptance evidence is ready for verification.
Closed work item — verified done.

Every open GTM work item also has gtm, product::keryx, a phase::pN, and a type::* label. priority::launch-blocker is removed only when the issue is closed or its risk is accepted in the roadmap by the launch authority.

Source-of-truth boundary

The adoption strategy records:

the fixed SafeCall companion role and administrator audience;
installed-base and active-prospect adoption plays;
positioning, enablement, message guardrails, and adoption measures;
hypotheses and decisions that do not contain client-sensitive data.

The roadmap records:

product and architecture decisions;
phase dependencies and go/no-go criteria;
the current evidence-based gap status;
accepted and deferred risks;
links to GitLab execution.

GitLab records:

work-item state, ownership, dependencies, and discussion;
implementation acceptance evidence;
follow-up defects and review outcomes.

Store consoles, signing vaults, production ntfy configuration, and client deployment records remain external systems. Their GitLab work items must link to durable evidence without copying secrets into the repository.

Keryx go-to-market ​

Fixed launch scope ​

GitLab program ​

How to use this program ​