Organization-level platform configuration decides which module types exist
for your patients and which view templates are active. The mechanical split
among stable, rolling, memory, and rendered views stays the same across
organizations.
State modules
Patient state is grouped into four families with different update rhythms and roles. The Console explores them through observability and patient detail; engineers map log types and templates onto these regions in configuration. The module keys listed below are examples of what exists today, not a fixed set: the catalog grows as the platform adds new data domains, and your organization’s configuration determines which modules are active.Stable profile
Baseline clinical and administrative facts that change relatively slowly: identity, conditions, medications, care relationships, coverage, and similar “current truth” that should stay valid until something explicitly updates it. Example module keys (categorystable_data): demographics, condition_diagnosis, medications, treatment_phase, user_preferences, emergency_contact, care_team, insurance, social, pharmacy, procedures, allergies, immunizations, devices, family_history.
Event-driven modules
Time-varying signal derived from logs: symptoms, labs, vitals, device-derived measures, engagement, conversations, and other streams that reflect what is happening with the patient now and recently. Shape and churn differ by domain, but the idea is the same: rolling clinical and product context, not a permanent archive in one blob. Example module keys (categoryevent_state): behavioral_state, symptoms, adherence, physical_activity, engagement, heart, sleep, lab_results, vitals, clinical_context, questionnaires, conversations, glucose, alerts_and_tasks.
Memory bank
Holds unstructured insights distilled from chats and similar sources. These are short, categorized memories the platform uses for continuity across sessions. Like other regions, memory is part of patient state, not a bolt-on store, and each insight keeps provenance back to what produced it.Views
Timestamped, template-driven outputs per view category: the rendered layers agents and APIs read; examples include medication, symptoms, and care context. They are built from stable, event-driven, and memory content on a schedule. Views & templates separates templates, how a category is defined, from views, the patient-specific result at a point in time. To inspect the field-level models behind each module and watch your patient state fill in as you send more log types, open a patient’s state in the Console.Time, weekly signal & longer horizons
Stable modules answer “what do we believe right now?” For historical reads you typically take a single cut at a chosen timestamp. Event-driven modules and the memory bank are intentionally high-churn: the live material holds on the order of about a week of relevant signal that rolls forward as new logs are processed, not an unbounded archive in one row. That keeps payloads sized for models and makes recency honest. When a view or job needs more than a week, the platform assembles a window: it merges versioned module snapshots across week-aligned slices inside the interval you care about, deduplicating and letting fresher data win. You get a truthful picture of how that rolling surface evolved over the range, without pretending one static row describes the whole period.Views work differently: generation starts from the current view
snapshot for the run’s timestamp, plus upstream modules; prior wording
inside a block is carried through that block’s last result, not by
replay-merging every old snapshot document.
Next steps
Views & templates
How blocks are built, cadence, confidence metrics, and provenance.
Accessing patient state
Read state via MCP, the Python SDK, or REST from your workflows.