Go-live checklist

Technical integration and permission to launch are separate. Passing this checklist proves connectivity and boundary conformance; only written Chia activation permits a live catalog or care handoff.

Production deployment gate: keep production activation blocked while the Partner API, BFF, and Platform releases converge. Their exact signed activation claims intentionally fail closed across mixed versions. Wait for the Lambda update, both ECS services to reach steady state, health checks, and an activation-closed smoke test before an authorized operator activates the approved artifact. Block activation again before any rollback; never roll one component back while production remains active.

Integration definition of done#

• ○The signed release manifest, integration archive, and SDK tarball pass the exact verification in Onboarding.
• ○Sandbox runtime catalog, webhook receiver, and finance run as isolated credential domains; sandbox webhook tests run only as an ephemeral job with the runtime key.
• ○Sandbox catalog refresh uses ETag, honors private max-age, and is never triggered by a user view.
• ○Every image is streamed, length/type/header/digest verified, atomically committed, and served from a random neutral partner-owned path.
• ○The mobile card preserves required block order, complete terms/disclosures, and exact CTA/JIT actions.
• ○hidden, neutral_only, and share_or_neutral behavior has been tested with fresh, stale, unsupported, and missing local state evidence.
• ○After affirmative JIT choice, the backend sends exactly catalog item, disclosure version, and affirmative timestamp with a persisted random UUIDv4; unknown/user/device/contact fields are rejected.
• ○Each created URL has a matching opaque phs_… ID/path, environment-matching livemode, no test field, and a 15-minute expiry; it opens only in the OS browser and is never logged or persisted.
• ○Webhook verification uses exact raw bytes, the five-minute timestamp window, constant-time HMAC comparison, environment matching, and durable event-ID deduplication.
• ○Duplicate delivery and all three test: true shapes produce no catalog, finance, accounting, notification, care, or analytics side effect.
• ○Every V2 webhook requires test: true; even production-signed catalog and settlement shapes commit only a no-side-effect dedupe receipt.
• ○Sandbox finance follows synthetic cursors; production finance traverses immutable releases newest first, persists each release ID once, applies direct supersedes_id links, and never sums a superseded revision.
• ○Errors record only status, code, retryability, and a validated Chia-Request-Id when present; opaque edge failures use a partner-owned correlation ID and UTC time. Logs contain no secrets, raw payloads, identifiers, or handoff URLs.
• ○Separate production runtime, finance, and receiver secrets work only in their roles; the live catalog, co-branded purchase handoff, all three synthetic webhook shapes, and production finance traversal pass.
• ○An authorized low-risk production purchase completes in Chia, Chia is the merchant of record, partner privacy mode remains active, and no patient/order/shipment record or lifecycle callback reaches the partner.
• ○A production synthetic event has both livemode: true and test: true and still produces zero business side effects.

Security and operations#

• ○Credentials are in secret-manager scopes, absent from mobile/browser bundles, source control, CI artifacts, tickets, chat, and email.
• ○Sandbox and production have distinct keys, webhook secrets, receiver URLs, deployments, storage, alerting, and access policies.
• ○Key and signing-secret rotation has been rehearsed, including the current-plus-retiring overlap and retiring-secret removal.
• ○Synthetic webhook receipt deduplication is durable in production storage; the file-backed reference store has been replaced.
• ○Alerting covers catalog expiry/refresh failure, asset-integrity failure, webhook signature/retry failure, credential rejection, and sustained 429/5xx responses without logging sensitive data.
• ○The partner team can immediately hide its catalog mirror, purge assets, disable handoff, revoke credentials, and contact both incident owners.
• ○Accessibility, supported OS-browser behavior, generic return, and offline/degraded catalog UX have been exercised on supported mobile versions.

Provisional performance and reliability guardrails#

These are deployment/IaC alarm guardrails, not an achieved SLA. They become production commitments only after the service is deployed, load/failure/restore tested, and the parties approve the G-11 availability and latency terms.

• ○Catalog and assets are refreshed on a scheduled backend path; a mobile card view makes zero Partner API or authenticated asset calls, while affirmative share makes exactly one bounded idempotent handoff call.
• ○Every HTTP client refuses redirects. 3xx, unexpected origin, and invalid content type fail closed without following Location.
• ○429 handling honors a bounded Retry-After with jitter; network/5xx retries are bounded and cancellable; long delays move to a durable queue.
• ○Public API, asset, and webhook services maintain at least two healthy tasks/instances and use bounded autoscaling with explicit minimum/maximum capacity.
• ○Separate origin-latency alarms fire when p95 exceeds 500 ms or p99 exceeds one second; the hourly authenticated CI canary fails above three seconds and its scheduled-workflow failures reach the named incident channel.
• ○Load, burst, downstream-failure, retry-storm, task-loss, zone-loss, and restore exercises pass without partial catalog publication, duplicate business work, or credential-role collapse.
• ○No dashboard or report labels these provisional targets as an achieved production SLA before representative deployed measurements exist.

Commercial, privacy, and legal gates#

• ○The signed agreement, exact party/MoR matrix, fixed-fee FMV rationale, state matrices, catalog copy, disclosures, retention, and incident duties are current.
• ○Partner support routes medical, checkout, cancellation/refund, prescription, and shipment questions to the named Chia support surface.
• ○The partner's consumer-health notice, rights path, JIT choice, internal access controls, retention, and deletion/consent handling are approved.
• ○Compensation does not vary with views, taps, leads, users, purchases, patients, prescriptions, revenue, shipments, outcomes, or aggregate activity.
• ○Production settlement amounts and paid/due state are Finance-authored immutable releases; optional counts remain nullable and require a recorded minimum group size of at least 10 plus composition approval before release.
• ○No user-level selection, return timing, app-focus signal, or aggregate is joined to infer conversion or care outcomes.
• ○Written Chia legal, privacy, security, clinical, finance, and product approvals are unexpired and bound to the exact release/configuration digest.

Activation sequence#

1. Freeze the certified SDK, contracts, partner receiver URL, care origin, mobile release, and catalog renderer.
2. Re-run sandbox certification and the complete production API/webhook test suite.
3. Confirm the exact production activation receipt, catalog publication, and fixed-fee terms are current.
4. Obtain the signed non-secret onboarding receipt and explicit activation record.
5. Chia activates only the approved publication/audience. The partner observes aggregate technical health, not patient activity.
6. If any approval, copy, origin, endpoint, credential, or operating fact changes, stop acquisition and re-certify before resuming.

Production credentials or successful synthetic events alone do not prove the full purchase flow; the authorized end-to-end production acceptance test does.