Sense
Available location, motion, HRV, and SOS signals enter the software pathways.
WISAM · safety in the context of a person’s routine
Location alone is not enough. Is this normal for them?
WISAM brings together available location, movement, and other signals. It compares location with a person’s routine and shows caregivers what changed, when the signal arrived, and what needs review.
Functional software prototype · simulated wearable telemetry
Illustrative image; not a WISAM deployment or patient.
The product
What is WISAM?
WISAM is an AI-supported safety software system designed for people living with dementia and those who care for them.
It does more than show a location. WISAM puts device signals alongside a person’s routine, compares GPS with a personal baseline, and combines available results and safety rules into context a caregiver can review.
Location alone cannot answer these questions:
- Is this place familiar for them?
- What changed?
- How recent and reliable is the signal?
- Does someone need to review this?
- 01Wearable and location signalsGPS · HRV · IMU motion · SOS · device status
- 02AI and personal analyticsBaseline · routine change · anomaly checks · risk fusion
- 03Information for peopleStatus · alerts · signal time · emergency profile
Current stage: the software path runs from signal ingestion to alerts in demonstration interfaces. Wearable telemetry is simulated today; connecting a physical device is the next technical step.
01 / The problem
An alert alone does not explain the situation.
GPS can tell you where someone is. It cannot explain whether that place is usual for them, when the last signal arrived, or whether something else changed. WISAM is designed to put those questions in context.
- 01Is this place or route usual?
- 02When did the last signal arrive?
- 03Did something else change at the same time?
02 / How it works
From a signal to a clearer human decision.
Each alert follows five simple steps. Signal timing and missing data stay visible throughout.
Understand routine
GPS is compared with a person’s usual pattern; HRV can use its own baseline.
Detect change
Components and safety rules flag a change or request for help that may need attention.
Add context
The last update, connectivity, and gaps remain visible so unknown is not mistaken for safe.
Support action
The interface presents status and alerts for a person to review and decide what to do next.
The planned wearable experience
The watch senses. WISAM adds personal context.
A wearable can provide location, movement, heart-rate, SOS, and connection signals. WISAM’s role is to read what is available together, show what changed from the usual pattern, and make interruptions visible.
01LocationPlace and time of the last update
02SOSA request for help sent by the person
03MotionActivity change and a possible fall signal
04Heart rate / HRVAdditional data if the device provides it
05ConnectivityDid the signal arrive or stop?
06Device / batteryIs the device running and connected?
Device signals → comparison with routine → safety checks → caregiver review
What has actually been evaluated?03 / AI and analytics
Intelligence that reads context, not a signal in isolation.
WISAM does not depend on one reading. Each pathway checks the data it has, then combines results and safety rules into a state a person can review.
- 01 / 05 — GPS · HRV · IMU · SOS
Each signal has its own pathway
GPS examines location, HRV processes beat-to-beat variation, IMU adds movement context, and SOS arrives as a direct safety signal.
- 02 / 05 — Personal Baseline
The baseline defines what is usual
GPS compares routes and zones with the person’s pattern. HRV can receive its own baseline; one baseline is not automatically applied to every signal.
- 03 / 05 — Anomaly Detection
Changes are checked
Components score the signals they receive. Safety rules check events such as SOS, while stale or missing signals stay visible.
- 04 / 05 — Risk Fusion
Risk fusion brings signals together
Risk Fusion combines available component scores with safety escalation rules into one state for review.
- 05 / 05 — Human Review
A person reviews and responds
Available status, alerts, and context reach caregiver and responder interfaces. A person decides on the next step.
04 / The caregiver experience
When something changes, caregivers need the right context quickly.
These real app captures follow the review journey: current status, alert details, then emergency information a responder may need. The screens use demonstration data.
Prototype screens with demonstration data; live location from a physical watch is not connected yet.
05 / When an alert arrives
What does the caregiver see?
Status
An at-a-glance view of available status instead of separate signals.
Change
What differed from the usual route, or which request for help arrived?
Data quality
The last update, connectivity, and gaps in the available data.
Next step
Details for review and contact; the software does not decide for the caregiver.
06 / What we tested
We tested what we built.
The software passed 72 automated tests: 45 for the backend and API, and 27 for AI services. We also evaluated the GPS and HRV components separately on specific tasks using public data.
WISAM / Evidence
WISAM Evidence Dashboard
Select a category to see what was tested, the result, and the limit of that result.
Evidence class / Engineering verificationReported verification run · 7 September 2026
72Automated tests
45Backend/API
27AI services
What this means
45 backend/API tests plus 27 AI-service tests, rechecked 7 September 2026. Frontend typechecks are excluded. Engineering test coverage, not clinical or field validation.
Evidence class / Component evaluationEvidence reviewed
1,896Trajectories
Dataset & task
GeoLife public mobility trajectories. Heuristic abnormal-route labels; user-disjoint train/test split.
What this means
GeoLife contains no dementia wandering labels. These are component proxy-task metrics, not clinical product accuracy or advance prediction.
Evidence class / Component evaluationEvidence reviewed
2,964One-minute windows
Dataset & task
PhysioNet Apnea-ECG. One-minute sleep-apnea proxy windows; two held-out test records.
What this means
General adult sleep-apnea data, not dementia patients; these are proxy-task component metrics, not clinical dementia or apnea diagnosis.
Evidence class / Prototype / feasibilityEvidence reviewed
An IMU/motion pathway is present in the prototype risk pipeline.
Dataset & task
Synthetic scaffold data. Fall and gait pathway feasibility in the software prototype.
What this means
The current fall and gait model uses synthetic scaffold data; its synthetic test scores are not public accuracy evidence.Synthetic feasibility only; no proven fall detection or prevention performance.
These are results for specific technical components. See the datasets, methods, and limits on the evidence page.
See the evidence, methods, and limitsThe project roadmap
We built the system. The next stage is proving it in the real world.
We are at stage 3 of 6, evaluating technical component evidence. Next come physical-device integration and a controlled pilot to test how the system works with people.
CURRENT STAGE03 / 06Technical Evidence
- 01Concept & system designCompleted
- 02Functional prototypeCompleted
- 03Technical evidenceCurrent
- 04Real wearable integrationNext
- 05Controlled real-world pilotFuture
- 06Validation & commercial readinessFuture
09 / People behind WISAM
Meet the WISAM team
The people developing the software prototype and preparing its next technical stage.
Working on wearables or real-world studies?
Explore ways to collaborate