Roadmap

What's coming next — designed in the open

Every item on this page is pilled with a StatusPill drawn from the same vocabulary as the rest of the site. Items marked planned have a code path, spec, or schedule that will be activated when the gating event lands. Items marked designed have an architecture but no commitment to schedule yet. Items marked future are directional intent. What's already shipped lives at /changelog.

Now · 0–30 days

In flight today

Active work on the prototype and the public surface. These items don't require a design partner or external dependency — they're polish and rigor we can ship under our own steam.

End-to-end smoke test of the polished surface

Wired in prototype

Reproducible smoke-test script at frontend/scripts/smoke-test.mjs. Hits 40 static routes + 4 persona-specific routes, follows 105 unique internal links, POSTs realistic fixtures to 19 API endpoints. Current run (2026-06-24, BASE_URL=localhost): 168 / 168 pass. Run via `npm run smoke` against a local dev server; results land in SMOKE_TEST_RESULTS.md. Re-runnable after every polish pass.

Source: See SMOKE_TEST_RESULTS.md

GitHub Private Vulnerability Reporting enabled

Planned

One-click toggle in repo Settings → Security. Required for the 'Report a vulnerability' button referenced in SECURITY.md to appear on the Security tab. Closes the open todo from the OSS-hygiene trio commit.

Source: SECURITY policy

Roadmap + changelog pages

Shipped

This page (/roadmap) and its sibling (/changelog) — making 'what's shipped' and 'what's coming' first-class surfaces rather than buried in commit messages.

Source: Changelog

MuleSoft iteration 8 — Phase-2 contract DataWeave (deployed 2026-06-16, live on CloudHub)

Shipped

providers-flow's DataWeave was rewritten to match the Phase-2 contract — a curated 9-row slice with lat/lng + serviceSignals + licenseStatus + insuranceAccepted + matchType tier ladder + ?insurance= filter — and shipped to CloudHub 2.0 as v1.0.4. Direct CloudHub /providers?menopause=true returns the full Phase-2 field set (latitude/longitude/distanceMiles, serviceSignals, licenseStatus, insuranceAccepted with 5 plans, credentialSource:'curated-overlay', top-level sort:'score') and production /api/mulesoft/providers reports meta._source:'live-mulesoft' end-to-end through Auth0-JWT → Flex Gateway → ngrok → the worker. The frontend contract-shape vitest pins live ⇄ mock parity so future drift fails CI. Two non-obvious deploy gotchas captured in MULESOFT_API_MANAGER_RUNBOOK.md: the rotated Connected App needed Runtime Manager + Exchange Contributor/Viewer scopes added per surface, and mule-maven-plugin's -DmuleDeploy doesn't publish to Exchange (two-command deploy: deploy-file to Exchange v2 maven, then -DmuleDeploy for Runtime Manager).

Source: /proposal/mulesoft

MuleSoft iteration 9 — Flex Gateway persistent hosting

Planned

The Flex Gateway runs Docker + ngrok on a local machine; when the machine sleeps or restarts the tunnel drops and pause-health.ai silently falls back to mock data (verified today: TLS handshake gets 'Connection reset by peer'). Iteration 9: move the gateway container to a persistent VM (DigitalOcean droplet or EC2 t4g.nano) so the MuleSoft live surface is always on. No Anypoint or Next.js changes needed — just a new host + updated MULESOFT_*_BASE_URL in Vercel. Sequenced after iteration 8 deploy so the new VM serves the Phase-2 contract from day one.

Source: /proposal/mulesoft

Next · 30–90 days

After the next decision point

Items gated on the next external event — usually 'first design partner conversation' or 'first credentialed customer org'. The code paths are designed or partially wired; the activation step is a customer-or-cohort gate, not an engineering gate. A few entries here are marked shipped — those are recent platform-layer milestones (Data 360 Phase 2, MuleSoft iterations 1–7, provider-graph Phase 1+2) kept in this horizon as context for the partnership-gated next steps that build on them.

First design-partner provider organization onboarded

Planned

A provider system that signs a design-partner LOI to co-develop the Care Router on a real cohort. Sized at one to three orgs across OB/GYN, primary care, and integrated health systems. This is the single highest-leverage unlock for the rest of the roadmap — every 'planned' BAA / IRB / SOC 2 item below is paced by when this lands.

Source: About / Milestones

Clinical advisory board formed

Planned

Clinicians across OB/GYN, endocrinology, primary care, and behavioral health to validate the Care Router policy, risk-band thresholds, and pathway routing. Pace: 4–6 advisors before the first design-partner pilot launches.

Source: About / Team

pause_ingest → real JupyterHealth Exchange round-trip

Wired in prototype

Now runs against a real JupyterHealth Exchange Django instance (docker postgres + jhe-local container, OIDC RS256 key, seeded RBAC + Patient + Oura DataSource + Study with explicit per-scope consent rows + FhirSource + a client_credentials OAuth app named pause-ingest). examples/oura_sample_upload.py round-trips both a real Oura heart-rate sample (mapped handler, integer pk) AND a derived HRV-time-domain feature observation (auxiliary handler, UUID pk) with derivedFrom pointer to the raw row, prints 'OK — uploaded and round-tripped 2 observation(s)'. Three real-JHE-only gotchas the wire-level mock had not pinned were surfaced and fixed in the same session: pause_ingest was requesting OAuth scope strings JHE rejects, used Content-Type application/fhir+json which JHE's parser rejects, and wrote OMH codings whose system/code shape did not match JHE's mapped-Observation routing criteria so writes silently fell through to the auxiliary handler. The wire-level mock was tightened to enforce the same routing contract — codings outside https://w3id.org/openmhealth now 400 without an X-JHE-FHIR-Source-ID header. Followed up 2026-06-23 by shipping an opt-in PAUSE_USE_REAL_JHE=1 pytest marker (pause_ingest/tests/conftest.py + test_exchange_real_jhe.py) so the same 7 contract assertions run against the live JHE instance, not just the periodic manual smoke script — 7/7 green against jhe-local; surfaced + documented two more mock-vs-real divergences (POST response omits valueAttachment; GET /Observation?patient=<unknown> doesn't filter to empty Bundle). Transcript at docs/JHE_REAL_RUN_2026-06-16.md; runbook Path B in docs/JHE_SETUP_RUNBOOK.md.

Source: /proposal/integration

MuleSoft Anypoint — iterations 1–8 complete

Shipped

Eight iterations shipped: CloudHub 2.0 worker live (iterations 1–2), Flex Gateway runtime enforcement (iteration 3), Rate Limiting SLA (iteration 4), OAS 3.0 spec published to Exchange (iteration 5), stable ngrok domain pinned (iteration 6), JWT Validation via Auth0 RS256/JWKS replacing Client ID Enforcement + plain Rate Limiting (iteration 7), Phase-2 contract DataWeave deployed to CloudHub 2.0 as v1.0.4 with the full provider field set live behind Auth0-JWT (iteration 8, 2026-06-16). Current policy stack: JWT Validation + Rate Limiting (10 req/min global). Iteration 9 (persistent VM hosting for the Flex Gateway) is the remaining piece, tracked in the Now horizon above.

Source: /proposal/mulesoft

Data 360 Phase 2 — Data Cloud unified profile

Shipped

LIVE in production: lib/salesforce/data-cloud.ts layers HRV z-score, vasomotor burden, and sleep disruption from three Data Cloud Calculated Insights on top of the Phase 1 SOQL grounding. The trailsignup DC tenant is provisioned, the CIs (Pause_HRV_RMSSD_30d, Pause_Vasomotor_Burden_30d, Pause_Sleep_Disruption_7d) are authored + activated over ssot__Individual__dlm, and SF_DC_TENANT_URL is set on Vercel; auth goes through the mandatory a360 token exchange. Each insight falls back to its intake baseline independently if a DC call fails. Demo-cohort values are seeded mock CIs — the next iteration swaps them for real JHE/DBDP wearable math (same client, same token flow). Walkthrough + gotchas in docs/PHASE_2_ACTIVATION_CHECKLIST.md.

Source: /proposal/data-360

Provider graph Phase 1 + Phase 2 — shipped end-to-end

Shipped

Phase 1 (NPPES bulk schema → menopause NUCC taxonomy filter → MSCP overlay → graphScore) and Phase 2 (Census 2020 ZCTA distance ranking, six NPPES service-line signals, three state license-sanction overlays dropping 1,720 sanctioned candidates at build, real-shaped synthetic insurance, /provider browseable UI + /provider/[npi] profile pages) are both wired and verifiable. The committed national run carries 2,015 providers behind the frozen /api/mulesoft/providers contract. See /changelog for the per-commit history and /proposal/provider-graph for the full architecture.

Source: /proposal/provider-graph

Provider graph Phase 2-bis — partnership + commercial-feed unlocks

Planned

Two pieces wait on external dependencies, not engineering effort. (1) Licensed Menopause Society MSCP feed replaces the synthetic + self-reported overlay (the Society's terms-of-use prohibits scraping; gated on a partnership conversation). (2) Paid in-network insurance feed (Ribbon Health, Turquoise) replaces the synthetic SHA-256 derivation behind the same insuranceAccepted field. Both swap in behind the existing contract without consumer changes — the agent + Care Router + UI keep working unchanged. The synthetic shapes are calibrated to plausible real-world rates and clearly labeled in every API response.

Source: /proposal/provider-graph

Later · 90+ days

Pre-revenue, pre-PHI compliance milestones

Items that depend on a paying customer relationship, PHI under BAA, or an external audit. The frameworks are designed (see /security and /hipaa for the Today vs. Designed tables); the work itself is paced by the customer's contractual timeline, not ours.

HIPAA Security Rule controls — full implementation

Planned

Administrative, physical, and technical safeguards aligned with 45 CFR Part 164 Subpart C. Today: pre-PHI prototype with no Business Associate obligation. Designed: full Security Rule program activated before the first customer's BAA goes into force.

Source: /security

Business Associate posture + BAA execution

Planned

Pause-Health.ai is NOT a Business Associate today (we handle no PHI). The full BAA template, permitted-use scope, and breach-notification protocol are designed and ready for execution before any Covered Entity grants PHI access.

Source: /hipaa

SOC 2 Type II attestation

Planned

Type I (point-in-time) targeted ~6 months after the first customer signs; Type II (operating-effectiveness, 6+ month observation window) targeted ~12 months later. Independent auditor TBD. Both reports made available under NDA to prospective customers.

Source: /security

HITRUST CSF r2 certification

Planned

Targeted ~18 months after first customer signs — most health systems require HITRUST as a procurement gate. Scope: the production Care Router API surface + all PHI-touching services. Independent assessor TBD.

Source: /security

IRB-blessed validation cohort

Planned

~10k women across 3–5 design-partner provider organizations, stratified by menopause stage / symptom severity / care-access setting. Endpoints: pathway concordance vs. blinded clinician adjudication, symptom-burden trajectory at 30/90 days, time-to-MSCP-visit. Pre-registered with primary analysis specified.

Source: /research

Provider graph Phase 3 — closed-loop scoring

Future

After the first 1,000 referrals, the provider graph's ranking signal gets a closed-loop input: clinician acceptance, patient appointment-kept rate, and clinician feedback on Pause's routing decisions. Compounds with credential + service-mention signals already in Phase 1 / 2.

Source: /proposal/provider-graph

First pilot deployment

Future

Move from design-partner LOI to a paid pilot in production at one provider organization. Care Router running against real PHI (under BAA), with measurable outcomes flowing back to the validation cohort. Targeted 2027.

Source: About / Milestones

Open the validation methodology + code

Future

Subgroup pathway-distribution + concordance report, refreshed at the cadence the validation cohort supports. Methodology and analysis code published alongside the peer-reviewed publication. Bias-monitoring as a public artifact, not an internal dashboard.

Source: /research

For prospective design partners

Influence what ships in Next

The Next horizon is paced by the first design-partner conversation. If your provider organization is considering menopause-care AI tooling, the items in Next become a negotiation surface for your pilot scope. Reach out via /contact with what your team would prioritize.

Start a conversation →

For investors + advisors

The full thesis behind these horizons

/proposal/full is the long-form version of why each horizon is ordered the way it is — including the business model, ICP, competitive landscape, and 24-month operating plan that anchors the Later horizon.

Investor brief →Full proposal →