Appearance
Authority Doc / Public V1 Integrations
The Integration Register decides which provider and self-hosted boundaries CoachMe may depend on for Public V1.
This page is the Public V1 authority for external providers, operator-controlled application integrations, credentials boundaries, commercial and license constraints, cache and retention limits, failure behavior, launch evidence, and explicit Post-V1 deferrals.
AuthorityMatrix onlyConditional gatesDated evidencePublic V1
Note
This register contains no secret values and assigns no individual or role-based owners. API, event, offline, privacy, environment, toolchain, observability, and release-gate authority remain in their adjacent documents.
Status Model
Provider selection and implementation evidence are related but distinct.
Status model
| Dimension | Status | Authority meaning | Launch effect |
|---|---|---|---|
| Decision | Approved | The selection and governing constraints are accepted. | Launch still requires the row's mandatory evidence to be ready. |
| Decision | Conditional | A preferred selection exists, but a named feasibility, commercial, legal, licensing, regional, or production-service condition is unresolved. | Blocks Public V1 production launch. |
| Decision | Rejected | The option was considered and must not be used under current authority. | Feature work must use an approved alternative or remain out of scope. |
| Decision | Deferred | The integration is outside Public V1 and has a concrete revisit trigger. | Does not block launch because Public V1 uses the registered alternative. |
| Evidence | Open | Required implementation or launch proof has not been supplied. | Blocks launch when the evidence is mandatory. |
| Evidence | Ready | The required proof is current and complete. | Satisfies this row's evidence gate. |
| Evidence | Blocked | Evidence failed or an external condition prevents validation. | Blocks launch. |
Note
Public V1 cannot launch while a required row is conditional or blocked, or while mandatory launch evidence remains open.
Public V1 External Integrations
Each row is authoritative for provider selection, data exposure, limits, persistence, failure behavior, and launch proof.
Public V1 external integrations
| Integration | Selection | Decision | Public V1 use | Data boundary | Configuration | Terms and limits | Cache and retention | Failure behavior | Launch evidence and sources |
|---|---|---|---|---|---|---|---|---|---|
| Google login | Google OIDC through Keycloak identity brokering. | Conditional Production clients and cross-surface flows are not yet proven. | Coach web, coach mobile, and client mobile registration and login. | Google subject, minimal profile, email, email-verification claim, issuer, audience, and authentication timestamps. No Google API scopes beyond identity. | Client ids, client secrets, and redirect URIs live in Keycloak and the deployment secret mechanism. CoachMe stores only provider alias and normalized identity references. | Google OIDC requires registered credentials, exact redirect URIs, state, nonce, HTTPS, and server-side token validation. No paid-plan assumption is approved. | Persist the normalized AuthIdentity and only the minimized claim summary allowed by Privacy And Retention. Do not retain Google access tokens unless a later approved integration requires them. | Hide or mark Google unavailable, preserve existing CoachMe sessions, and offer email/password or another approved provider. Never create an account from an unverified token. | Open Validate production credentials, consent screen, claims, account linking, logout, recovery, and web/iOS/Android redirects. Keycloak broker docs; Google OIDC. Verified 2026-07-10 |
| Apple login | Sign in with Apple through the Keycloak identity-provider boundary. | Conditional Production identifiers, keys, and cross-platform behavior are not yet proven. | Coach web, coach mobile, and client mobile registration and login. | Apple subject, identity token, optional email or private-relay email, verification state, and the limited name payload supplied during initial authorization. | App ids, Services ids, private keys, key ids, team id, and redirect configuration live in Apple configuration, Keycloak, and the deployment secret mechanism. | An Apple Developer account and Sign in with Apple capability are required. Current program, branding, key-rotation, and platform rules must be rechecked before launch. | Persist the normalized AuthIdentity and minimized initial profile. Never depend on Apple returning name or non-relay email after first authorization. | Preserve existing CoachMe sessions; show temporary unavailability and offer email/password or another approved provider. Recovery must support private-relay addresses. | Open Validate capability setup, token verification, private relay, account linking, key rotation, logout, and real web/iOS/Android flows. Apple REST API; Apple capability. Verified 2026-07-10 |
| WhatsApp messaging delivery | WhatsApp Business Platform template messages for invitation-link delivery and phone-verification one-time codes. Explicitly not a login identity provider. | Conditional Template categories, opt-in posture, regional availability, and pricing are unverified. The custom-broker condition no longer applies because authentication is out of scope for this row. | Invitation-link delivery and phone-verification code delivery for coach and client onboarding. Never authentication or account creation on its own. | Phone number, template id, delivery status, provider message id, attempt count, and verification outcome. No health, coaching, nutrition, message, or media data. | Business account ids, app credentials, phone-number ids, template configuration, and webhook secrets stay in the deployment secret mechanism and backend-only configuration. | Template approval per category, opt-in and consent rules, regional availability, per-message pricing, rate limits, and abuse controls require current Meta validation. Invitation links and authentication codes may fall under different template categories. | Retain only the normalized delivery outcome and short-lived redacted diagnostics under the 30-day invitation diagnostics window. Never store code plaintext. | Fall back to manual copy or email delivery; never block invitation creation on channel availability. Phone verification falls back to another approved channel. Never weaken invitation target binding. | Open Verify template categories for invitation links versus authentication codes, opt-in requirements, pricing, UAE/GCC availability, webhook security, replay protection, rate and abuse limits, and delivery receipts. Meta authentication templates; Meta pricing. Verified 2026-07-10 |
| Telegram messaging delivery | Telegram Bot API messages for invitation links and phone-verification codes, deliverable only to users who have already started the CoachMe bot. | Conditional Telegram bots cannot initiate contact and cannot address a phone number, so Telegram cannot deliver a cold invitation. Only post-bot-start delivery is viable, and its Public V1 value is undecided. | Not approved for initial invitation delivery. Candidate only for notification and code delivery after a client has started and linked the CoachMe bot. If adopted, notification delivery is nudge-only and deep-links into the client app's Today surface; the channel never becomes a second action surface. | Telegram chat id, bot message id, delivery status, verification outcome, and — only if the nudge channel is adopted — a privacy-safe templated nudge preview and deep-link target. No health, coaching, nutrition, message, or media data. | Bot token, bot username, allowed updates, and webhook secret stay in BotFather, the deployment secret mechanism, and backend-only configuration. | The Bot API has no send fee, but it requires user-initiated contact, offers no template message to an arbitrary phone number, and carries no approved SLA. Current bot and regional rules must be rechecked. | Retain only the normalized delivery outcome and short-lived redacted diagnostics under the 30-day window. Never store code plaintext. | Fall back to manual copy or email; never block invitation creation. Treat an unlinked Telegram account as channel-unavailable, not as a delivery failure. | Open Confirm the user-initiated-contact constraint against the current Bot API, then decide whether a linked-bot notification and code channel earns Public V1 scope at all. Prove webhook security, replay protection, and rate limits only if adopted. Telegram Bot API. Verified 2026-07-14 |
| Telegram login | Telegram OIDC authorization-code flow with PKCE through Keycloak generic OIDC brokering. | Conditional The official protocol exists, but CoachMe bot/client configuration and phone-scope behavior are not yet proven. | Optional federated coach and client registration and login. Independent of the Telegram messaging-delivery row: this is federated identity, not a message channel. A consented phone claim yields a verified contact, never a phone-based credential. | Telegram subject, minimal profile, requested verified phone-number claim with consent, issuer, audience, and authentication timestamp. | Bot/client id, client secret, allowed origins, redirect URIs, and provider alias live in BotFather, Keycloak, and the deployment secret mechanism. | Telegram documents OIDC, PKCE, native SDKs, and an optional phone scope. There is no approved SLA; current platform, bot, and regional rules must be rechecked. | Persist normalized AuthIdentity and minimized claims. Do not retain Telegram tokens, profile photos, or bot messaging access unless separately approved. | Hide or disable Telegram and offer email/password or another approved provider. Phone consent denial must not be treated as verified-phone login. | Open Validate BotFather configuration, OIDC discovery/JWKS, phone consent and claims, account linking, mobile/browser behavior, logout, and outage handling. Telegram Login. Verified 2026-07-10 |
| Exercise metadata and video | YMove server-side exercise API. | Conditional No commercial plan or written multi-surface content coverage is approved. | Coach web exercise search and program building; coach/client mobile exercise detail and demonstration playback. | Exercise ids, taxonomy, instructions, media availability, usage counters, and API diagnostics. Do not send user health, identity, workout performance, or coach-client data. | API key, plan, base URL, internal quota caps, and usage-reconciliation settings stay in backend-only configuration and the deployment secret mechanism. | Paid plan limits apply. Brand License scope, web plus two mobile apps, normalized catalog sync, metadata retention, video minutes, watermarking, and subscription-end obligations require written confirmation. | Persist only licensed normalized metadata and provider references. Never store signed media URLs; they expire after 48 hours. Do not mirror or download YMove videos for Public V1. | Search uses the local normalized catalog, approved local thumbnails, custom exercises, and placeholders. Video failure returns typed temporary-unavailable or quota-reached behavior without breaking assigned-program snapshots. | Open Approve plan and Brand coverage, confirm sync rights, set internal caps, provision credentials, test /usage reconciliation, quota failure, 48-hour URL refresh, and outage fallback.YMove pricing; YMove docs; YMove terms. Verified 2026-07-10 |
| Exercise thumbnails | yuhonas/free-exercise-db imported into CoachMe-controlled object storage. | Approved | Search results and compact exercise cards where a reviewed YMove-to-local mapping exists. | Public exercise metadata, source image paths, checksums, import version, license provenance, and reviewed mapping status. No user data crosses this boundary. | No runtime credential. Import tooling pins a source commit and stores provenance in backend configuration or the import manifest. | Public-domain/Unlicense source. The exact imported commit, files, checksums, and any third-party asset provenance must be recorded before use. | CoachMe may store imported assets in controlled object storage. Do not imply that automated dataset matches are reviewed or provider-authored. | Use a CoachMe-owned muscle/equipment placeholder when an asset is missing, rejected, or unmapped. Exercise search remains usable. | Open Pin the exact source commit, retain the license text and import manifest, verify checksums, review mappings, and test placeholder fallback. Source repository; Unlicense text. Verified 2026-07-10 |
| Mobile push delivery | Expo Push Service with APNs and FCM as downstream platform services. | Approved | Coach mobile and client mobile reminders, messages, tasks, review signals, and privacy-safe deep links. | Expo push token, app surface, platform, privacy-safe payload, provider ticket and receipt ids, and normalized delivery errors. No sensitive message body, signed URL, health detail, or raw provider token in logs. | Expo project configuration and APNs/FCM credentials live in EAS/Expo and the deployment secret mechanism. Encrypted push tokens stay server-side. | Expo states no send fee, a 600-notification/second/project limit, 100-message send batches, 1000-receipt request batches, and best-effort at-least-once handoff to APNs/FCM. | CoachMe retains normalized tickets and receipts for the diagnostics window. Expo states contents are held transiently in memory/queues; keep notification previews privacy-minimal. | Throttle and retry transient errors, revoke invalid tokens, preserve in-app inbox/tasks, and never claim device delivery from an Expo handoff receipt. | Open Provision both apps, test physical iOS/Android devices, permissions, token rotation, batches, receipts, invalid tokens, throttling, quiet hours, localization, and deep links. Expo FAQ; Expo sending guide. Verified 2026-07-10 |
| Grafana Cloud observability | One conditional Grafana Cloud stack for staging and production, fed through Grafana Alloy. | Conditional Plan, region, processing, retention, quota, access, and production evidence are unresolved. | Minimized backend logs, aggregate metrics, two operational dashboards, email alerts, HTTP synthetics, and TLS checks. No Launch traces. | Allow-listed Pino fields, bounded OTel metrics, synthetic outcomes, release/service/environment attributes, and approved diagnostic ids. No raw payloads or user content. | Environment-filtered queries, separate staging/production write credentials, scoped ingestion tokens, and named least-privilege admin access. | Current plan, region, quotas, authentication, roles, activity logs, processing terms, and 30-day objective support require verification. | Identifiable/minimized and synthetic-log evidence cannot exceed 30 days. Strict aggregates cannot exceed 13 months. Actual provider windows remain Open evidence. | Export failure never blocks accepted requests or jobs. Local stdout remains; independent synthetics detect internal telemetry loss. | Open Verify plan, region, processing, quotas, retention, MFA/RBAC/activity logs, environment isolation, outage behavior, credentials, dashboards, alerts, and synthetics. Grafana Cloud OTLP; Synthetic Monitoring. Verified 2026-07-13 |
| Sentry error and crash reporting | Sentry SaaS with separate projects for backend API/workers, coach web, coach mobile, and client mobile. | Conditional Region, processing, retention, scrubbing, quota, access, and production evidence are unresolved. | Backend exceptions plus web/mobile errors, crashes, releases, and source maps. No logs, tracing, replay, screenshots, attachments, or profiling at Launch. | Scrubbed stack/error context, service/surface, registered release/build, environment, bounded operation/outcome, and Roles-approved diagnostic ids. No authenticated session id or user content. | Environment/release tagging, project-scoped DSNs, CI-only source-map upload tokens, server-side scrubbing, and named least-privilege admin access. | Current region, processing terms, quotas, MFA/roles/activity logging, source-artifact handling, and SDK/framework compatibility require verification. | Sentry events and approved diagnostic identifiers cannot exceed 30 days. Source artifact handling and actual project windows remain Open evidence. | SDK/provider failure never blocks accepted product work. Grafana monitors operational availability separately. | Open Verify region, processing, scrubbing, quotas, retention, access/activity logs, outage behavior, and staging symbolication for API, worker, web, coach mobile, and client mobile. Sentry Next.js; Sentry Expo; Expo Sentry guide. Verified 2026-07-13 |
| Messaging GIF search | GIPHY API using separate approved client configuration per app surface. | Approved | GIF search and selection in coach web, coach mobile, and client mobile messaging. | Search query, locale, rating, pseudonymous GIPHY customer id where required, selected asset id, rendition keys, attribution, and analytics fields. No CoachMe message history or health profile is sent. | Surface-specific public API keys and safe-search settings come from the CoachMe config endpoint. Production approval records remain in deployment configuration; no secret key is embedded. | Powered by GIPHY attribution is mandatory. Beta keys are limited to 100 calls/hour; higher traffic requires production approval and pricing discussion. Default maximum content rating is pg, with workspace policy allowed to tighten to g. | Do not build a GIF database, commingle provider search, proxy, rewrite, ingest, or persist GIF binaries. Store only selected message metadata and attribution required to render history. | Hide the GIF picker and keep text, attachments, and voice notes available. A selected queued GIF may send only if its provider payload still passes validation. | Open Obtain separate keys, complete production approval, validate pricing/limits, attribution, rating, Arabic search, analytics, payload validation, and provider-unavailable behavior. GIPHY API docs; GIPHY API terms; Beta key limits. Verified 2026-07-10 |
Public V1 Self-Hosted Integrations
These components remain integration boundaries because licenses, security updates, resource limits, and failure modes affect application behavior.
Public V1 self-hosted integrations
| Integration | Selection | Decision | Public V1 use | Data boundary | Configuration | Terms and limits | Cache and retention | Failure behavior | Launch evidence and sources |
|---|---|---|---|---|---|---|---|---|---|
| Identity and federation boundary | Self-hosted Keycloak. | Approved | Email/password, external identity brokering, sessions, token issuance, account linking, and realm identity configuration for all surfaces. | Credentials, password hashes, identity links, sessions, tokens, verification state, and minimized provider claims. CoachMe business roles and relationships stay in PostgreSQL. | Realm exports, clients, providers, redirect URIs, signing keys, SMTP/transactional identity settings, and admin credentials use environment configuration and the deployment secret mechanism. | Apache License 2.0 community project. No community SLA is assumed; supported version, patch cadence, and optional commercial support are deployment decisions. | Retain identity/session data according to Keycloak operation and Privacy And Retention. Backups must align with CoachMe account deletion, recovery, and audit requirements. | Fail authentication closed, preserve already validated application sessions only within policy, expose dependency health, and use the Environment Runbook for restore and rollback. | Open Pin a supported version, prove realm import/export, key rotation, backups, restore, email/password, federation, session revocation, health checks, and upgrades. Keycloak admin guide; Keycloak source/license. Verified 2026-07-10 |
| Local object storage | MinIO through the S3-compatible application port, for local development only. | Approved | Local developer uploads, signed access, bucket bootstrap, media processing, and metadata/byte integration tests with sample data. | Non-production sample media and documents only. No production or copied user data may enter the local service. | Safe sample root credentials, local endpoint, region, and bucket names live in local environment configuration; required buckets are created by an explicit bootstrap command. | The current repository/distribution and MinIO license posture require explicit review. Approval is local-only and does not grant staging or production use. | Disposable local buckets follow developer reset/seed behavior. Do not treat local objects as backups or durable evidence. | Fail local storage health and upload tests visibly. Never fall back from local development to a shared staging or production bucket. | Open Pin a reviewed local source/container build, record license obligations, prove bucket bootstrap, signed access, cleanup, and health behavior. MinIO source; MinIO license. Verified 2026-07-10 |
| Staging and production object storage | S3-compatible service selected and approved before production data exists. | Conditional No production service or region is selected. | Private progress photos, messages, voice notes, attachments, exercise assets, thumbnails, previews, and other application media. | Identity-linked, health-adjacent, and communication media plus internal object keys, checksums, renditions, and lifecycle state. | Service endpoint, region, bucket policy, credentials, encryption keys, lifecycle rules, signed-URL limits, and webhook/event settings stay in the deployment secret mechanism and backend configuration. | Provider pricing, storage/egress limits, data region, encryption, processor terms, deletion, backups, support, and SLA are unresolved. | Private objects use explicit lifecycle/purge rules from Privacy And Retention. PostgreSQL owns metadata and permissions; storage owns bytes. | Reject new uploads when safety cannot be proven, preserve authorized access to existing objects where possible, queue replay-safe cleanup, and use backup/restore procedures for metadata/byte consistency. | Blocked Select the service and region, complete legal/privacy review, provision least-privilege credentials, and prove signed access, encryption, lifecycle, purge, backup, restore, pricing, quotas, and outage behavior before production data exists. |
| Malware scanning | Self-hosted ClamAV worker integration. | Approved | Scan uploaded communication files, media, documents, and other supported attachment bytes before they become ready. | Untrusted file bytes and minimal job metadata stay inside the operator-controlled worker boundary. Filenames and user context are not required by the scanner. | Daemon/socket endpoint, signature update source, timeouts, size limits, and worker resources live in backend/environment configuration. | GPLv2 project; signature freshness, supported versions, container provenance, CPU/memory limits, and update availability are operational constraints. | Retain normalized scan result and engine/signature version; do not retain duplicate scan copies after the source object follows its lifecycle. | Fail closed for unsupported, unsafe, timed-out, or unavailable scans. Quarantine or reject the asset; never mark it ready because scanning failed. | Open Pin image/version, automate signatures, test known-safe and approved test-malware fixtures, timeouts, size/resource limits, queue isolation, and fail-closed behavior. ClamAV source; ClamAV docs. Verified 2026-07-10 |
| Image processing | Sharp with libvips in a self-hosted media worker. | Approved | MIME-confirmed image normalization, EXIF stripping, thumbnails, previews, dimensions, and policy-safe renditions. | Private image bytes, detected metadata, dimensions, checksums, and derivative object keys remain inside CoachMe-controlled workers and storage. | Accepted formats, pixel/byte limits, timeouts, concurrency, output profiles, and worker resources live in backend/environment configuration. | Record Sharp and libvips licenses and binary provenance. Native dependency versions, decoder vulnerabilities, decompression bombs, memory, and CPU are operational limits. | Keep required canonical/derived objects under the owning feature lifecycle. Strip EXIF and do not persist transient processing files beyond job cleanup. | Reject unsupported or policy-violating images; retry bounded transient worker failures; keep the canonical asset non-ready until required safe derivatives exist. | Open Pin versions, verify licenses, test MIME spoofing, EXIF removal, dimensions, decompression/resource limits, deterministic derivatives, cleanup, and vulnerable-decoder updates. Sharp docs; Sharp source; libvips source. Verified 2026-07-10 |
| Audio/video processing | FFmpeg/ffprobe in a self-hosted media worker. | Approved | Audio/video metadata, duration and codec validation, voice-note checks, poster frames, and approved renditions. | Private voice/video bytes, technical metadata, duration, codec, dimensions, waveform/poster metadata, and derivative object keys stay inside controlled workers/storage. | Approved build flags/codecs, accepted formats, duration/size limits, timeouts, concurrency, and sandbox/resource limits live in worker build and environment configuration. | FFmpeg is LGPL 2.1+ by default, but GPL or nonfree components can change obligations. The exact build configuration and notices must be approved and recorded. | Keep only canonical/approved derivatives under feature retention. Remove transient processing files and never log raw media or signed URLs. | Reject unsupported or policy-violating media; retry bounded transient failures; keep the asset non-ready until required validation and derivatives succeed. | Open Pin build/version and configure flags, complete license review, test corrupt media, duration/codec limits, poster frames, sandbox/resource limits, cleanup, and security updates. FFmpeg legal guidance. Verified 2026-07-10 |
| Grafana Alloy collector | Grafana Alloy as the Docker-managed collector for approved backend logs, application/runtime metrics, and collector self-signals. | Approved Use the Environment-owned protected restricted Docker API proxy; deployment proof remains launch evidence. | Collect Pino stdout, OTel application metrics, approved runtime/container metrics, heartbeat, exporter failures, and drops. No client OTel or Launch traces. | Allow-listed backend log fields and bounded metrics remain inside the operator-controlled collector before export. No raw product payloads. | Protected restricted Docker API proxy; no direct Docker socket mount; non-root where supported, dropped capabilities, read-only filesystem, bounded memory, no public ports, and scoped write-only credentials. | Pin the collector image/version, validate configuration, review security updates, and verify Docker/environment compatibility. | No durable product store. Local buffers, if enabled, are bounded by Environment and cannot exceed the applicable Privacy class. | Exporter failure is observable degradation and never blocks accepted requests/jobs. Restart with bounded resources; preserve local stdout. | Open Approve and test host access, privileges, ports, limits, credentials, config validation, heartbeat, export failure, and recreated-container behavior. Alloy Docker monitoring; Alloy access permissions. Verified 2026-07-13 |
| PDF preview | One engine selected from Poppler or PDFium after review. | Conditional The engine is not selected. | Page count, safe first-page previews, and supported-document validation for form and communication attachments. | Private PDF bytes, page count, detected properties, preview images, and derivative object keys stay inside controlled workers/storage. | Selected engine/version, accepted PDF features, page/byte limits, timeouts, sandbox, and worker resources live in the media-worker build and environment configuration. | Poppler and PDFium have different license, patching, packaging, and rendering tradeoffs. The selected distribution and notices must be approved. | Keep the canonical PDF and approved preview under feature retention; remove transient render files and reject active/unsupported content. | Do not render unsafe or unsupported PDFs. Retry bounded transient failures; allow download only when owning feature policy permits, even if preview generation failed. | Blocked Compare license, security patching, container packaging, preview quality, supported formats, resource limits, and malicious-PDF handling; select and pin one engine. Poppler license; PDFium license. Verified 2026-07-10 |
Deferred Integrations
These capabilities are not Public V1 dependencies. Each row records the current alternative and the only trigger that permits reconsideration.
Deferred integrations
| Integration area | Status | Public V1 alternative | Deferral reason | Revisit trigger |
|---|---|---|---|---|
| Phone number as a login credential (one-time code over SMS, WhatsApp, or Telegram) | Deferred | Email/password, Google, and Apple registration and login, with Telegram OIDC as a conditional federated option. Phone numbers are verified contacts, never credentials. | The delivery channel is not the cost driver: stock Keycloak offers TOTP/HOTP only, so phone-plus-code login requires a custom Keycloak authenticator plus its own security design for rate limiting, replay, account enumeration, SIM-swap, and toll/pumping fraud. Choosing SMS instead of WhatsApp does not avoid any of that work. | An approved phone-first login requirement, together with a completed authenticator security design and channel abuse controls. Adding it is additive: the code-delivery channels and verified-contact records already exist for phone verification. |
| Comprehensive food database, provider search, and barcode scanning | Deferred | Coach-authored/workspace foods with immutable nutrition snapshots. | Regional coverage, Arabic data quality, licensing, cost, privacy, and snapshot behavior require a separate decision. | Approved nutrition expansion with measured search/barcode demand and a provider evaluation covering UAE/GCC data and licensing. |
| Payments, subscriptions, invoicing, and receipts | Deferred | No in-product billing or payment processing in Public V1. | Commercial model, tax, currency, store rules, refunds, and regulated payment scope are outside the coaching-loop launch. | An approved monetization scope and payment/legal architecture. |
| Wearables and companion watches | Deferred | CoachMe-owned manual workout, progress, nutrition, and daily logging. | Device coverage, health permissions, sync semantics, data accuracy, and support load exceed Public V1 scope. | Measured demand plus a prioritized device/platform data contract and privacy review. |
| Outbound email integration beyond identity-system transactional needs | Deferred | In-app messaging, push notifications, and minimal identity/invitation transactional delivery. | Campaign, lifecycle, consent, deliverability, suppression, and analytics behavior are not required for the core loop. | An approved lifecycle or transactional-email requirement with consent and deliverability policy. |
| Calendar integration | Deferred | CoachMe Today tasks, schedules, reminders, and in-app dates. | Two-way sync, recurring events, time zones, permissions, and conflicts are outside Public V1. | An approved scheduling use case that cannot be met by CoachMe-owned tasks and reminders. |
| Zoom or other video-call integration | Deferred | In-app messaging, attachments, capped voice notes, and out-of-band live-session arrangements. | Live sessions, recording, consent, scheduling, reliability, and regional provider terms are outside Public V1. | An approved live-coaching scope with recording/consent and scheduling policy. |
| User-facing cloud-storage integration | Deferred | CoachMe-controlled private object storage and platform file/photo pickers. | Third-party account linking, permissions, imports, exports, duplicates, and revocation are outside Public V1. | Measured import/export demand that cannot be met by platform pickers and CoachMe exports. |
| Direct CoachMe APNs/FCM delivery adapter | Deferred | Expo Push Service with provider-neutral tickets, receipts, and native-token metadata. | Direct routing adds credentials, platform-specific delivery code, receipt handling, and operational burden without a proven launch need. | Expo throughput, reliability, compliance, cost, feature, or support constraints that materially block CoachMe requirements. |
Integration Boundary Rules
Every registered row follows these application-wide rules.
Integration boundary rules
| Boundary | Authority rule |
|---|---|
| Client access | Coach web and mobile clients use CoachMe contracts. Direct provider access is allowed only where a row explicitly approves it, such as Keycloak redirects, Expo token acquisition, or GIPHY client search. |
| Provider adapters | Backend adapters normalize provider payloads and errors before domain code consumes them. Feature code must not branch on raw provider payloads. |
| Credentials | Secret values stay in Keycloak, the deployment secret mechanism, or approved backend-only configuration. This register stores only the boundary and required rotation evidence. |
| Provider administration | Use named accounts, MFA, least privilege, activity logging, and separate ingestion versus administration credentials. A telemetry identifier is not an access grant. |
| Webhooks and receipts | Authenticate or verify signatures where supported, enforce replay protection and idempotency, redact raw payloads, and normalize accepted results before emitting internal events. |
| Events | Normalized provider activity follows the Event And Outbox Standard. Provider-specific payloads do not become domain-event contracts. |
| Caching | Provider data, URLs, and media may be cached, mirrored, or proxied only where the provider row explicitly permits it. |
| Privacy and retention | Every data path follows Privacy And Retention. Provider terms cannot expand CoachMe's approved use of identity, communication, or health-adjacent data. |
| Offline behavior | Mobile queues submit CoachMe operations; the server performs permitted provider work and returns normalized receipts or typed failures. Provider calls are not hidden inside mobile replay. |
| Failure categories | Use stable CoachMe errors and one registered outcome: cached/snapshotted continuation, bounded retry, temporary unavailability, optional-feature disablement, alternate approved provider, or fail-closed security block. |
Launch Evidence
These evidence families define what each Public V1 row must prove before production launch.
Launch evidence
| Integration family | Required evidence |
|---|---|
| Authentication | Staging and production configuration; claim normalization; account linking; logout and recovery; invalid claims; outage behavior; and real web/iOS/Android flows where applicable. |
| Exercise content | Schema drift; local catalog fallback; license/import provenance; plan and Brand coverage; quota guard; usage reconciliation; expiring media; and outage behavior. |
| Push | Both Expo apps on physical APNs and FCM devices; permission changes; token rotation; tickets and receipts; invalid tokens; throttling; quiet hours; localized previews; and deep links. |
| GIPHY | Separate approved keys; production approval; pricing/limits; safe-search rating; attribution; Arabic search; analytics; unsupported payload rejection; and unavailable-provider fallback. |
| Storage and media | Signed access; encryption; MIME spoofing; malware rejection; resource and size limits; deterministic derivatives; object purge; metadata/byte restore consistency; licensing; and worker failure. |
| Observability providers and collector | Provider/collector approval; region and processing; Privacy-compatible retention; quotas; MFA/RBAC/activity logging; protected Alloy access; separate environment credentials; outage isolation; five-surface symbolication; dashboards, alerts, and synthetics. |
| All required rows | Official source and verification date; credential rotation proof; privacy/data review; rate/limit behavior; typed degradation behavior; and provider-outage evidence. |
Source and verification policy
| Source rule | Requirement |
|---|---|
| Primary sources | Use official provider documentation, official pricing/terms, and original project license sources. |
| Dated facts | Put Verified YYYY-MM-DD beside time-sensitive commercial, protocol, limit, region, retention, distribution, or license facts. |
| Concise authority | State the CoachMe decision and material constraint; link instead of copying long pricing or terms tables. |
| Unverified facts | Keep the decision conditional or evidence blocked. Never promote remembered values or unofficial comparisons into authority. |
| Secrets | Never publish secret values, example tokens, private keys, OTP values, or raw credential payloads. |
Change Control
These triggers require an explicit register review.
Change control
| Trigger | Required action |
|---|---|
| Pricing or quota change | Recalculate Public V1 usage assumptions and update the decision and launch evidence. |
| Terms, license, attribution, or cache-policy change | Re-review stored data, media handling, attribution, notices, and continued legality. |
| API, SDK, schema, or authentication change | Re-run adapter contracts, schema-drift checks, and affected web/mobile flows. |
| Data-region, processor, or retention change | Re-review privacy, transfer, deletion, and provider-retention posture. |
| Security advisory or unsupported version | Patch, isolate, replace, or block the integration; refresh evidence before release. |
| Provider degradation, deprecation, or shutdown | Apply the registered fallback and reconsider provider selection. |
| New product surface or market | Recheck availability, terms, credentials, localization, verification behavior, and data region. |
| New integration proposal | Add a conditional or deferred row before feature implementation depends on it. |
Related Docs
These documents own adjacent rules that this register references without redefining.
Related documents
| Document | Adjacent authority |
|---|---|
| Workflow State Map | Cross-system lifecycle states and transitions. |
| Roles And Permissions | Backend authority, support/admin access, and cache boundaries. |
| Privacy And Retention | Data classification, processors, consent, retention, export, deletion, and transfer posture. |
| API Contract Standard | CoachMe request/response DTOs, errors, compatibility, and generated clients. |
| Event And Outbox Standard | Normalized integration events, retries, idempotency, and dead letters. |
| Offline Sync Protocol | Mobile operation queues, receipts, replay, conflicts, and cache pruning. |
| Environment Runbook | Environment topology, secrets, storage, deployment, backup, restore, and rollback. |
| Toolchain Contract | Dependency, build, configuration-validation, and update tooling. |
| Observability Plan | Signal contracts, provider-health use, dashboards, alerts, diagnostics, and operational incident detection; provider approval remains here. |
| Test And Release Gate | Execution frequency, automation, release evidence, and final approvals. |
| Technical Architecture Plan | System decomposition and provider-adapter architecture. |
| Public V1 Scope Contract | Required launch scope and explicit Post-V1 boundaries. |