Allt du tar in leder till en enda plats — dig. Det här dokumentet beskriver appen som kartlägger den platsen: vad den är, hur den är byggd, och hur kunskapen är strukturerad.
Vad appen är till för, och liknelsen den vilar på.
Appen hjälper människor att förstå vad som faktiskt händer i kroppen när de äter och dricker. Den jämför substanser i mat och dryck och förklarar, begripligt och vederhäftigt, hur de samverkar i magen och kroppen — vad som skapar obehag, vad som påverkar näringsupptag, vad som krockar med mediciner.
Målet är inte att döma eller skrämma, utan att göra osynliga processer synliga. När en användare förstår sin egen kropp kan hen motverka risker, lindra obehag och lösa vardagsproblem innan de uppstår. Kort sagt: hjälpa människor att må bättre genom att förstå mer.
Det sker genom fyra roller. Avkodaren förklarar vad som händer just nu. Detektiven hittar dina personliga mönster och triggers. Vakten varnar för risker och interaktioner. Coachen hjälper dig i förväg. Fyra roller — men ett och samma svar i botten, eftersom alla läser ur samma karta.
Hur plattformen är byggd — kärnan, rollerna, de fem lagren och vägen framåt.
Avkodaren, Detektiven, Vakten och Coachen är inte fyra appar — de är fyra roller som läser samma karta. Mellan rollerna och kärnan ligger ett lager av logik och intelligens som översätter rådata till begripliga, säkra svar.
Stommen byggs först — kärnan fylls sedan.
Vad händer i mig?
Hitta dina triggers
Hjälp innan obehaget
Risker & interaktioner
Din ursprungliga stack är intakt — den utgör lager IV. Tre nya lager läggs till: kärnan själv, logiken som tolkar den, och förvaltarytan som Sabina arbetar i.
Plattformens kronjuvel — kartan över Rom, den modell av kroppen som allt annat vilar på. Substanser, livsmedel och drycker, deras interaktioner, kontraindikationer, kroppens processer, symtom och de mekanismer som förklarar varför. Varje post är versionerad med utkast/publicerat-status, källhänvisad och spårbar. Detta är inte kod — det är data, och behöver sin egen historik skild från GitHub.
Lagret som översätter kärnans data till svar. Avgörande nyans: Vaktens kontroller måste vara deterministiska, spårbara regler — aldrig en fritt resonerande AI, eftersom en hallucination i hälsosammanhang är oacceptabel. AI får driva förklaring och ton, men aldrig riskbedömning.
Avkodaren, Detektiven, Vakten och Coachen. Inga separata system — bara fyra vyer mot samma motor. En användare kan vandra mellan dem utan att lämna appen. Rollerna kan släppas en i taget; kärnan och logiken är gemensamma.
Plattformen är tvåsidig. Användarappen är det folk laddar ner. Förvaltarkonsolen är det Sabina faktiskt arbetar i — en no-code-yta för innehåll, ton och kunskap, byggd så att hon kan förvalta utan att kunna bryta systemet. Det här lagret saknades helt i den första skissen och är navet i hela överlämningsplanen.
Byggkedjan är oförändrad: AI/Cursor → GitHub → Vercel → Cloudflare. Supabase bär databas och autentisering — nu med EU-region och Row Level Security från dag ett. Kritisk logik flyttas till Edge Functions. Zapier behålls, men endast för icke-kritisk glue: e-post, sms, CRM. Aldrig kärnlogik.
Vissa krav bor inte i ett lager utan löper genom hela arkitekturen. De måste byggas in från start — de går inte att lägga till efteråt.
Inget hälsopåstående går live utan granskning. Utkast/publicerat-status, godkännandesteg och fullständig ändringshistorik. Skyddar användaren, Sabina och dig.
Symtom, mediciner och diagnoser är särskild kategori under GDPR. EU-region, dataminimering, uttryckligt samtycke och RLS är inte tillval utan utgångsläge.
GitHub, Vercel, Cloudflare, Supabase och domänen ligger i org-konton — aldrig privata. Då blir överlämningen till Sabina ett ägarbyte, inte en migrering.
100 % är en sund, byggbar arkitektur. Här är de tio procent som gör den trovärdig, försvarbar och värd mer än summan av sina delar.
Varje fakta i kärnan bär en källa och en konfidensnivå. Då kan Vakten citera varför den varnar, Förvaltaren kan granska sak, inte gissning, och appen blir trovärdig i en bransch full av brus. Detta är skillnaden mellan en hälsoapp och en åsiktsapp.
Eftersom appen är bredare än Sabina — och du bygger många appar — exponeras Kunskapskärnan som ett återanvändbart internt API. Den behöver inte tjäna bara den här appen; en framtida produkt kan vila på samma karta över Rom.
Anonymiserade användarutfall matas tillbaka och gör mönstermotorn vassare över tid. Detektiven blir bättre ju fler som använder appen — försiktigt gjort, alltid avidentifierat.
En medveten gräns i arkitekturen där ägande kan bytas utan att något byggs om. Motorn stannar hos teamet, driftsytan går till Sabina. Sömmen ritas in nu — inte den dag den behövs.
Liknelsen håller hela vägen. Vi reser ställningen först — när stommen står, fyller vi kartan med sitt verkliga innehåll. Sist överlämnar vi den färdiga kartan till Sabina.
Din stack är behållen i sin helhet — den var rätt. Tre lager har lagts till: kärnan (lager 0), logiken (lager I) och förvaltarytan (lager III), som alla saknades i den första skissen. Tre tvärgående hänsyn — styrning, efterlevnad, överlämning — har gjorts explicita. Och fyra skärpningar lyfter arkitekturen från sund till försvarbar.
Nästa kapitel beskriver datamodellen för kärnan — de sju objekten i lager 0 och hur de hänger ihop. Det är ritningen som Fas I byggs mot.
Kartans ritning — de objekt kunskapskärnan är byggd av, och hur de hänger ihop.
Det här är datamodellen för kunskapen — inte för användaren. Användarprofil, loggade måltider och loggade symtom är en egen modell, den som Detektiven och Coachen vilar på. Den tar vi separat, så att kartan inte blandas ihop med resenären.
Katalog, inte logg. Objektet Symtom här är definitionen av ett symtom — vad "halsbränna" är. En användares faktiska upplevelse ("kände mig uppblåst kl. 14") är en loggpost i användarmodellen, som pekar tillbaka på katalogen. Samma princip gäller Tillstånd: katalogen bor i kärnan, en persons faktiska diagnoser i profilen.
Varje kunskapspost — alla sju kärnobjekt och båda stödobjekt — bär samma uppsättning fält. Det är inte något man lägger till sedan; det är förutsättningen för granskning, härkomst och en trygg överlämning.
Fälten nedan är ett första utkast — tillräckligt skarpt att bygga mot, öppet nog att vrida på. Metadata-bältet ovan tillkommer på var och en och upprepas inte här.
Den kemiska aktören — atomenheten i hela modellen. Koffein, citronsyra, kapsaicin, etanol, laktos, histamin, en aktiv läkemedelssubstans.
Det verkliga objektet en person tar in — dörren in till Rom. Kaffe, en tomat, mjölk, ibuprofen, sojasås.
En fysiologisk process eller plats — var något händer i Rom. Magsyrasekretion, järnupptag i tunntarmen, CYP3A4-metabolism i levern.
Appens hjärta — en effekt. En substans påverkar en kroppsprocess, eller en annan substans.
En flaggad risk-regel för en person — det Vakten läser. Skild från Interaktion: ett faktum blir en regel först i en personlig kontext.
En upplevd erfarenhet — vad du känner. Halsbränna, uppblåsthet, skakighet, energisvacka. Detta är katalogen, inte en loggad upplevelse.
Den begripliga "varför" — Avkodarens innehåll. En återanvändbar, källhänvisad och granskad text.
Beslut 2 sa: interaktioner modelleras på substansnivå. Det fungerar bara om det finns en bro mellan det användaren känner igen och det kemin handlar om.
En kopplingstabell: vilket Intag som innehåller vilka Substanser, och i vilken mängd. Det är här appen översätter "kan jag ta detta med mjölk?" till substansnivå — och härleder interaktioner på intagsnivå utan att samma fakta matas in om och om igen.
Ryggraden är ett flöde: från det du tar in, genom det som händer, till det du känner. Kontraindikationen grenar av som en regel; Tillståndet ger den sin kontext.
Tvärsöver, utanför ryggraden: Förklaring kopplas till Interaktion, Kroppsprocess, Symtom och Kontraindikation — den begripliga "varför". Källa underbygger varje enskild post, och kopplingen bär konfidensnivån. Dessa två ritas inte in i flödet ovan eftersom de rör allt.
Källa flaggade jag redan när vi skissade kärnan. Tillstånd dök upp när vi designade kontraindikationen — den behöver något att peka på. Inget av dem stod i den ursprungliga sjuan, och båda lyfts därför fram här, inte tyst inbakade.
Härkomsten bakom ett faktum. Kan inte vara ett textfält — en källa backar många poster och granskas separat.
Katalogen över tillstånd en kontraindikation kan gälla. Katalog, inte profil — en persons faktiska diagnoser bor i användarmodellen.
Diagrammet visar berättelsen. Här står alla kopplingar uttryckligen, så ingenting lämnas till tolkning.
Mat och medicin är ett objekt — Intaget, med en kategori. De interagerar i kroppen, och just den interaktionen är poängen.
Interaktioner modelleras på substansnivå — intagsnivån härleds via Innehåll.
Interaktionens mål är flexibelt — kroppsprocess eller substans, exakt ett.
Interaktion och kontraindikation hålls isär — fysiologiskt faktum mot personlig regel.
Förklaring är ett eget objekt — källhänvisad, granskad, versionerad.
Läkemedel ryms i Intaget, men kan behöva egna fält. Dosform, receptstatus och doseringsregler beter sig inte som en tomat. Beslutet att hålla mat och medicin i ett objekt står — men hur läkemedelskategorin ska bära sina särdrag är medvetet skjutet framåt, och tas upp innan kärnan fylls på djupet i Fas II.
Kärnans ritning står. Det naturliga nästa steget är användarmodellen — profil, loggade måltider och loggade symtom — den som Detektiven och Coachen vilar på, och som pekar tillbaka in i den här katalogen. Därefter regelmotorns logik.