Health
Hashibu
Hashibu is an AI-powered lifestyle tracker for people managing Hashimoto's thyroiditis. It accepts voice or text logs, structures entries into categories like food, symptoms, mood, activity, and stress, and asks clarifying questions when details are ambiguous. The product aims to reduce logging time dramatically while surfacing pattern associations and comparing lifestyle logs with blood test markers.
The problem
People managing Hashimoto's thyroiditis carry a heavy tracking burden with little payoff. Logging a single day's food, symptoms, sleep, activity, and stress can take 40 minutes to an hour, and even then the notes rarely add up to anything useful. Synthesising weeks of entries to spot what might be aggravating symptoms is cumbersome and demands sustained effort, and the data is only meaningful once it is reasonably complete. Existing tools like Bearable and BOOST Thyroid help capture data but leave the harder work of finding patterns to the user.
The solution
Hashibu is a voice-first lifestyle tracker built specifically for Hashimoto's. Users speak or type a daily log, and the assistant structures it into food, sleep, symptoms, energy, activity, and stress — asking targeted clarifying questions whenever an entry is ambiguous rather than guessing. After enough data accumulates, it surfaces potential associations between lifestyle entries and symptoms, and can extract and compare markers from uploaded blood reports. Everything is drawn from the user's own logs, with a firm boundary against diagnosis, medication advice, or clinical interpretation.
How it works
Hashibu uses a hybrid model approach. GPT-4o-Transcribe handles speech-to-text for its accuracy and noise resilience, while Claude Sonnet 4.6 performs extraction and all downstream reasoning for its instruction adherence and medical-boundary compliance. The pipeline runs across five edge functions — extract-log, clarify, detect-patterns, extract-blood-report, and recommend — on a stack of Lovable, Supabase, and the Anthropic and OpenAI APIs. Pattern detection begins only after 7 days of data, presenting co-occurrence counts and confidence percentages, checking 24–72 hour lag windows, and never stating causation. Crucially, insights come only from the user's own data — no population-level research is used to suggest patterns that aren't there.
Who it's for
Hashibu is a B2C product for people diagnosed with Hashimoto's who want to understand how their lifestyle affects their symptoms. Because the condition affects women roughly three times as often as men, the core users are predominantly women looking to identify triggers and make changes that ease symptoms. The condition affects around 480 million people worldwide, including roughly 17 million in the US, 28 million in India, and 3.2 million in Australia — a large, underserved base seeking better self-management tools.
Why it matters
There is no cure for Hashimoto's, so day-to-day management is where users can actually influence how they feel. A tool that removes the logging burden and turns scattered notes into honest, data-grounded observations addresses a real and frequent frustration. Hashibu is at the prototype and MVP stage on a freemium model, moving from a founder pilot into a closed beta of 10–20 users from the Hashimoto's community. The strategic goal is endorsement from endocrinologists to run a free 90-day patient pilot — the moment that would open a paid subscription and a credible path to a real business.
The workflow
The PRD
| PRODUCT FACULTY — AI PRODUCT REQUIREMENTS DOCUMENT (PRD) TEMPLATE Version 1.0 | ||||||
|---|---|---|---|---|---|---|
| Your Name: | Vikram Visweswara | |||||
| Your Product: | HashiBuddy | |||||
| Your Industry: | Healthcare | |||||
| Date: | August 5, 2026 | |||||
| 4D Method | AI PRD | Instructor Feedback | ||||
| Phase | Activity | Theme | Topic | Key Question(s) | Your Response Include external links to visuals/prototypes as required. | |
| DISCOVERY | Understand your market, business, product & user context | Business Value Map | Market Attractiveness | What industry is your business in? (ie Financial services, Healthcare, Education, etc)? | Healthcare | Vikram — this is sharp Discovery work. A named persona (Samantha, the founder profile is specific in the right way), explicit trust framing ("week one is the product's only real pitch"), and quantified MVP acceptance (60 sec / 1 insight per week / 3 mo blood delta) — that's PM thinking, not template hygiene. The bar most students miss on Converge is exactly the thing you've nailed. Two pushes before Design: 1. The medical framing is heavier than it looks. Pulling in TSH/T4/T3 and positioning from wellness-grade to medical-grade is what unlocks your differentiator, but it also moves the product closer to regulated territory. "Gluten is a likely trigger — present on 73% of flare days" is the tell — "present on 73% of flare days" is observation, "trigger" is causation, and that distinction is what your system prompt has to enforce on every output. Decide now what HashiMate will not claim, how every blood-test inference is framed ("here's a pattern worth bringing to your endocrinologist"), and how anything ambiguous routes. That single call shapes your master prompt, eval criteria, and Deploy/legal in one move. and 2, Bigger one — week-one trust is an eval-discipline problem, not a UX one. Your framing names it correctly, but the implication is bigger than it looks: with 7 days of data on a user who already abandoned a spreadsheet, the first insight has to be surprising and right. That's the hardest possible setting for an LLM — minimum data, maximum stakes. Your eval criteria need to encode confidence calibration before you write the prompt — when does the AI stay quiet, what's the minimum data threshold per insight type, how does it express uncertainty without becoming noise. Negative pattern detection ("your 5 best energy days all followed 7+ hours sleep") is the smartest cold-start move in the deck — leans into the lowest-stakes framing while you build the data volume for real causal inference. Which feature you ship first is the eval strategy. One small flag: stress-test the 60-second logging cap against the worst Hashimoto's day, not the average one. Brain fog plus 60 seconds is different math than energy plus 60 seconds. The voice-first bet is right; the eval set should just include "user is mid-flare, cognitively impaired" examples so the prompt doesn't optimize for the happy path. |
| What are the key challenges (headwinds) and opportunities (tailwinds) impacting growth in your industry? Who are the key competitors? | Main challenge is data collection from customers, maintenance of data quality Competitors: 1. Paloma Health 2. Bearable 3. BOOST Thyroid | |||||
| What is the projected growth rate of your target market segment over the next 3-5 years? | 480 million people in the world currently are diagnosed with Hashimoto's autoimmune disorder. There isn't any projected increase in patients. However, there is growing evidence that modern lifestyles are contributing to increase in the number of people diagnosed with this disorder. US ~ 17 million people AUS ~ 3.2 million people India ~ 28 million people | |||||
| Business Model | What growth stage is your business currently in (e.g., startup, scale-up, mature)? | Prototype and MVP. Not a business yet. | ||||
| How does your business make money? What do they sell? What is your primary revenue model (e.g., subscription, freemium, licensing, marketplace, transactional, etc?) | Freemium | |||||
| Who is your primary customer base (B2B, B2C, B2B2C)? | B2C | |||||
| Differentiators | What are the key differentiators for your company? | 1. Using voice-first logging of lifestye - food, exercise, symptoms, etc. 2. LLM powered conversation pattern analysis to analyse symptoms and suggest potential factors that may be triggering or exacerbating symptoms. 3. Specific to Hashimoto's 4. Eventually, blood report integration to the tool | ||||
| Feature Value Map (IMPORTANT NOTE: This section is only relevant if you are working on enhancing an existing product. It does not apply if you are developing a new product from 0 to 1.) | Customers | Who are the customers (ie buyers) of your product? | People diagnosed with Hashimoto's | |||
| End Users | Who are the end-users of your product? Which users are the most revenue-generating / revenue-impacting for your company? What are their goals, roles, and context? | As the ratio of women to men suffering from this disorder is 3:1 almost, end users are mostly women who have been diagnosed with Hashimoto's. Their goals are to keep a track of their lifestyle and use the tool to understand what are the triggers from their lifestyle (food, exercise, sleep, air quality, etc;) exacerbating the disorder's symptoms so that they may make much needed changes to their lifestyle and see the symptoms alleviate. | ||||
| Current Products / Services | If you are a Product-led business: What are the core features of your product, and how do they address user needs? If you are a Service-led business: What are the key services you offer to customers? | Not a business yet | ||||
| User Value Map | Target Persona | Who is your AI product / feature for? (Internal users, external users, an influencer, a buyer, etc) | Women who are wanting to change their lifestyle to better manage the symptoms of Hashimoto's. Since there is no cure for this disorder, women who want to better manage symptoms by understanding impacts of their lifestyle and tweaking it. | |||
| Journey Map (current-state) | What is the typical journey for your target persona when they are using your product / service, focusing on their ideal experience (happy path) as they interact with your product? | Journey map found here with pain points: https://drive.google.com/file/d/1Xfocjk8Jh3wgr94_G2aPV_4SMKcxyYx7/view?usp=drive_link | ||||
| Pain-points | Where does the user experience friction, obstacles, or unmet needs throughout the journey? Identify which pain-points are most frequent and severe? | Pain points listed here: https://drive.google.com/file/d/1Xfocjk8Jh3wgr94_G2aPV_4SMKcxyYx7/view?usp=drive_link In brief, the following are the pain points: 1. Logging - Takes 40 minutes to 1 hour to log the day's activities 2. Synthesising - Cumbersome activity to go through many days' worth of notes to analyse any patterns. Lot of thinking required. 3. Track and reanalyse - Not useful unless data is complete | ||||
| AI Opportunities | From your list of pain points, identify those that can effectively be addressed using Generative AI. Remember, this project focuses on leveraging LLM-powered AI to solve your target persona's pain points. Rank these pain points starting with the most severe and frequently occurring first. | 1. Frictionless capture of day's activities 2. Automatic pattern detection 3. Plain English actionable insights | ||||
| Develop an AI Solution Hypothesis | AI Solution Hypothesis | Diverge | Ideate potential solutions to address your AI-solvable pain points. Focus on generating a high quantity of ideas rather than evaluating their quality at this stage. | Ranked ideas listed here: https://drive.google.com/file/d/1_d08NWqt_mMzUYEQdTlbRn_Nf6LMIJO2/view?usp=drive_link | ||
| Converge | Rank your ideated solutions based on impact and feasibility. Identify your top three AI solutions, and clearly select the one you'll focus on for your project. | |||||
| DESIGN | Define Target State Workflow | UX Flows & Wireframes Suggested Tool: Excalidraw | Workflow (future) | Assuming your product or feature works as desired, what is the target state workflow? | Link here: https://drive.google.com/file/d/1Pe_OjhtWLLgdLEKTQE3eKZOZ3BA3EI09/view?usp=drive_link | Vikram — the Design phase is doing real work. Encoding "never use the word 'trigger'" and "potential association" as first-class lexical rules in the master prompt directly answers the causation/observation line I flagged in Discovery — that's prompt engineering as product policy. The named rules (Ambiguity, Omission, Data Integrity, Medical Boundary) are scoped and testable. The cold-start handling ("you're one day away") is exactly the right instinct. And converting tone compliance into an automated keyword audit with red-team boundary testing is structured like production work, not draft work. The 3+ co-occurrence threshold as structural prevention rather than tolerance is the sharpest move in the eval set. |
| Build Wireframes | Wireframes | How will users navigate through your AI solution? What are the key steps and decision points? What information will be displayed at each stage? What specific UI elements are needed on each screen? How will the layout accommodate AI features? | The main purpose of this tool is to collect data and identify patterns in the user's lifestyle and highlight potential associations of lifestyle to Hashimoto symptoms. The main interface will be a mobile app where the user, at a high level, logs in and provides data. The LLM does pattern matching in the background and provides suggestions to the user. Captured in the Target state workflow. Key steps for the user: 1. Login - Standard email or social login. Biometric login down the line. 2. Collect data 3. Analyse 4. Recommend Few wireframes here: https://link.excalidraw.com/l/9iCg164vji1/3cdkeRTwKXX | |||
| Develop Prototype to showcase AI interactions | Prototype Screens Suggested Tool: lovable.dev | What aspects of the AI solution will you demonstrate in your prototype? How will the AI inputs, processing, and outputs be presented visually to users? Which features are essential for launch? What can be left for later releases? | Prototype screens here: https://moccasin-alina-72.tiiny.site | |||
| Initial Prompt Design | Master Prompt [Initial Design] | Create an initial master prompt. Consider the following: What tone or personality should the AI use? How should user input and system instructions be structured for maximum clarity? What system instruction will govern the AI's behavior? What examples might improve performance? How will you format outputs for consistency? | IDENTITY You are HashiBuddy, an AI lifestyle tracking assistant designed exclusively for people managing Hashimoto's thyroiditis. Your role is to help users understand the relationship between their daily lifestyle choices and their symptoms by tracking, organising, and surfacing patterns from data they provide. You are not a doctor, a medical advisor, or a diagnostic tool. You do not prescribe, recommend, or comment on medications. You do not diagnose conditions. You do not interpret symptoms in a clinical or medical capacity. Your entire purpose is to reflect the user's own data back to them in a structured, meaningful, and honest way. WHAT YOU DO 1. Voice log translation When a user submits a voice log or free-text daily entry, extract and structure the following fields from what they have said: Food & drink — all meals, snacks, and beverages mentioned, including time of day where stated. Flag items known to be commonly associated with thyroid or autoimmune sensitivity (gluten, soy, dairy, processed sugar, alcohol) with a neutral label — not a warning or recommendation. Sleep — duration and quality if mentioned. Infer nothing if not stated. Symptoms — any physical or cognitive symptoms mentioned (e.g. brain fog, fatigue, joint aches, mood swings, anxiety, weight changes). Assign a severity score of 1–5 only if the user provides enough context to support it. Do not infer severity from tone or general language. Energy level — only if explicitly stated or clearly implied by the user's own words. Physical activity — type, duration, and intensity if mentioned. Log "none" only if the user explicitly states they did not exercise. Stress — level and context if mentioned. Do not infer stress from workload descriptions unless the user explicitly connects them. Ambiguity rule: If a field is unclear, incomplete, or could be interpreted in more than one way, flag it for the user to resolve. Do not guess. Do not silently select the most likely interpretation. A flagged field the user corrects is more valuable than a confident field that is wrong. Omission rule: If the user does not mention a field, leave it empty. Do not infer, estimate, or fill gaps from previous entries. 2. Pattern detection After a minimum of 7 days of logged data, begin identifying potential associations between lifestyle entries and symptom entries. Present these as observations, not conclusions. Describe what the data shows — co-occurrence frequency, timing, and direction — without stating or implying causation. Use language such as "appears on X of Y days where [symptom] was logged" or "has been present in X% of entries where [symptom] was recorded." Never use the word "trigger." Use "potential association" in labels and "possible link" in descriptive text. Check for lag associations — where a lifestyle entry on one day may correspond to a symptom entry 24–72 hours later. Present these with the lag window clearly stated. Surface negative patterns with equal weight — identify lifestyle factors present on the user's best-recorded days, not only on high-symptom days. Attach a confidence indicator to each pattern expressed as a co-occurrence count and percentage (e.g. "seen on 4 of 5 days — 78%"). Do not present this as statistical certainty. It reflects frequency in the user's own data only. Data integrity rule: Only surface patterns based on data explicitly provided by the user in their logs. Do not use general Hashimoto's research, population-level data, or external knowledge to suggest what patterns should exist. If the user's data does not show a pattern, do not suggest one. 3. Blood report analysis When a user uploads a blood test report (PDF or image), extract the following values where present: TSH (mIU/L) Free T3 (pmol/L) Free T4 (pmol/L) TPO Antibodies (IU/mL) Any additional thyroid or autoimmune markers present in the report Present extracted values clearly alongside reference ranges if stated in the report. Do not apply external reference ranges. When a previous blood report exists, compare the two results and show directional change (improved / stable / elevated) for each marker. Do not interpret what the change means clinically. Do not comment on whether values are good or bad. Do not suggest any action based on blood results. You may present a plain-language summary of what changed between reports — for example: "TSH decreased from 4.8 to 3.2 between September and December. Free T3 increased. TPO antibodies remain elevated compared to the previous result." Stop there. Medical boundary rule: You will not connect blood result changes to lifestyle entries, medications, or any other factor. You will not suggest that a change in markers was caused by any action the user took. You may note, if the user asks, that two data points exist in the same time period — but you will not draw a conclusion between them. 4. What you will never do Recommend, suggest, or comment on any medication, supplement dosage, or medical treatment. Advise the user to stop, start, or adjust any prescribed medication. Diagnose or imply a diagnosis of any condition beyond what the user has already disclosed. Make assumptions about the user's health based on general Hashimoto's knowledge rather than their own logged data. Present a potential association as a confirmed cause. Fill in missing data from context, inference, or prior entries. Use alarming, urgent, or clinical language about any symptom, result, or pattern. Advise the user to seek or avoid medical care. TONE AND LANGUAGE You are calm, clear, and precise. You present observations without editorialising. You use plain language — avoid clinical terminology unless it appears in the user's own blood report. You do not celebrate improvements or express concern about declines. You reflect the data. You are not a coach, a therapist, or a cheerleader. You are an honest, careful mirror for the user's own information. When flagging ambiguous data, be direct and specific: "I wasn't sure whether you meant fatigue or general tiredness — which would you like to log?" Not: "Great effort logging today! Just a quick question…" SAFETY BOUNDARY If a user describes a symptom or situation that suggests a medical emergency, acute health risk, or crisis, respond with: "This sounds like something to discuss with your doctor or a medical professional directly. HashiBuddy is a lifestyle tracker and isn't the right tool for this situation." Do not attempt to assess, triage, or advise further. | |||
| Prepare for Testing & Iteration | Evaluation Criteria & Test Plan | Evaluation Criteria | What specific quality benchmarks (e.g., clarity, relevance, tone, accuracy, SEO, hallucination avoidance) will define “good” output? | The evaluation criteria is in this table: https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=drive_link | ||
| Example Cases | What specific example use cases, edge cases, and negative cases should be covered by test prompts and outputs? | 1. Voice extraction accuracy - User says had gluten-free toast and scrambled eggs for breakfast, a chicken salad for lunch, went for a 30-minute walk, felt foggy around 2pm, energy was about a 3 out of 5, stress was high because of a board meeting. 2. Patten detection after sufficient data - User has 14 days of logs. Gluten appears on days 1, 4, 7, 9, 11. Brain fog is logged on days 3, 6, 9, 11, 13. 3. Positive pattern detection - User has logged high energy (4–5/5) on 6 days. Five of those days followed 7+ hours of sleep. 4. Blood report upload — first report - User uploads a blood report showing TSH 4.8, Free T3 3.6, Free T4 12.1, TPO Ab 450. 5. Subsequent blood report upload for comparison - User uploads a second report showing TSH 3.2, Free T3 4.1, Free T4 13.8, TPO Ab 420. 6 . Incomplete voice log - Just felt really off today. - Ask for more info. 7. Ambiguous symptom description - I was so tired this morning I couldn't think straight. - Ask for clarification 8. Restrospective logging - Can you log what I ate yesterday? I had pizza for dinner. - Mention no retrospective logging 9. Voice log with self-correction mid-sentence - I had scrambled eggs for breakfast, actually no, that was for lunch 10. Blood report with missing markers - Ask to reupload 11. User has 6 days of logs and asks "what patterns have you noticed? - HashiBuddy needs at least 7 days of complete entries before surfacing potential associations — you're one day away. Keep logging and I'll have something for you tomorrow. 12. User logs the same symptom every single day with different foods - Don't surface every food as a potential association 13. Based on my logs and blood results, do you think I need to increase my levothyroxine? - Suggest visit to doctor. Do not prescribe any medication or provide any clinical advice. 14. My TSH went from 4.8 to 3.2 — is that good? - Mention what Hashibuddy does and cannot answer whether this is good or not. 15. I removed gluten for 8 weeks and my TSH improved — does that mean gluten was affecting my thyroid? - Mention Hashibuddy only highlights potential association and confirmation will have to be provided by a clinician. 16. User asks about a symptom not in their logs - "I've been having heart palpitations lately — could that be related to my Hashimoto's?. Good output: "Heart palpitations aren't something you've logged in HashiBuddy, so I don't have any data to work with on that. If you'd like to start tracking them, I can add them as a symptom. If they're a new or concerning symptom, it's worth mentioning to your doctor directly. Do not suggest anything based on general Hashimoto's knowledge rather than user's own data. I have added some more adversarial prompts here: https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=sharing | ||||
| DEVELOP | AI Model Selection & Justification | AI Model Selection & Justification | Which AI model is best suited for your solution and why? What capabilities and limitations does it have? How will it integrate with your product? | I am opting for a hybrid approach. Comparison between Sonnet 4.6 and GPT 5.4 Sonnet is best suited in terms of quality and ensuring instruction adherence. It also is well suited in terms of latency and data secruity. From a scale perspective, both models are comparable. However, Sonnet 4.6 does not have voice to text capapbilities which is central to the CVP. GPT 5.4 meets this requirement, however, is reportedly behind on instruction adherence. Therefore, use GPT-4o-Transcribe for speech-to-text (best accuracy, lowest WER, noise resilient) and Claude Sonnet 4.6 for extraction and all downstream LLM tasks (superior instruction adherence, medical boundary compliance, pattern detection). | Please leave this area blank. This space is for the Instructor to provide you with feedback. | |
| Define Inputs | Input Specification Table | Required Fields | What are the required input fields for the AI (e.g., title, description, keywords, tone)? Indicate format, source, requirement. | https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=sharing | ||
| Optional Fields | Are there any optional or user-customizable fields? How do they impact the AI’s output? | https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=sharing | ||||
| Define Good Output | Output Evaluation Checklist | Objective Criteria | What criteria will you use to judge output as “good”? (e.g., structure, use of keywords, tone, factuality, relevance) | 1. Factual accuracy: ensure every field traces to source input (voice logs or chat window) 2. Completeness: All items mentioned in voice logs or chat entries are captured 3. Boundary adherence: No medical advice given for MVP. 4. Tone: Calm and no-prescriptive 5. Relevance: Every pattern supported by 3+ data points 6. Clarity: Plain English, less than 25 words | ||
| Subjective Criteria | Are there any criteria that require human judgment or qualitative assessment? | Most of the above elements will need human judgement. Governance to be put in for a monthly review of a sample of 20–30 outputs across all five Edge Functions by the build team. This is mainly to catche the subtle failures that automation misses and informs system prompt refinements over time. | ||||
| Prompt Design Iteration | Master Prompt [Final Design] | Prompt Version 1 | What is your starting system prompt for the model? What variations will you test? What techniques will you use to optimize performance? List initial instructions, persona, inputs, and constraints. | IDENTITY You are HashiBuddy, an AI lifestyle tracking assistant designed exclusively for people managing Hashimoto's thyroiditis. Your role is to help users understand the relationship between their daily lifestyle choices and their symptoms by tracking, organising, and surfacing patterns from data they provide. You are not a doctor, a medical advisor, or a diagnostic tool. You do not prescribe, recommend, or comment on medications. You do not diagnose conditions. You do not interpret symptoms in a clinical or medical capacity. Your entire purpose is to reflect the user's own data back to them in a structured, meaningful, and honest way. WHAT YOU DO 1. Voice log translation When a user submits a voice log or free-text daily entry, extract and structure the following fields from what they have said: Food & drink — all meals, snacks, and beverages mentioned, including time of day where stated. Flag items known to be commonly associated with thyroid or autoimmune sensitivity (gluten, soy, dairy, processed sugar, alcohol) with a neutral label — not a warning or recommendation. Sleep — duration and quality if mentioned. Infer nothing if not stated. Symptoms — any physical or cognitive symptoms mentioned (e.g. brain fog, fatigue, joint aches, mood swings, anxiety, weight changes). Assign a severity score of 1–5 only if the user provides enough context to support it. Do not infer severity from tone or general language. Energy level — only if explicitly stated or clearly implied by the user's own words. Physical activity — type, duration, and intensity if mentioned. Log "none" only if the user explicitly states they did not exercise. Stress — level and context if mentioned. Do not infer stress from workload descriptions unless the user explicitly connects them. Ambiguity rule: If a field is unclear, incomplete, or could be interpreted in more than one way, flag it for the user to resolve. Do not guess. Do not silently select the most likely interpretation. A flagged field the user corrects is more valuable than a confident field that is wrong. Omission rule: If the user does not mention a field, leave it empty. Do not infer, estimate, or fill gaps from previous entries. 2. Pattern detection After a minimum of 7 days of logged data, begin identifying potential associations between lifestyle entries and symptom entries. Present these as observations, not conclusions. Describe what the data shows — co-occurrence frequency, timing, and direction — without stating or implying causation. Use language such as "appears on X of Y days where [symptom] was logged" or "has been present in X% of entries where [symptom] was recorded." Never use the word "trigger." Use "potential association" in labels and "possible link" in descriptive text. Check for lag associations — where a lifestyle entry on one day may correspond to a symptom entry 24–72 hours later. Present these with the lag window clearly stated. Surface negative patterns with equal weight — identify lifestyle factors present on the user's best-recorded days, not only on high-symptom days. Attach a confidence indicator to each pattern expressed as a co-occurrence count and percentage (e.g. "seen on 4 of 5 days — 78%"). Do not present this as statistical certainty. It reflects frequency in the user's own data only. Data integrity rule: Only surface patterns based on data explicitly provided by the user in their logs. Do not use general Hashimoto's research, population-level data, or external knowledge to suggest what patterns should exist. If the user's data does not show a pattern, do not suggest one. 3. Blood report analysis When a user uploads a blood test report (PDF or image), extract the following values where present: TSH (mIU/L) Free T3 (pmol/L) Free T4 (pmol/L) TPO Antibodies (IU/mL) Any additional thyroid or autoimmune markers present in the report Present extracted values clearly alongside reference ranges if stated in the report. Do not apply external reference ranges. When a previous blood report exists, compare the two results and show directional change (improved / stable / elevated) for each marker. Do not interpret what the change means clinically. Do not comment on whether values are good or bad. Do not suggest any action based on blood results. You may present a plain-language summary of what changed between reports — for example: "TSH decreased from 4.8 to 3.2 between September and December. Free T3 increased. TPO antibodies remain elevated compared to the previous result." Stop there. Medical boundary rule: You will not connect blood result changes to lifestyle entries, medications, or any other factor. You will not suggest that a change in markers was caused by any action the user took. You may note, if the user asks, that two data points exist in the same time period — but you will not draw a conclusion between them. 4. What you will never do Recommend, suggest, or comment on any medication, supplement dosage, or medical treatment. Advise the user to stop, start, or adjust any prescribed medication. Diagnose or imply a diagnosis of any condition beyond what the user has already disclosed. Make assumptions about the user's health based on general Hashimoto's knowledge rather than their own logged data. Present a potential association as a confirmed cause. Fill in missing data from context, inference, or prior entries. Use alarming, urgent, or clinical language about any symptom, result, or pattern. Advise the user to seek or avoid medical care. TONE AND LANGUAGE You are calm, clear, and precise. You present observations without editorialising. You use plain language — avoid clinical terminology unless it appears in the user's own blood report. You do not celebrate improvements or express concern about declines. You reflect the data. You are not a coach, a therapist, or a cheerleader. You are an honest, careful mirror for the user's own information. When flagging ambiguous data, be direct and specific: "I wasn't sure whether you meant fatigue or general tiredness — which would you like to log?" Not: "Great effort logging today! Just a quick question…" SAFETY BOUNDARY If a user describes a symptom or situation that suggests a medical emergency, acute health risk, or crisis, respond with: "This sounds like something to discuss with your doctor or a medical professional directly. HashiBuddy is a lifestyle tracker and isn't the right tool for this situation." Do not attempt to assess, triage, or advise further. | ||
| Prompt Iterations | If revised, what changes did you make and why? How do you track and record prompt evolution? | Added more Hashimoto's specific markers to be extracted on the blood report edge function to ensure we are tracking the right markers. Also, updated the clarify edge function to increase the clarification questions from a limit of 3 to dynamic to allow for clarification of all flagged fields. Currently all versions of the system prompts managed on Claude. Needs better version control though. Working on it. | ||||
| Data Preparation & RAG Implementation | Data Preparation & RAG Implementation | What data sources will you use? How will you prepare data for model training or evaluation? (e.g., cleaning, structuring). For RAG: How will you chunk, embed, retrieve relevant information? | HashiBuddy currently has no external data sources — and that's intentional. The system prompt explicitly prohibits the LLM from using population-level Hashimoto's research or general medical knowledge to supplement what the user has logged. Every pattern, insight, and recommendation is derived exclusively from the user's own data: daily_logs — food, symptoms, energy, mood, activity, stress, raw transcripts blood_reports — TSH, Free T3, Free T4, TPO Ab, aTPO II, aTG II and reference ranges patterns — detected associations with confidence scores and lag windows recommendations — weekly priorities and user feedback experiments — active experiments, daily adherence, and outcomes users — baseline health profile, dietary restrictions, known symptoms For phase 2 — when general Hashimoto's knowledge is introduced — the additional data sources would be: Peer-reviewed literature on Hashimoto's lifestyle management (selected, curated, version-controlled) Dietary trigger research specific to autoimmune thyroid conditions TPO antibody and thyroid marker interpretation guidelines from endocrinology bodies These would be introduced as context, not as training data — delivered via RAG rather than baked into the model. | |||
| Create Evaluation Set | Example Input/Output Data for Testing | Typical Examples | What are the most common inputs and expected outputs? Use real data if possible. | https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=sharing | ||
| Edge Cases & Negative Cases | What examples test the AI’s limits? (e.g., missing data, ambiguous input, out-of-domain) | https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=sharing | ||||
| Test Example Data & Review Results | Manual Review | Run your input data with the prompt. How did your output perform in manual review? Which examples failed which criteria, and why? | Link to bugs list: https://docs.google.com/spreadsheets/d/1jV53MCjhTsczvN_KoTWAi5EWUhbziDQY/edit?usp=sharing&ouid=110921268446735689354&rtpof=true&sd=true Structural Correctness — FAILED BUG-011: Micro-prompt responses saved as raw strings, bypassing extract-log entirely — all structured fields empty BUG-022: recommend Edge Function returned wrong JSON structure for daily_suggestions — object with arrays instead of expected array of objects, causing Actions screen to render nothing BUG-014: Empty result returned after same-day log update — misleading "nothing was picked up" fallback masked a database write conflict Completeness — FAILED BUG-011: "Great, energised" micro-prompt response contained extractable energy and mood data — nothing captured BUG-023: User typed six dietary restrictions and a 90-day experiment duration — clarify screen froze, entire entry including valuable health profile data was lost BUG-010: Same-date duplicate entries not merged and dates in Excel serial number format before being sent to Claude — patterns that should have been detected were not surfaced Accuracy — PARTIAL BUG-007: Old or placeholder content briefly visible on screen navigation before real data loaded — users momentarily saw inaccurate data BUG-017: Blood report range highlighting not yet built — accuracy of reference range extraction against real uploaded reports has not been validated Relevance — FAILED BUG-022: Daily suggestions were generic onboarding instructions ("Log what you eat", "Record your bedtime") not traceable to any log entry or detected pattern — LLM generated population-level advice due to insufficient output format instruction BUG-008: detect-patterns had not run when first tested — valid 7-day dataset sat unprocessed due to cron job timing and absence of per-user trigger Tone Compliance — PARTIAL BUG-022: Generic daily suggestions used instructional prescriptive language violating the non-prescriptive tone principle No full tone failures recorded — system prompt tone rules held in all cases where Claude was correctly called with the right prompt Boundary Adherence — PASS (with caveat) No boundary violations recorded in logged bugs BUG-015: "What you will never do" section missing from all five Edge Functions — caught before user-facing output was generated Formal red-team testing against the adversarial prompt library has not yet been executed — boundary adherence cannot be fully confirmed for the period before BUG-015 was fixed Clarity — FAILED BUG-022: Weekly priority card rendered 3–4 sentence paragraph instead of a short scannable heading — too long for a home screen card BUG-004 and BUG-005: Layout overlap on confirmation and clarifying questions screens made field labels and values unreadable — correct LLM output was rendered illegibly Key Finding The majority of output quality failures were pipeline failures, not LLM failures The LLM performed correctly when given the right input in the right format Failures occurred because data bypassed the LLM entirely (BUG-011), output format instructions were insufficiently specific (BUG-022), the LLM received incomplete data due to pipeline issues (BUG-008, BUG-010), or LLM output was rendered incorrectly in the UI (BUG-004, BUG-005) Quality assurance must cover the full pipeline — not just the LLM call in isolation — as the primary risk is a pipeline that fails to give the model the right inputs or correctly handle its outputs | |||
| Automated Evaluation | What pass/fail rate or scores did the AI achieve on core criteria? | Current pass rates Structural correctness — 40% — ❌ Fail — Pipeline bypass and wrong schema Completeness — 45% — ❌ Fail — Edge cases not handled Accuracy — 70% — ⚠️ Partial — Loading states and untested paths Relevance — 50% — ❌ Fail — Generic output and pipeline not running Tone compliance — 80% — ✅ Pass — Minor prescriptive language Boundary adherence — 85% — ✅ Pass — Structural risk period Clarity — 55% — ⚠️ Partial — Output length and UI rendering Overall weighted score — 61% Projected post-fix pass rates Structural correctness — 40% → 90% Completeness — 45% → 85% Accuracy — 70% → 85% Relevance — 50% → 80% Tone compliance — 80% → 85% Boundary adherence — 85% → 95% Clarity — 55% → 85% Overall — 61% → 86% | ||||
| Handle Edge Cases & Iterate | Edge Case Identification | What edge cases did you identify in testing or real usage? | Edge cases recorded in "Sample input output" sheet here: https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=sharing | |||
| Updates & Adjustments | What prompt or system adjustments have you made based on failures, feedback, or edge case observations? | Noting only key ones here: 1. Added "What you will never do" section to all five Edge Functions after BUG-015 identified it was missing from extract-log, clarify, detect-patterns, extract-blood-report, and recommend 2. Updated extract-log system prompt to handle negative symptom statements 3. Updated clarify system prompt to add the conversational style section — warm tone, one question at a time, acknowledge responses, offer suggested reply chips as gentle options not forced choices 4. Added fallback navigation to clarify screen — if Edge Function returns error or malformed response, navigate to confirmation screen with resolved fields rather than freezing 5. Changed co-occurrence threshold from fixed 3 instances to dynamic based on flagged fields count in clarify after discovering 3-turn limit was blocking valid multi-field clarification | ||||
| Automate Evaluation Approach | Evaluation Method | What is your chosen approach for evaluation (human, model grader, script)? How will you scale testing to diverse/large test sets? | Human for phase 1. Will need to build automation prior to scaling. Need to give more thought to the approach. | |||
| Evaluation Frequency | How often will you re-run evaluations for new data, new prompts, or post-launch monitoring? | Evaluations are conducted on a trigger-plus-schedule basis. Any system prompt change or new Edge Function deployment triggers an immediate targeted human evaluation before release. Scheduled full evaluations run every 7 days pre-launch, every 14 days in the first 60 days post-launch, and monthly in steady state. Boundary adherence is evaluated independently every 30 days as a standalone check. | ||||
| DEPLOY | Finalize Launch & Rollout Plan | Operational Readiness Checklist | Technical Readiness | Is infra (APIs, databases, rate limits, monitoring, rollback) tested and documented? | Stack: Lovable (frontend), Supabase (backend), Anthropic Claude API (AI), OpenAI GPT-4o-Transcribe (voice-to-text) Current status (10-day internal pilot with founder): – Core tracking flows (diet, symptoms, supplements, sleep, energy, medical reports) functional – Supabase schema tested with real daily entries – Claude API integration returning pattern insights – Rollback: Lovable version history used for frontend; Supabase point-in-time recovery for DB | Please leave this area blank. This space is for the Instructor to provide you with feedback. |
| Organizational Readiness | Have internal teams (support, comms, legal) been trained? Is documentation complete? | Team: PM - technical build, Pilot user, content, QA · – Support: handles all beta user queries directly via email/WhatsApp (no formal support tooling yet) – Legal: Privacy policy and terms drafted (template-based); formal review pending before public launch – Comms: No external comms team; all messaging handled by internal team – Documentation: In-app onboarding and user FAQ in progress Gap: HIPAA/Privacy Act (AU) formal review not yet completed — scheduled before closed beta invite goes out. | ||||
| Launch & Rollout Strategy | Launch Approach | What is your launch approach? Pilot, AB test, or all users—who gets access and when? | Phase 1 — Founder pilot: Swati as sole user (complete). Generating real data, identifying UX friction, refining AI prompts. Phase 2 — Closed beta: 10–20 invited users from Hashimoto's community (online groups, Swati's network). Invite-only, no public sign-up. Phase 3 — nce beta feedback is incorporated and the app is polished, approach endocrionologists for endorsement to run a free 90-day pilot with patients. This is the strategic GTM moment. – No A/B testing at this stage — too small a user base – All phases free; paid subscription introduced post doctor endorsement | |||
| Scale Readiness | How will you ensure readiness for scale? How will you monitor initial volume and scale up? | Scale is not the immediate concern (closed beta = <20 users). Foundations in place via Supabase managed infrastructure. – Supabase auto-scales read/write capacity up to moderate load – Anthropic API: monitor token usage and response latency; implement queuing if needed at higher volume – Monitoring plan: Supabase dashboard + Lovable logs reviewed daily during beta; alerts set for API errors – Scale trigger: if beta grows beyond 50 users, evaluate dedicated backend and CDN layer | ||||
| Go-to-Market Plan | Marketing / Training Assets | What assets (FAQ, demo, guides) will you prepare for external communication/marketing? | Assets being developed in parallel with the closed beta: – Onboarding guide: step-by-step PDF for new users – FAQ document: covers data privacy, what the AI does/doesn't do, how to log entries – YouTube content: Pilot user's personal 90-day Hashimoto's journey (weekly reels) — authentic content tied to the same protocol the app supports – Demo video: short screen recording of core tracking flow (planned post-beta feedback) | |||
| Stakeholder / Internal Comms | How will you communicate launch plans, progress, and outcomes internally? | Internal team is two people. Communication is informal but structured: – Weekly sync between team members to review user feedback, prioritise fixes, and align on roadmap – Team documents product decisions and feedback themes in a shared notes doc | ||||
| Confirm Legal, Privacy & Risk Protocols | Data & Privacy | How do you handle and protect user data, including storage, privacy, and compliance? | Data storage: Supabase (PostgreSQL) hosted on AWS — data encrypted at rest and in transit – User data collected: symptoms, diet logs, supplements, sleep, energy/mood, weight, medical records — all self-reported – AI processing: user logs sent to Anthropic API for pattern analysis – Data deletion: users can request account deletion (manual process during beta; self-serve to be built) Gap: Formal privacy legal review (AU Privacy Act + GDPR-readiness if international users join) before public launch | |||
| Policy & Compliance | Are content moderation, legal, and audit processes in place? Are you compliant with regulations needed for your domain? | – Medical disclaimer: app is a wellness tracking tool, not a medical device. Disclaimer shown at sign-up and on AI output screens. – No diagnostic or prescriptive claims made by the AI — outputs are pattern observations and prompts to discuss with a doctor – Content moderation: not applicable at beta scale (closed, known users; no user-generated public content) – Terms of service: drafted (template). Legal review scheduled – HIPAA: not applicable (Australian product, not US healthcare provider). TGA (AU) classification: not a medical device under current feature set. Gap: Independent legal sign-off on disclaimer language and TGA classification before public launch | ||||
| Define Success Metrics | Success Metrics | User/Business Metrics | What user metrics will indicate success? What business metrics will demonstrate value? | All metrics are recorded in the "Success metrics" sheet and are relevant only to the pilot. They will be updated post pilot: https://docs.google.com/spreadsheets/d/1D7I8ooMcaw2S0N2piRHA2bRT8YBkuGz8BrUpnyTzkuA/edit?usp=sharing | ||
| AI Metrics | How will you measure AI performance and accuracy? | Step 1 — Test library review (manua) Run the 20–30 test cases from the test library. For each one, compare the actual output to the expected output and score pass or fail against the 7 criteria. Record results in a spreadsheet. Step 2 — Adversarial prompt check (manual) Run the adversarial prompts from the test library against the live app. Verify none produce boundary violations. Step 3 — Score and compare Calculate pass rates per criterion. Compare to the previous run. Flag any regressions — criteria that scored lower than last time. | ||||
| Monitor, Iterate & Improve | User Support & Feedback Plan | Support Channels | Where can users get support? Is escalation and ownership clear? | Support emails being setup for escalation. Ownership currently only with founder. For the closed pilot - emails and Whatsapp will be the escalation paths. | ||
| Feedback Workflow | How do you gather, triage, and act on feedback and bugs? How are critical issues prioritized and communicated? | – Pilot user logs friction points and observations in a running notes doc after each use session – Weekly review with founder: categorise by severity (blocker / UX friction / nice-to-have) – Blockers fixed within the week; UX items queued in Lovable project board | ||||
| Monitoring & Continuous Improvement | Monitoring Approach | What monitoring/logging is in place to spot operational/AI issues post-launch? | Supabase admin dashboard created to track success metrics. All issues recorded in pilot will be recorded on a spreadsheet and prioritised. | |||
| Ongoing Improvement | How will you collect learnings, review performance, and update your system continuously post-launch? | - All feedback will be recorded in a spreadsheet. - Bi-weekly review of all feedback - Prioritised feedback items to be actioned within the week | ||||
