Questions behind the work.

Many care experiences are not captured by routine feedback. Silence does not tell us whether a visit went well; timing, trust, and the way a question is asked may all affect whether someone responds.

I have explored a patient-feedback prototype that makes it easier to share concerns and routes themes to a service owner. It uses synthetic scenarios and does not handle emergencies, clinical escalation, or grievances.

The open question is how a care team can show patients that their feedback led to a response without steering them toward praise or turning care into a loyalty programme.

What would you add from your own work or experience?

An AI answer can feel helpful even when it is answering the wrong question. In a clinical workflow, a confident response to incomplete context can consume a clinician’s time, hide uncertainty, and send a patient toward a path no one intended.

In the AI Firewall, AI Routing Gateway, and smart-glasses work, I am exploring bounded routing, fail-closed behavior, explicit handoffs, and synthetic tests for missing context, tool failure, and requests outside intended use.

The next test is whether the system can recognise when a person must take over, explain that boundary clearly, and support an appropriate handoff. A working prototype does not establish clinical safety.

What would you add from your own work or experience?

Consent becomes harder to understand when a cloud transfer is invisible to the person affected. Sensitive details may also leave through a prompt, a log, or an overlooked field.

The AI Firewall is a local gateway prototype that inspects outbound JSON before cloud calls, with allow, redact, and block decisions plus metadata-only audit events. It explores whether privacy can become behavior the team can test and the operator can understand.

The intended benefit is a visible decision before data leaves the local system. Real-world reliability and the operator experience still need testing.

What would you add from your own work or experience?

A demo can be right once and still fail in a real workflow. The model may choose the wrong specialist, call a tool with unsupported arguments, lose the source behind an answer, respond too slowly, or leave an operator unsure whether the system actually did what it claimed.

SystemBench explores evaluation across task success, reliability, groundedness, tool correctness, safety, performance, operability, and human interaction. The aim is to make the failure visible while there is still time to change the design.

The aim is to give a team better evidence for what to ship, constrain, or keep researching. The evaluation method itself still needs testing against real decisions.

What would you add from your own work or experience?

Non-invasive sensing can make a biological signal feel like a shortcut to a diagnosis. But a signal becomes useful only when we know what it is being compared against, which people it may fail for, and what decision it is supposed to improve.

BioVOC, NeoGlycemia, and metabolic-risk research planning point to the same discipline: define intended use, reference standard, confounders, provenance, and validation before making a clinical claim.

The next step is a study design that could test whether the signal improves a clinical decision. That question must be answered before a device or test is described as useful in care.

What would you add from your own work or experience?

Measurements often look more certain than they are. A blurry scan, a lost device connection, or missing context can still produce a number that feels precise enough to act on.

The Clinical LiDAR Framework and Smart Glasses simulator explore how a tool can show poor capture, missing data, or an invalid state before a measurement is mistaken for a conclusion. The prototype uses synthetic inputs, calibration, quality gates, and vendor-neutral contracts to make those limits testable.

The design aims to make uncertainty visible at the decision point: ask for better input, hand the case to a person, or stop. Those responses still need to be tested with real users and settings.

What would you add from your own work or experience?

Personalization begins with a promise: the system will understand a person better next time. Without visible consent and control, that promise can quietly become a record of someone’s life that they cannot inspect, correct, or delete.

Reflection AI explores consent-aware memory with provenance, isolation, deletion, rollback, and gated training. A person should be able to see what was retained, understand why it was used, change their mind, and recover from a bad inference.

The question is whether people can understand and use those controls in practice, rather than having to trust an invisible memory system.

What would you add from your own work or experience?