BHS is clinical AI infrastructure for behavioral health platforms serving caregivers and vulnerable populations. A deterministic safety layer. A zero-PII privacy architecture. Population-specific clinical knowledge graphs. And a structured evaluation process that runs before a single real user ever reaches the system.
BHS goes beyond basic prompt wrappers. Every message passes through a privacy architecture, a population-specific clinical knowledge graph, and a deterministic Crisis Rules layer before the LLM is invoked. On crisis signals, the Crisis Rules layer takes control and directs the LLM. Casual conversation is not possible, and the model has no discretion. This infrastructure exists because the population demands it.
The BHS privacy architecture is built on minimum necessary use: the system collects only what is required to deliver a clinically appropriate response, retains only what is required to maintain care continuity, and shares nothing beyond what the user has explicitly consented to. Messages are encrypted at ingestion and stored separately from the derived clinical data. The emotional states, lived experiences, and longitudinal care history that drive the system live in a separate dataset from the message content itself, and the two are never joined at the model layer. The Clinical Knowledge Graph receives structured clinical context, and the LLM receives an anonymized payload drawn from that context, with no path back to the identity of the person who sent it.
The Crisis Rules layer is not a prompt and it is not a classifier. It is a deterministic logic engine that runs on every inbound message after the knowledge graph resolves context. When a crisis signal is detected, the Crisis Rules layer classifies the danger level and dynamically generates a tightly controlled prompt based on that classification. The LLM responds only within that prompt, directed to either connect the user with emergency services or deliver clinically appropriate crisis techniques. Casual conversation is not possible at that point. The LLM has no discretion. The Crisis Rules layer does.
No deterministic system catches every indirect or implicit expression of risk. BHS does not claim otherwise. The Crisis Rules layer is under continuous expansion with clinical advisory input specifically to close that gap. The SAFE Standard evaluation framework is designed to surface those gaps before they reach a live user.
Every BHS pathway runs through a structured, versioned clinical evaluation framework before a single real user reaches it. Bloomb was evaluated against the SAFE Standard, a BHS-authored framework built around four non-negotiable criteria. Clover was evaluated against the SMART 40, a framework independently defined by the grant reviewer who assessed the program. Both evaluations run on population-specific synthetic scenario libraries. The results are documented, versioned, and available for IRB submission, insurer review, and enterprise due diligence.
View Full Evaluation Results →BHS runs on Microsoft Azure. Every component, from the population-specific knowledge graph and interaction history to the audit log and private LLM endpoint, lives in a cloud architecture designed around the principle that behavioral health data should never leave the environment you control. Data residency, encryption at rest and in transit, and role-based access are not configuration options. They are defaults.
The LLM runs on a private endpoint inside your Azure tenancy or BHS-managed infrastructure. No message, no clinical context, and no user payload ever reaches a shared public API. If the endpoint is compromised, there is no PII there to expose, because the decoupling layer handled that upstream.
Each pathway runs on its own graph. the Bloomb knowledge graph knows postpartum, the Clover graph knows autism caregiving. They share infrastructure but not knowledge. The graph is structured, queryable, and completely separate from the LLM. If the model changes, the clinical knowledge stays yours.
Every session produces a structured record: emotional states detected, risk level assigned, techniques selected or suppressed, safety protocols triggered, care network notifications sent. The record is complete, timestamped, and reviewable by a clinician without a single patient message ever being exposed. This is the audit trail your IRB, insurer, and legal team need.
Data is encrypted at rest and in transit. Interaction history is stored separately from the knowledge graph. Reporting uses derived clinical state, covering emotional patterns, risk trajectories, and session outcomes, with no verbatim user content in any reporting surface. Data residency is configurable per deployment. Role-based access limits who can see what, and audit logs capture who looked.
The BHS architecture is built around HIPAA privacy principles: consent-gated collection, minimum necessary use, data separation, role-based access, and documented breach response. A Business Associate Agreement is in progress with Microsoft. Compliance documentation is available for enterprise due diligence.
Real-time monitoring tracks system health, response latency, safety protocol activation rates, and error events at the application level. Alerts fire on anomalous patterns before they become incidents. Session-level telemetry is retained for post-deployment audit, separate from clinical content.
Most conversational AI resets with every session. The BHS Dynamic Care Pathway engine tracks state across the full care relationship. It selects responses from the population-specific knowledge graph, matching conditions, emotional states, care stages, and appropriate interventions into explicit relationships rather than leaving that reasoning to the LLM. The result is a system that responds differently to the same words depending on who is saying them, when, and what has happened in every prior session.
Once the care level is set, the personalization engine selects the specific technique, resource, or referral that fits this person at this moment, including routing to your own vetted local provider network if you bring one.
The care level system spans eight states from healthy adjustment through acute crisis, each with a defined response posture, technique set, and escalation logic. As a user moves through those states across sessions, the system tracks the trajectory and adjusts accordingly. A user who reaches a sustained crisis state across multiple sessions receives a different response than someone encountering that state for the first time, because the system knows the difference.
The knowledge graph is what makes this possible. When the system selects a response posture or escalates a level, it is traversing a structured graph of conditions, emotional states, care stages, and clinically appropriate responses. State persists across sessions. A user who reaches a sustained crisis state did so across multiple conversations, and the system tracked that history.
Each BHS pathway is built on a population-specific clinical ontology developed from direct lived experience and clinical advisory input. The knowledge architecture exists independently of the LLM, which means responses are clinically coherent because the reasoning is explicit, not because a model achieved it through statistical probability. A new pathway begins with the knowledge graph, not with a prompt.
The flagship BHS pathway. Built across the full postpartum arc from healthy adjustment through Edinburgh-scored depression risk, NICU trauma, birth trauma, and perinatal loss. The knowledge graph maps 25 emotional states and 35 lived postpartum experiences across 4 care stages. Validated against the SAFE Standard before launch.
Built for the caregiver, not just the child. The knowledge graph maps 25 emotional states and 35 lived caregiver experiences across 4 care stages: Early Intervention, School Years, Adolescence and Puberty, and Transition to Adulthood. 30 evidence-based techniques tuned to this population at that specific moment. Validated against the independently defined SMART 40 framework.
Because BHS captures emotional state trajectories, risk level histories, care stage progressions, and technique outcomes across sessions, and because consent is gated at the point of collection and not applied retroactively, that data is available to researchers and providers in structured, derived clinical form. No raw message content is ever included. The architecture was designed for this from the start.
BHS can provide consented, de-identified longitudinal datasets covering emotional state trajectories, risk level patterns, care stage progressions, and intervention outcomes across the postpartum and autism caregiver populations. Data is structured, timestamped, and expressed entirely in derived clinical language, suitable for IRB-approved research without requiring access to any raw session content.
Providers working with patients who use a BHS-powered platform can receive a structured longitudinal clinical record covering emotional state trajectory, risk level history, and care stage progression, all under patient consent and in derived clinical language. No session transcripts. No raw disclosures. A clinician can review what the system understood about a patient over time without reading a single message the patient sent.
Tell BHS about your platform and your population. Most conversations start with a simple question about whether this is a fit for what you are building.