Investor brief · Salesforce Data 360

Unified patient memory, federated in place

Pause-Health.ai's Care Router is grounded on real Salesforce Health Cloud objects today via OAuth Client Credentials, with identity resolution against real seeded Contacts (Phase 1). Phase 2 — Data Cloud Calculated Insights (HRV z-score, vasomotor burden, sleep disruption) — is LIVE on the trailsignup tenant; the endpoint reports 'Phase 2: SOQL (Health Cloud) + Data Cloud Calculated Insights' on every routing call. Phase 2-bis swaps the demo-cohort seeded CIs for real JHE FHIR + DBDP wearable math through the same client + token flow; Phase 3 onboards the customer's EHR-of-record. The Care Router interface doesn't change across phases.

Why Data 360

Four properties — pilled by what's wired today

Pills: Wired in prototype wired and live in the prototype today · Today · partial shape live, values still synthetic / demo-cohort seeded · Designed committed path, activates with Phase 2-bis or first customer.

Designed

Zero-copy federation

The pattern Data 360 enables is to query the customer's existing data plane in place — JupyterHealth FHIR, Snowflake / Databricks warehouses, DBDP feature stores, and the Epic Health Cloud — via the Federation + Iceberg connectors. No PHI bulk-ingestion into Salesforce; nothing for the customer's data team to migrate. Today, the live grounding path federates against the customer surface we control (Salesforce Health Cloud); the broader sources federate in Phases 2–3.

Today · partial

Unified patient memory

Identity Resolution reconciles the same patient across wearable signups, EHR records, prior intake sessions, and claims. The Care Router decides over a single unified patient, not whichever fragment happened to be in the current API response. Today: deterministic match against real seeded Health Cloud Contacts is LIVE behind /api/data-360/identity/resolve when Salesforce env vars are set; the configurable cross-source IR ruleset is Phase 2.

Wired in prototype

Calculated insights as triage features

Materialized features computed continuously across the federated sources. Today: 3 Salesforce-native insights (active care program, days since last clinical contact, active care plan status) are computed LIVE on every Care Router call from real Health Cloud objects, and the wearable / EHR insights (HRV z-score, vasomotor burden, sleep disruption) are now served LIVE from Data Cloud Calculated Insights via the Phase 2 federation. These become routing inputs without us writing a feature pipeline.

Designed

Segments power proactive care

Population segments (e.g. "late perimenopause with rising HRV variability", "postmenopausal bleeding cohort") activate to Agentforce, the Agent Fabric, and Health Cloud. Pause will reach the right patients before they ever open an intake session. Today: four hand-curated segments are returned by /api/data-360/segments; segment authoring + activation plumbing are Phase 4 work.

How it composes with the rest of the stack

Where Data 360 sits in the fabric

Designed

Sits between MuleSoft and the agents

MuleSoft remains the integration plane (system-to-system, writes, transforms). Data 360 is the unified read plane on top: 'what do we know about this patient, right now, across every source we federate into?' The two compose cleanly. MuleSoft itself is currently mocked at /api/mulesoft/* (see /proposal/mulesoft); the Data 360 read plane is live against Health Cloud today.

Wired in prototype

Registered as a first-class agent on the fabric

Data 360 appears in the Agent Fabric registry alongside Agentforce, the Care Router, the Pause MCP server, and MuleSoft. Its grounding queries emit trace spans. Its identity resolution emits trace spans. Every call is auditable in the same pane — verifiable today at /demo/agent-fabric.

Today · partial

Policy-governed grounding

Three Data 360-specific policies advertised today: zero-copy-federation-only (no PHI bulk-ingest), consent-required-before-grounding (the Care Router cannot read without an active 'ai-decision-support' consent), segment-activation-allowlist (downstream channels must be approved). The consent ledger is included on the federated record; hard-blocking enforcement is Phase 3 work alongside the customer's consent service. Standard HIPAA audit policy applies to every grounding call.

Wired in prototype

Identity resolution at the front door

When Agentforce captures the intake, the handoff endpoint asks Data 360 to resolve the partial identity to a unified patient id. That unified id flows through the rest of the trace — the Care Router, the MCP server, every downstream span carries it. Wired today at /api/data-360/identity/resolve against real seeded Health Cloud Contacts.

The four-span trace

Every multi-agent task produces this shape

Open /demo/agent-fabric, run a test case, and watch the four spans appear with parent/child correlation intact. When Salesforce env vars are set, spans 2 and 3 carry a LIVE badge.

Span 1: Agentforce intake.complete
Patient finishes the intake. Captured fields, red-flag screen, and severity are recorded as the parent span.
Span 2: Data 360 identity.resolve
The handoff endpoint asks Data 360 to resolve the partial identity. Returns the unified patient id and the IR confidence score. LIVE against real seeded Salesforce Health Cloud Contacts when env vars are set.
Span 3: Data 360 grounding.federated-query
Federated read against the Data 360 unified patient view: calculated insights (active care program, days since last clinical contact, active care plan status — all LIVE Salesforce-native), longitudinal observations, cohort comparison. Wearable / EHR insights (HRV, vasomotor, sleep) are served LIVE by the Phase 2 Data Cloud Calculated Insights client (a360 token exchange against the trailsignup tenant), falling back to intake-only baselines per-insight only if a DC call fails.
Span 4: Care Router a2a.tasks/send
The Care Router receives BOTH the intake AND the Data 360 grounding as data parts of one A2A message. Decision rationale cites which insights it used; span attributes record cohort name and insights cited.

Touch the architecture

Every Data 360 surface is reachable as a real HTTP endpoint

The Care Router reads grounding from one of these on every intake. When Salesforce env vars are set, grounding + identity resolve go LIVE against the connected Health Cloud org; when unset, they fall back to the deterministic mock. Identity resolve is a POST endpoint invoked during the intake flow — click through to /demo/intake to exercise it end-to-end rather than as a one-shot URL.

Open Agent Fabric console →GET /api/data-360/.../grounding →Identity resolve (POST · run in /demo/intake) →Federated patient record →Population segments →

Where Phase 1 is wired

Three environments, one decision matrix

The real-Salesforce grounding path is activated by three env vars (SF_INSTANCE_URL, SF_CLIENT_ID, SF_CLIENT_SECRET). When set, the Care Router queries a connected Health Cloud org via OAuth 2.0 Client Credentials Flow. When unset, every API route silently falls back to the deterministic mock and the prototype runs end-to-end with zero credentials.

Environment	SF env vars	Active grounding path
Local dev (founder's machine)	Set in `frontend/.env.local`	LIVE Salesforce Health Cloud (real Contact / CareProgramEnrollee / CarePlan / Case)
Vercel preview / production (`pause-health.ai`)	Deliberately unset	Deterministic mock (shape-identical to live path)
Investor demo session	Temporarily set in Vercel, then unset after	LIVE for the duration of the demo

Why the public site is mock-by-default: the connected dev org is a Trailhead Playground (not production-grade), and routing public intake traffic at it would (a) exhaust its API limits, (b) create unbounded demo records, and (c) tie investor demo quality to whoever last did a write against the org. The mock is identical in shape and clinically realistic, so the public surface stays investor-ready without any of those risks. The first paying customer brings their own Salesforce org and their own env vars.

Prototype vs production · per-row status

Seven aspects of the federation, labeled honestly

Pills: Wired in prototype LIVE today against Salesforce Health Cloud when env vars are set · Designed mocked today, activates with Phase 2/3 federation.

Status	Aspect	Prototype today	Customer deployment
Wired in prototype	Identity Resolution	LIVE today: deterministic match against real seeded Health Cloud Contacts in our Salesforce dev org. Returns the real Salesforce Contact.Id as the unified patient id. Mock falls back automatically if the org is unreachable.	Configurable Data 360 IR ruleset across federated sources, returning ranked match candidates with confidence scores.
Wired in prototype	Grounding query target	LIVE today: real SOQL against Salesforce Health Cloud (Contact + CareProgramEnrollee + CarePlan + Case). Returns real enrollment status, real care-plan status, real days-since-last-clinical-contact, real cohort size.	Real Salesforce Data 360 Federated Query API against the customer's JupyterHealth FHIR store, DBDP feature warehouse, and EHR-of-record. Phase 1 SOQL pattern stays — the federation target swaps.
Wired in prototype	Calculated insights — Salesforce-native	LIVE today: "Active care program enrollment", "Days since last clinical contact", "Active care plan status" — built from real Health Cloud objects on every Care Router call. Insight names match what lib/salesforce/grounding.ts emits.	Same insights plus Data 360 Calculated Insights jobs recomputed nightly/streaming over the federated sources.
Wired in prototype	Calculated insights — wearable / EHR	LIVE in production: lib/salesforce/data-cloud.ts queries three Data Cloud Calculated Insights (Pause_HRV_RMSSD_30d, Pause_Vasomotor_Burden_30d, Pause_Sleep_Disruption_7d) on the trailsignup org via the a360 token-exchange flow, layering HRV RMSSD z-score, vasomotor burden composite, and sleep disruption index onto the Phase 1 SOQL grounding. Each falls back to an intake-only baseline independently if the DC call fails. Demo-cohort values are seeded mock CIs over ssot__Individual__dlm; the production wiring is identical (see docs/MULESOFT_PHASE_2_DATA_CLOUD.md).	Real Data 360 Calculated Insights jobs against the customer's JupyterHealth FHIR observations and DBDP feature warehouse — same client, same token flow, only the CI SQL behind the DMO changes.
Designed	MSCP-credentialed contact recency	Surfaced in the mocked /api/data-360/* path as "days since last MSCP-credentialed clinician contact" so the trace + UI can model the eventual signal. The LIVE Health Cloud path returns only generic "days since last clinical contact" because the credential overlay isn't wired into the seeded Contacts yet.	Joins the LIVE clinical-contact recency against the customer's MSCP roster (from /proposal/provider-graph + /proposal/menopause-society partnership) to produce the credential-aware signal.
Designed	Segments	Four hand-curated segments returned by /api/data-360/segments (mocked).	Population segments authored in the Data 360 console by the customer's clinical-data team, with activation routes configured per segment.
Designed	Consent enforcement	Consent ledger included on the federated record; policy advertised but not blocking the prototype.	Hard-enforced by the Data 360 consent service. Care Router grounding calls without an active 'ai-decision-support' consent are rejected with a redaction notice.

Phased plan

From real Health Cloud grounding to a federated customer deployment

Wired in prototype

Phase 1 — Real Health Cloud grounding

Shipped

Pause's Care Router is now grounded on real Salesforce Health Cloud objects from a connected dev org: real Contact, real CareProgramEnrollee, real CarePlan, real Case. OAuth 2.0 Client Credentials Flow via an External Client App. The Agent Fabric console shows a LIVE badge on every span served by the real org. Zero-credential mock path remains the default for previews and CI.

Wired in prototype

Phase 2 — Data Cloud Calculated Insights

Shipped on trailsignup

Three CIs authored + activated on the trailsignup tenant over ssot__Individual__dlm: Pause_HRV_RMSSD_30d, Pause_Vasomotor_Burden_30d, Pause_Sleep_Disruption_7d. SF_DC_TENANT_URL wired into Vercel; auth flows through the mandatory a360 token exchange (a core Salesforce token is NOT valid against the c360a tenant — must hit /services/a360/token first). Each CI falls back to its intake-only baseline independently if a DC call fails, so the Care Router degrades cleanly. The grounding endpoint now reports 'Phase 2: SOQL (Health Cloud) + Data Cloud Calculated Insights' on every call. The path here surfaced five things the original runbook got wrong (a360 token exchange chief among them) — all documented in docs/PHASE_2_ACTIVATION_CHECKLIST.md so re-running on a customer org is a checklist, not an archaeology dig. Demo-cohort values are seeded mock CIs; Phase 2-bis swaps them for real wearable math.

Designed

Phase 2-bis — Real wearable math behind the same CIs

Same client, same token flow, only the CI SQL changes

The Data Cloud Calculated Insights client doesn't care what's behind the DMO. Phase 2-bis swaps the seeded mock CIs for real Data Cloud Calculated Insights jobs against the customer's JupyterHealth FHIR observations and DBDP feature warehouse — same lib/salesforce/data-cloud.ts, same a360 token flow, same fall-back semantics. What changes is the CI definition (the SQL behind ssot__Individual__dlm) and where the source data lands. No Care Router, agent, or UI change required.

Designed

Phase 3 — First customer deployment

4–6 weeks with customer

Federate the customer's EHR-of-record (Epic / Cerner / Athena) and their DBDP feature warehouse. Author the customer's IR ruleset. Wire consent enforcement to the customer's existing consent ledger. Roll the Care Router onto real-customer grounding.

Future

Phase 4 — Cohort analytics & activation

Ongoing

Population segments activate to Agentforce for proactive outreach ("women in your cohort who saw an MSCP within 14 days had 71% symptom resolution"). Health Cloud cards on the patient timeline. Marketing Cloud for educational journeys.

Why investors should care

Four properties of the Data 360 grounding strategy

Hospitals don't migrate; they federateDesignedPause does not ask a customer to move PHI into Salesforce. Data 360's zero-copy federation reads the data where it already lives (JupyterHealth, Snowflake, Epic). This is the posture that closes deals with Chief Data Officers — the prototype federates only against Salesforce Health Cloud today; the broader federation is Phase 2/3 work.
Longitudinal context makes the agent visibly smarterWired in prototypeWithout Data 360 grounding, the Care Router sees one intake. With it, the agent sees real Health Cloud enrollment status, real care-plan status, real days-since-last-clinical-contact (Phase 1, SOQL), and the 30-day HRV z-score / vasomotor burden composite / sleep disruption index (Phase 2, Data Cloud Calculated Insights — LIVE on trailsignup) on every routing call. The same code path produces materially better routing decisions — and the rationale shows it.
Open ecosystem at every tier — including dataDesignedData 360 is the customer's data control plane. MuleSoft is their integration plane. JupyterHealth + FHIR + DBDP is their clinical substrate. MCP + A2A is the agent contract. Pause composes — it doesn't lock anything in.
Same data plane, two product motionsDesignedB2C: the Care Router routes patients smarter because Data 360 told it about the cohort. B2B: hospitals install Pause on top of their existing Data 360 (or our managed Data 360) and segment their menopause population for proactive care. One platform, two GTM wedges.

Read deeper

Where Data 360 meets the rest of the brief

Headless 360 — where Data 360 fitsToday · partialData 360 grounding is the REST leg of Salesforce's Headless 360 architecture (TDX 2026). The audit page is the single-place mapping that classifies every Pause surface and names the missing PKCE seam for full conformance.
Multi-agent control planeWired in prototypeThe Agent Fabric where Data 360 is registered and its grounding calls are traced.
MuleSoft integrationDesignedThe integration plane that will write back to JupyterHealth and the EHR-of-record that Data 360 federates over. Today: Experience APIs mocked at /api/mulesoft/*.
JupyterHealth integrationToday · partialThe FHIR R5 substrate Data 360 will read from as its primary clinical federation target. Today: omh-shim + jupyterhealth-client integrated in pause_ingest; JHE federation is Phase 2.
DBDP feature engineeringToday · partialThe wearable feature pipeline that will supply HRV, sleep, and vasomotor signals to Data 360 calculated insights. Today: FLIRT + DBDP HRV math integrated in pause_ingest.
Provider graphDesignedWhere the MSCP credential overlay comes from — the join target that makes 'days since last clinical contact' into 'days since last MSCP-credentialed contact' in Phase 3.
Salesforce Data 360The Salesforce product Pause grounds its agents on.