Two products. One patient model.
Everything we build stands on a single idea: one timestamped picture of a person, grounded in the language medicine already agrees on. Auratwin is a consumer twin that learns your daily life. Auracare CDSS is clinical decision support that reasons over the whole picture: vitals, history, symptoms and everything the twin captures. This page is how both work.
The twin builds the picture no clinic ever sees.
Wellness apps fail the moment they demand effort. Auratwin removes it: the signals you already generate flow in on their own, get normalised into one timestamped model of your body, and the twin reaches you where you already talk. The result is a high-context, continuously updated view of daily life: the part of your health that lives between appointments.
of people who install a health app are still active a month later. The other 96% have churned, and almost all of them go in the first two weeks: not because the advice was wrong, but because logging it was work.
-
Connect
Link the wearables and health apps you already use. Cloud services sync server-side: the vendor pings us the moment a new record lands and we pull just that record. Phone-native sources push straight from the device, since they expose no server to poll. Either path runs in the background. Nothing to open, nothing to remember.
-
Normalise
Every source records data its own way. The twin translates each record into one shared format (resting heart rate is the same field whether it came from a ring or a watch), removes duplicates across devices, and timestamps each reading in your local time, so last night’s sleep is counted on the right day. The result is one clean, consistent stream instead of a dozen feeds that don’t line up.
-
Converse
The twin keeps an eye on the normalised stream and messages you first when something shifts (a run of poor recovery, a sedentary streak) and answers when you text back. Just reply in plain language; that is the logging. It all happens in your messages: no new app, no forms, no streaks to keep alive.
Raw signals in, scores out.
Sleep, movement, meals and mindfulness sessions map to one canonical, timestamped schema. From those inputs the twin computes the scores you read: a Sleep Score from sleep stages, duration and consistency; recovery from resting heart rate and heart-rate variability, so every number is derived the same way, whatever device it came from. Wearables sync automatically; anything else is a reply away.
- Sleep Duration, efficiency, deep and REM
- Recovery & HRV Readiness, recovery score, resting heart rate
- Activity Steps, movement, daily exertion
- Nutrition Meals and substances, from a normal text
- Mindfulness Meditation and breathing sessions, minutes and streaks
- Context Screen time, location and daily rhythm
Health records can be read into the twin but never acted on by it. Auratwin is a general-wellness product under the FD&C Act §520(o)(1)(B) exclusion, not a medical device: the twin gives wellness guidance, not diagnosis.
One timestamped model of a person.
A person’s health does not live in one app. It is scattered across devices, labs and memory. The patient state pulls those sources onto a single timeline, each observation encoded into the same clinical vocabulary and stamped with when it was true, so the loop always reasons from one coherent picture, not a dozen partial ones.
Because everything is timestamped, the state is longitudinal, not a flat snapshot. It can answer what a reading was, how it has changed, and whether that matters now: iron studies rising, a resting heart rate creeping up.
Acute readings arrive the same way. Our own devices (a recording stethoscope, a blood-pressure monitor, an otoscope) stream straight into the core: a closed hardware-to-software link, with no manual entry and no third-party integration in between.
- Everyday-life signals from the twin
- Acute vitals, streamed from our own devices
- Lab results & records
- Clinical notes & history
- What a person tells us, in their own words
- One timestamped patient state
A loop, not a pipeline.
Most health AI runs a fixed pipeline: data in, answer out. Auracare behaves more like a clinician: it reasons, decides the next-best question, then reasons again, always anchored in established medical evidence. A pipeline ends when it produces an answer; our loop treats every answer as the start of a better question, and only acts once no further question is worth its cost. A safety layer wraps all six stages, end to end.
-
Input
The prior and the acute, on one timeline: everyday-life signals from the twin, clinical history, and vitals captured live in the room, all as points on a single timestamped record.
-
Encoding
The bridge. Each observation is entity-linked onto the clinical ontology and stamped with when it was true, building the one patient state the core reasons over.
-
Thinking
The neuro-symbolic core weighs the evidence over the knowledge graph and returns a distribution over what is likely, never a single guess.
-
Thesis
Calibrate, score, diagnose. The distribution is grounded against population data, turned into quantified risk, and stated as a ranked differential with its sources attached: a working thesis, held only as long as the evidence supports it.
-
Value-of-information
The loop asks whether more evidence is worth acquiring. If yes, it picks the single next-best question, exam or test and feeds it back to the top. If not, it converges and hands the thesis on.
-
Medical outcome
The thesis becomes an action: a referral, a prescription, further testing or a lifestyle plan, each one gated by safety and by what is permitted where the patient is.
Stage five is the only exit. Nothing reaches a patient until value-of-information says the next question is not worth its cost, and every action that follows is checked against the safety overlay before it leaves the loop.
Two kinds of intelligence, checking each other.
Learned models are fluent but can be confidently wrong. Symbolic systems are rigorous but rigid. We pair them and draw a sharp, named line between the two, because Auracare is a medical device: a regulator’s question is not “is it accurate” but “which decisions crossed onto the learned side, and can you reconstruct them.” We keep that line inspectable.
Auditable, authoritative
- The clinical ontology (SNOMED CT, ICD-11, LOINC, HPO): curated, deterministic, every edge inspectable
- Runs the red-flag and contraindication screens, and reads diagnoses straight off named graph edges
- Authoritative: it holds the veto over anything the learned side proposes
Adaptive, advisory
- A Heterogeneous Graph Transformer: a graph neural network that learns patterns across a patient’s linked clinical data
- Bends the generic textbook weights toward this patient’s comorbidities and trajectory, then ranks the shortlist
- Advisory by construction: it proposes and personalises, but never makes an un-gated decision
The learned model proposes. The auditable layer disposes.
A glass box, not a black box: every conclusion traces back to a named ontology edge or rule, and every step is logged and replayable.
One gate on every stage.
Safety is an overlay, not a box at the end. Drawing it as a single final filter would imply reasoning can be unsafe as long as the last gate catches it, which is exactly the failure mode a medical device must not have. So the overlay runs through the whole loop, with a different instantiation at each stage.
And the outermost gate is a person. Auracare is built to be used in conjunction with a clinician, never to replace one. It is a tool that informs and supports their judgement. The clinician stays accountable for every decision, and their opinion always overrides the model.
Encoding-confidence gate
A signal that cannot be mapped to the right concept with enough confidence is flagged, not silently trusted. A mis-linked observation would poison everything downstream.
Audit log of decisions
Every reasoning step is recorded with its inputs and provenance, so any conclusion can be reconstructed and replayed after the fact.
Red-flag screen
A hard, authoritative screen over the differential that can escalate or veto regardless of what the learned side proposed.
Jurisdiction guard
The loop only ever proposes actions permitted where the patient is: prescribing authority and what is possible in primary care versus referral.
Contraindication check
The last gate before any terminal action: interactions, allergies and pharmacogenomic contraindications, checked against the medicine.
Clinical assurance sampling
The empirical face: human clinicians grade sampled live outputs against a harm ladder, with sign-off at every new deployment and ongoing random re-review.
On data residency: our approach is jurisdiction-based. Auracare will comply with the data residency requirements and local health data laws of each market we operate in, with the reasoning core designed to run inside our own cloud tenant in the applicable region so consented health data stays within infrastructure we control. This is an architectural commitment for the agentic engine, which remains in development, and whose regulatory pathway is under active, continuous review.
Grounded in what medicine already knows.
The twin and the reasoning core both bind to the same live graph of clinical concepts and the relationships between them. It is not scraped from the open web; it is mapped to the standards clinicians, regulators and health systems already trust, and it is the one part of the system you can explore for yourself today.
- SNOMED CT The anchor
- ICD-11 Diagnoses
- HPO Phenotypes
- LOINC Lab codes
- NICE UK guidance
Every answer traceable to a named source.