# SCRIMED Launch Readiness Brief

Status: launch-readiness-control-plane-active
Posture: strict-primary-domain-launch-gate-with-contained-sandbox-dns-workaround
Primary domain: https://app.scrimedsolutions.com
Fallback domain: https://scrimed-site.vercel.app
Launch tracks: 10
Ready tracks: 3
Contained tracks: 3
Operator-required tracks: 1
External-review tracks: 3
DNS controls: 3
Service paths: 5
Risks: 5
Critical risks: 1
High risks: 3
Proof routes: 40
Hard stops: 10

## Boundary
SCRIMED Launch Readiness organizes launch structure, product readiness, service readiness, functional verification, DNS/domain checks, sandbox limitations, and workarounds into one go/no-go control plane. It is operating-readiness evidence only. It does not bypass sandbox restrictions, override DNS, approve production clinical use, authorize PHI processing, certify security or compliance, create a contractual SLA, approve production connectors, approve customer release, provide legal/accounting/tax advice, guarantee revenue or profit, or replace qualified human launch review.

Fallback success is continuity evidence only. Launch approval still requires the branded domain to resolve and pass production smoke from an unrestricted or approved network. This brief does not bypass sandbox restrictions, override DNS, approve PHI processing, authorize live clinical care, certify security or compliance, create a contractual SLA, approve production connectors, approve customer release, or replace qualified human launch review.

## DNS And Sandbox Controls
- Sandbox DNS classifier (fallback-contained): Restricted Codex sandbox execution can return getaddrinfo ENOTFOUND for app.scrimedsolutions.com even when the production app is reachable from an approved network. Command: SCRIMED_PRIMARY_BASE_URL=https://app.scrimedsolutions.com SCRIMED_FALLBACK_BASE_URL=https://scrimed-site.vercel.app npm run smoke:launch-domain-preflight Launch rule: Fallback success is not sufficient for launch approval; unrestricted primary-domain smoke is still required. Workaround: Request approved network execution for production smoke, run the fallback preflight for continuity evidence, and keep the branded domain as the buyer-facing target.
- Strict production smoke (strict-primary-required): A green local build does not prove the branded production app, headers, routes, protected fail-closed checks, and public pages are reachable. Command: SCRIMED_BASE_URL=https://app.scrimedsolutions.com SCRIMED_WORKSPACE_SLUG=atlas-synthetic-evaluation npm run smoke:public Launch rule: Required before external launch, buyer campaign activation, investor demo packet distribution, or board-readiness claim. Workaround: If sandbox DNS blocks this command, rerun with approved network access and attach the preflight classification to the launch note.
- Domain ownership and route fallback (operator-required): Custom-domain routing, SSL, Vercel aliasing, and Wix CTA routing are external systems and can drift independently of source code. Command: curl -L --max-time 20 -s -I https://app.scrimedsolutions.com/api/launch-readiness Launch rule: Buyer-facing launch material should use the branded domain only after this verification is current. Workaround: Use direct Vercel deployment URLs or authenticated share links for internal review while branded DNS or CTA routing is repaired.

## Launch Tracks
- Custom domain and DNS preflight (contained): Can operators distinguish a restricted sandbox DNS failure from a real production-domain outage? Control: Run strict production smoke against the branded domain when network DNS is available, and run the launch domain preflight to classify DNS, HTTP, and fallback deployment posture. Gate: Primary branded domain must resolve and pass smoke from an unrestricted network before public launch approval. Workaround: When the managed sandbox returns ENOTFOUND, rerun production smoke with approved network access and use the fallback Vercel alias only as supporting evidence, not as launch approval. Hard stop: Do not mark launch green from fallback-only proof when the branded domain cannot be verified.
- Source, build, and route inventory (ready): Does the deployed product match the source and expose navigable launch-critical routes? Control: Keep build, typecheck, route inventory, API route pattern count, persistent navigation, and smoke-covered HTML routes aligned before promotion. Gate: Typecheck, lint, build, navigation inventory, public smoke, and route counts must agree before external promotion. Workaround: If one dynamic detail route cannot be smoked, keep the canonical route smoke-covered and rely on build/typecheck for the dynamic segment until it becomes buyer-critical. Hard stop: Do not launch with missing primary navigation, stale route counts, or broken canonical buyer paths.
- Product and offer packaging (ready): Can a buyer understand what SCRIMED sells without internal explanation? Control: Use the Product Console, Offerings Portfolio, demos, pilots, pricing, and proof stack as the first buyer-facing product path. Gate: Every launch conversation has a sellable package, scope boundary, proof route, and next buyer action. Workaround: Use assessment or synthetic pilot packages when production connectors, PHI, customer proof, or live-care authority are not approved. Hard stop: Do not sell live clinical execution, EHR writeback, payer submission, or autonomous patient outreach.
- Service delivery and onboarding (ready): Can SCRIMED handle demos, pilots, meetings, handoffs, and follow-up without ad hoc process? Control: Route client onboarding through human-reviewed emails, calendar-ready agendas, demo scripts, pilot workshops, follow-up SLAs, and handoff controls. Gate: Each opportunity has owner, stage, communication packet, proof routes, scope, retained boundary, and next meeting artifact. Workaround: Use manual human-send communications and no-PHI meeting packets until email/calendar automation and CRM sync are approved. Hard stop: Do not auto-send emails, create calendar invites, bind contracts, store PHI, or promise procurement approval.
- Enterprise operations and margin control (external-review-required): Can SCRIMED scale revenue operations without letting contracts, margin, tax, or accounting risk drift? Control: Run every serious opportunity through deal desk, price floor, margin review, legal/accounting/tax routing, billing readiness, and blocked-claim checks. Gate: No enterprise proposal expands beyond approved package, price floor, review owner, contract posture, and margin exposure. Workaround: Use non-binding readiness packets and qualified-review labels until counsel, accounting, tax, and finance reviewers approve templates. Hard stop: Do not imply audited financials, legal approval, tax advice, revenue guarantee, profit guarantee, securities material, or contract approval.
- Scale, support, and reliability posture (contained): Can SCRIMED discuss enterprise scale without accidentally promising an SLA or managed service? Control: Use scale domains, service reliability controls, incident/change operations, support-tier review, cost thresholds, and regional gates before commitments expand. Gate: Support, uptime, SLO, region, residency, DR, and cost commitments must be contract-reviewed before buyer use. Workaround: Offer launch-window support plans and review cadences as readiness language, not contractual SLA language. Hard stop: Do not claim 24/7 production support, SOC/MDR coverage, uptime guarantee, or data-residency approval.
- Healthcare data, interoperability, and patient safety (external-review-required): Can SCRIMED show strong health-record capability while keeping live-data and clinical authority blocked? Control: Keep health records, interoperability, extraction, patient-safety lint, and clinical activation on synthetic/no-PHI tracks until buyer-specific authority exists. Gate: Live PHI, EHR/HIE/payer connectors, matching, writeback, patient outreach, payer submission, or clinical action require explicit buyer, legal, privacy, security, and clinical approval. Workaround: Use no-PHI synthetic extraction, metadata-only artifact references, standards mapping, and external evidence pointers. Hard stop: Do not process PHI, diagnose, triage emergencies, prescribe, mutate records, submit claims, or represent clinical validation.
- Approvals, certifications, and global launch readiness (external-review-required): Can domestic and global launch claims stay prepared without claiming approval? Control: Route HIPAA/BAA, SOC 2, HITRUST, ISO, FDA, ONC, EU AI Act, GDPR, NHS, MHRA, Australia, public-sector, and region-specific questions through evidence tracks. Gate: External certification, conformity, regulatory, legal, privacy, procurement, and security claims must cite qualified evidence before use. Workaround: Use preparation packets, official-source checklists, and external-review-required headers until formal approvals exist. Hard stop: Do not claim HIPAA certification, SOC 2/HITRUST/ISO certification, FDA clearance, ONC certification, GDPR assurance, EU AI Act conformity, NHS/MHRA/Australia approval, or public-sector procurement approval.
- AI, API, UI, agents, and continuous review (contained): Can the platform feel enterprise-grade while keeping live AI authority and autonomous remediation blocked? Control: Keep API contracts, UI command paths, model-route controls, agent approval, eval/red-team loops, evidence retrieval, review agents, and incident learning wired into launch proof. Gate: Launch messaging must show agent-assisted review and AI readiness while preserving human approval, no-PHI, no-live-AI, and no-public-quantum boundaries. Workaround: Assign speculative technology such as quantum-safe readiness to internal research with no public capability claim. Hard stop: Do not claim live autonomous AI authority, production model approval, public API SLA, trillion-scale equivalence, security certification, or public quantum capability.
- Protected proof and customer release (operator-required): Can SCRIMED prove diligence value without exposing protected artifacts or customer-specific claims? Control: Keep protected buyer proof, release decisions, reviewer signoffs, distribution lockbox, recipient attestations, access logs, provider adapters, procurement evidence, and AAL2 proof fail-closed publicly. Gate: Customer-specific proof must have permission, reviewer signoff, recipient scope, release authority, and access-log reconciliation before external sharing. Workaround: Use public proof routes, synthetic evidence, and metadata-only protected summaries until customer release is approved. Hard stop: Do not share named customer proof, confidential buyer artifacts, protected packets, or authenticated evidence without retained approval chain.

## Service Paths
- Public buyer entry: Owner: Founder + Product Console. Proof: Homepage, Product Console, Offerings, Demos, Pilots, Pricing, and Pilot intake load from branded domain.. Customer output: Clear buyer path from interest to product proof and pilot request.. Fallback: Share direct product, demo, pricing, and pilot URLs if Wix CTA routing is delayed.
- Guided demo and pilot scoping: Owner: Sales Engineering + Customer Operations. Proof: Client Onboarding packets, demo scripts, meeting agendas, pilot workshop notes, and follow-up controls are ready.. Customer output: Professional demo, pilot scope, presentation, and next-step artifacts.. Fallback: Manual email/calendar send using approved no-PHI packets.
- Protected diligence and evidence: Owner: Buyer Diligence + TrustOps. Proof: Protected workspace fail-closed publicly; AAL2 operator run produces no-secret retained proof when approved.. Customer output: Controlled diligence packet or public proof map, depending on release authority.. Fallback: Public proof routes and synthetic evidence summaries until protected release gates pass.
- Enterprise proposal and contract review: Owner: Legal Ops + Finance + Revenue Operations. Proof: Enterprise Business Ops, price floors, margin controls, blocked claims, and qualified-review owners are attached.. Customer output: Scope, proof, assumptions, price logic, retained boundaries, and review path.. Fallback: Readiness-only proposal packet and review calendar before formal contracting.
- Clinical and global expansion readiness: Owner: Clinical Governance + Regional Counsel + Security. Proof: Approvals, Global Certification, Clinical Authority, Health Records, and Interoperability gates are visible.. Customer output: Region, approval, privacy, security, data, and clinical-authority plan.. Fallback: Synthetic, metadata-only, and external-reference evidence lanes until local approvals exist.

## Launch Risks
- Sandbox DNS false negative blocks confidence even when production is healthy. (high): Owner: Release Steward. Containment: Classify DNS lookup failure separately from application failure and require unrestricted-network smoke before launch approval.. Gate: Primary branded domain resolves and public smoke passes from approved network.
- Fallback deployment URL could be mistaken for buyer-ready launch proof. (high): Owner: Product Console + Domain Administrator. Containment: Label fallback as continuity-only and keep branded-domain proof as the go/no-go requirement.. Gate: Domain, SSL, Vercel alias, Wix CTA, and launch-readiness API headers verified.
- Launch breadth overwhelms first-time buyers or investors. (medium): Owner: Founder + Revenue Operations. Containment: Route audiences into Product, Offerings, Client Onboarding, Investor Readiness, or Pilot Deal Room instead of exposing the full route map first.. Gate: Each launch audience has one packet, one proof ladder, one owner, and one next action.
- Product claims outrun approvals, certifications, or healthcare authority. (critical): Owner: TrustOS + Claim Guard + Qualified Reviewers. Containment: Keep no-authority headers, blocked claims, Claim Guard, approval tracks, and clinical/global gates visible in every launch-critical lane.. Gate: External evidence and qualified reviewer signoff exist for any expanded claim.
- Service delivery grows faster than support, margin, or governance. (high): Owner: Customer Operations + Finance + Legal Ops. Containment: Tie every demo, pilot, assessment, and proposal to onboarding controls, price floors, support posture, and margin review.. Gate: Repeatable onboarding, support, billing, contract, and margin processes are approved for the target segment.

## Next Launch Move
Use Launch Readiness before any public campaign, buyer demo day, investor packet release, or broader app launch: run build/typecheck/lint, run strict branded-domain public smoke from a network with DNS, run launch-domain preflight to classify sandbox ENOTFOUND separately, keep fallback evidence continuity-only, verify no-authority headers, keep protected AAL2 happy-path proof operator-only, and route unresolved legal, finance, clinical, security, certification, PHI, connector, SLA, customer-release, revenue, and profit claims through qualified review.

Updated: 2026-06-26