SCRIMED now separates sandbox DNS limits from real launch go/no-go proof.

Sandbox DNS classifier

• Detection: The launch domain preflight first resolves the primary host, then requests health endpoints, then tests a fallback Vercel alias when the sandbox cannot resolve DNS.
• Command: SCRIMED_PRIMARY_BASE_URL=https://app.scrimedsolutions.com SCRIMED_FALLBACK_BASE_URL=https://scrimed-site.vercel.app npm run smoke:launch-domain-preflight
• Pass condition: Primary domain resolves and returns SCRIMED health/readiness, or sandbox DNS failure is explicitly classified while fallback health/readiness passes for internal continuity.
• 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.
• This does not bypass DNS, alter external records, or convert fallback-only evidence into launch approval.

Strict production smoke

• Detection: Run the public production smoke against https://app.scrimedsolutions.com from a network that can resolve DNS.
• Command: SCRIMED_BASE_URL=https://app.scrimedsolutions.com SCRIMED_WORKSPACE_SLUG=atlas-synthetic-evaluation npm run smoke:public
• Pass condition: All public HTML routes, JSON APIs, Markdown briefs, headers, and protected fail-closed checks pass.
• Workaround: If sandbox DNS blocks this command, rerun with approved network access and attach the preflight classification to the launch note.
• The smoke suite does not approve protected AAL2 happy-path mutations or production clinical authority.

Domain ownership and route fallback

• Detection: Verify app.scrimedsolutions.com health, product, launch-readiness, and pilot routes after every DNS, Vercel, or Wix CTA change.
• Command: curl -L --max-time 20 -s -I https://app.scrimedsolutions.com/api/launch-readiness
• Pass condition: The branded domain returns launch-readiness headers and buyer routes load without Vercel-auth friction.
• Workaround: Use direct Vercel deployment URLs or authenticated share links for internal review while branded DNS or CTA routing is repaired.
• Fallback routes are continuity aids, not a replacement for branded-domain launch readiness.

Custom domain and DNS preflight

• 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.
• Proof: /release-continuity, /operations, /navigation, /api/launch-readiness

Source, build, and route inventory

• 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.
• Proof: /navigation, /product, /api/navigation-audit, /api/product/console

Product and offer packaging

• 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.
• Proof: /product, /offerings, /demos, /pilots, /pricing, /pilot-deal-room

Service delivery and onboarding

• 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.
• Proof: /client-onboarding, /sales-operations, /pilot, /pilot-workspace/access

Enterprise operations and margin control

• 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.
• Proof: /enterprise-business-ops, /capital-vitality, /public-market-readiness, /growth-engine

Scale, support, and reliability posture

• 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.
• Proof: /enterprise-scalability, /service-reliability, /operational-efficiency, /platform-power

Healthcare data, interoperability, and patient safety

• 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.
• Proof: /health-records, /interoperability, /clinical-authority-readiness, /clinical-care-activation

Approvals, certifications, and global launch readiness

• 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.
• Proof: /approvals-readiness, /global-certification-readiness, /global-reach, /trust-center

AI, API, UI, agents, and continuous review

• 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.
• Proof: /platform-power, /agents, /continuous-review-audit, /qa-claim-guard

Protected proof and customer release

• 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.
• Proof: /pilot-workspace/access, /buyer-release-control-run, /qa-buyer-proof-release, /qa-manual-execution-console

Public buyer entry

• Public, no-PHI, synthetic-only, claims-controlled.
• 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

• Human-reviewed communications, no automatic send, no calendar mutation.
• 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

• AAL2 protected, tenant-scoped, no-PHI, metadata-only where external artifacts are referenced.
• 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

• Non-binding until executive, legal, accounting, tax, and buyer authority reviews complete.
• 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

• Preparation only until qualified external evidence exists.
• Customer output: Region, approval, privacy, security, data, and clinical-authority plan.
• Fallback: Synthetic, metadata-only, and external-reference evidence lanes until local approvals exist.

Sandbox DNS false negative blocks confidence even when production is healthy.

• Gate: Primary branded domain resolves and public smoke passes from approved network.

Fallback deployment URL could be mistaken for buyer-ready launch proof.

• Gate: Domain, SSL, Vercel alias, Wix CTA, and launch-readiness API headers verified.

Launch breadth overwhelms first-time buyers or investors.

• Gate: Each launch audience has one packet, one proof ladder, one owner, and one next action.

Product claims outrun approvals, certifications, or healthcare authority.

• Gate: External evidence and qualified reviewer signoff exist for any expanded claim.

Service delivery grows faster than support, margin, or governance.

• Gate: Repeatable onboarding, support, billing, contract, and margin processes are approved for the target segment.