[Kryscekk]

As a urologist who built and runs his own clinic management software, I'd encourage thinking about this question early: what does the system do when the LLM refuses to answer, returns malformed JSON, or hallucinates a glycemic value? In medical contexts, a 'silent failure' (system continues despite bad data) is much worse than a noisy failure (system stops and asks the user). The 'happy path' for an LLM-powered medical tool is usually well-designed. The failure paths are where the project lives or dies. Curious how you handle that.

[jlengelbrecht]

Thank you. Really appreciate this feedback. I am actually already thinking about this. Hallucinations need to be clearly called out which is important. This is on the project's roadmap for me to address. There needs to be a way for users to clearly say "This is wrong. you need to reevaluate" In terms of alerting this is where we drift from what the LLM does and what the platform does. The platform already ingests data and stores it in the RAG system which provides the AI context but AI is the component that used for chatting about your data and providing you daily briefs. Alerting lives on the platform side so the AI may use it when we start implementing pattern detection to alert diabetics and care takers with questions such as "I see your glucose is rising. Did you eat and not bolus?" but for actual glucose events that fire during hyper or hypo events this is hard coded in the platform itself.