Extraction Schema

Principe

Le modèle lit chaque Entrée et en extrait des valeurs typées, rangées par catégorie. Chaque catégorie définit des KPI canoniques — les informations attendues à intervalle régulier — plus un espace « en vrac » pour tout ce qui est dit mais ne rentre dans aucun KPI.

• TypeChaque valeur porte un type : heure-horloge durée (h:mm) nombre booléen ordinal étiquette texte.
• DateLe modèle utilise la date & heure de saisie de l'Entrée, mais respecte une date de référence différente si le texte la précise (« hier soir », « cette nuit »…).
• DéfautUne information non fournie reste « Non renseigné » — jamais de valeur inventée ni de « non » implicite.
• TraçableChaque valeur extraite garde le lien vers son Entrée source et l'extrait exact du texte (boîte de verre).

🧭Conventions transverses

Maquette — encart de résolution (design proposé) :

{
  "version": "2.0",
  "meta": {
    "lastRunAt": "2026-07-06T15:04:00Z",   // date du Run (traçabilité)
    "model": "claude-fable-5",              // modèle réellement utilisé
    "processedThrough": 1751790000000       // repère incrémental : entrées créées/éditées après → à retraiter
  },
  "releves": [
    { "id": "r_0001",
      "kpi": "sleep.bedTime",               // catégorie.KPI canonique (registre des KPI)
      "value": "21:40",                     // typée selon le KPI : "HH:MM" | nombre | booléen | étiquette
      "day": "2026-07-06",                  // journée d'affectation (frontière réveil→réveil)
      "entryId": "e_123",                   // traçabilité boîte de verre
      "quote": "couchée vers 21h40",        // extrait exact du texte source
      "confidence": 0.95 }
  ],
  "vrac": [                                  // ce qui ne rentre dans aucun KPI
    { "id": "r_0002", "category": "sleep", "text": "rêves intenses",
      "day": "2026-07-06", "entryId": "e_123", "quote": "des rêves intenses toute la nuit" }
  ],
  "conflicts": [                             // déclarations contradictoires → sollicitation de résolution
    { "kpi": "sleep.duration", "day": "2026-07-06",
      "releveIds": ["r_0010", "r_0011"], "status": "pending" }   // pending | resolved
  ],
  "unusable": ["e_456"]                      // entrées photo/audio inexploitables, exclues des analyses
}

Notes : les KPI à valeur par défaut (ex. « Envie de manger entre les repas » = Non) ne génèrent pas de relevé — le défaut est appliqué par l'app à la lecture. Le Poids est stocké en Δ (jamais l'absolu). Les relevés impliqués dans un conflict pending sont ignorés par le Récap et les corrélations.

Photos & audio (09/07/2026) : les entrées peuvent porter une photo (scan, résultat d'analyse, assiette…) et/ou une note audio enregistrée dans l'app. Le Run les lit dans la mesure du possible : ce qui est extractible devient des relevés normaux (mêmes règles de KPI, quote = description de la source, ex. « [photo] tension 12/8 » ou transcription de l'audio). Si le média n'est pas exploitable (illisible, hors sujet, inaudible), l'id de l'entrée est ajouté à la liste unusable — le Journal affiche alors sur l'entrée « Donnée inexploitable, exclue des analyses » après le Run.

🌙Sommeil

Cinq KPI attendus chaque nuit, plus les infos en vrac. Une nuit est rattachée au matin où elle se termine (clé = date du réveil).

• HeuresHeures de sommeil : si donnée (« j'ai dormi 7h »), prise telle quelle ; sinon réveil − coucher. Libellé unique « Heures de sommeil », sans mention « estimée » — une valeur calculée se lit comme le nombre d'heures au lit.
• RéparateurJamais dérivable (subjectif) → toujours demandé le matin.

🍽️Alimentation

L'occurrence ici = la prise alimentaire (chaque repas/snack = une ligne), avec des agrégats du jour au-dessus.

• Fadi/DidiFadi = « facile à digérer », Didi = « difficile à digérer ». Chaque prise alimentaire doit porter l'un des deux. Aujourd'hui = ta déclaration ; en v3, le modèle le déduira du contenu de l'assiette selon tes critères. Asymétrie déclarée (Fadi inerte, Didi = le signal) : voir le registre User Beliefs.

🏃Activité

Le modèle lit ta description et décide si l'activité compte comme Sport (avec transpiration) ou Mouvements (cœur qui monte sans transpirer : danse, yoga…).

👥Social

🌡️Climat

Pour l'instant = ta déclaration v3 : météo automatique via localisation. Humidité retirée pour l'instant (06/07).

🩺Symptômes

Tous en oui / non, du jour. Chaque symptôme = une sollicitation distincte, qui ne disparaît qu'une fois renseignée. Défaut = « Non renseigné » — jamais de « non » implicite. Synonymes déclarés : un booléen peut porter un vocabulaire qui mappe des mots vers oui/non — ex. Faim entre les repas : « faim » → oui · « pas faim », « satiété » → non (registre complet : § Vocabulaire). Valeur par défaut : un KPI peut en déclarer une (registre User Beliefs ; NA = aucune) — ex. « Envie de manger entre les repas » = Non par défaut. Absorbe l'ex-Énergie (« Fatiguée »), l'ex-Douleur (« Douleurs ») et l'ex-Brouillard mental (« Brain fog »).

🙂Humeur

⚖️Poids

Nouvelle catégorie v2. Discrétion : seules les variations depuis le jour 0 sont stockées et affichées (jamais de chiffre absolu à l'écran).

📖Règles de vocabulaire d'extraction

Registre des mappings mots → valeur typée que le modèle applique à chaque Run. Un KPI (booléen ou autre) peut porter des synonymes déclarés ; cette liste est injectée dans la consigne de chaque Extract User Data et s'enrichit au fil des validations (source des croyances : User Beliefs).

⏰Planning des sollicitations

Une sollicitation est posée tant que l'info est vide et disparaît une fois renseignée ; elle persiste tant qu'on est dans la journée, puis le trou reste visible dans Données sans être re-posé.

• MatinKPI Sommeil manquants (coucher, réveil, heures, réveils nocturnes) + Sommeil réparateur (toujours). (Colon irritable : retiré le 07/07 — défaut Non.)
• 14hClimat (température ressentie) si vide.
• 19hFatiguée et Humeur — les deux seuls KPI encore sans valeur par défaut à ce créneau (MAJ 07/07 : Eau, Activité, Social et les autres Symptômes ont désormais un défaut → plus jamais vides, plus sollicités).
• Par priseFadi / Didi pour toute prise alimentaire non qualifiée.
• ConflitRésolution de conflit : dès qu'un Run détecte deux déclarations contradictoires du même KPI le même jour (cf. Conventions) — les deux entrées affichées, contradiction en surbrillance, édition proposée.

Les trois niveaux du moteur de sollicitation

Vision : il n'y a pas de problème de données manquantes — l'outil demande à l'utilisateur les données clés dont il a besoin. La sollicitation n'est pas un questionnaire fixe : elle est pilotée par le moteur d'analyse. Trois niveaux, tous en v2.

• Niveau 1Règles fixes — le planning ci-dessus (matin / 14h / 19h / par prise). Couvre les KPI canoniques : si l'utilisateur répond, il n'y a structurellement plus de manquants sur les KPI.
• Niveau 2Sollicitation pilotée par les analyses — à chaque Run All Correlations, le moteur sait ce qui lui manque (paires « données insuffisantes », règles candidates bloquées à petit n, facteurs dont les trous coûtent le plus d'analyses). Il produit, en plus de la base de corrélations, une liste de besoins : fichier data-needs_<id>.json, lu par l'app, affiché comme sollicitations priorisées par valeur d'information (ex. « il manque surtout Climat — 7 trous sur 14 j — ça bloque 12 analyses »).
• Niveau 3Questions conditionnelles « au bon moment » — pour promouvoir une corrélation candidate, le moteur a besoin d'observations futures des jours où la condition est remplie. Le Run écrit des questions pré-compilées (déclencheur + question + moment) : « SI une prise Didi est loguée aujourd'hui → demander demain matin : colon irritable ? ». L'app les exécute localement (un simple test sur les données du jour, pas d'IA en temps réel). C'est le chaînon qui fait tourner la validation prospective toute seule : chaque corrélation candidate fabrique la collecte qui la confirmera ou l'infirmera.