knowledge-meeting-ingest

Ingestion de réunion

Transformer une transcription en une page de réunion sourcée, des profils d'entités mis à jour et des revendications structurées, puis les vérifier. Ne lire une référence que lorsque son étape en a besoin :

• configuration : toujours, en premier (statut, ontologie, recherche)
• acquisition de source : récupération depuis une API, y compris Granola
• sources : conservation des originaux ; format de citation
• intervenants : répartition possible, intervenant en double ou peu clair
• identité : résolution d'une personne, entreprise ou projet
• rédaction : avant d'écrire une prose de page
• page de réunion : rédaction de la page de réunion
• profils : création ou mise à jour d'un profil
• assertions : revendications, arêtes de présence, relances
• publication : écritures par lot ou par page
• récupération : toute écriture incertaine, rejetée ou conflictuelle
• vérification : vérification et rapport

Contrat

• Une page par réunion réelle. Conserver la transcription complète ; les résumés des enregistreurs sont des revendications, pas des faits.
• Les intervenants sont résolus sur la base de preuves avec un niveau de confiance, jamais devinés. Utiliser chaque signal réel ; ne laisser un intervenant non résolu qu'en l'absence de tout signal.
• Chaque participant (a parlé, a été interpellé, ou a autrement participé) reçoit un profil avec une ligne de chronologie et une arête de présence. Les noms figurant uniquement sur la liste d'invitation n'obtiennent ni l'un ni l'autre.
• Toute entreprise, projet ou concept dont la réunion dit quelque chose de substantiel obtient une page (trouvée ou créée), une ligne de chronologie et des liens dans les deux sens. Les mentions passagères n'en obtiennent pas.
• Les pages ressemblent à de bonnes notes humaines : les noms en premier, peu d'exceptions, pas de commentaires de processus.
• Les décisions, engagements et événements deviennent des revendications. Les revendications non vérifiées ne se propagent pas vers d'autres pages.
• Ne jamais qualifier une réunion d'entièrement ingérée tant que la vérification n'est pas réussie.

Étapes

1. Acquérir et normaliser

Obtenir la transcription complète. Une entrée vide, avec résumé uniquement ou en cours échoue à cette étape : le signaler. Si l'utilisateur souhaite uniquement sauvegarder des notes, utiliser knowledge-capture et dire que l'ingestion de la réunion n'est pas complète.

Normaliser dans le contexte de travail en : source, source_id, titre, date, heure, durée, participants (revendications de la source), segments ordonnés avec speaker, speaker_raw et text, résumé de la source, URL. Les valeurs inconnues sont null. Le traitement spécifique à l'enregistreur s'arrête ici ; chaque enregistreur exécute les mêmes étapes après cela.

Conserver l'export original et la transcription (sources). Le texte normalisé est un dérivé étiqueté. Signaler l'acquisition, la conservation et la publication séparément, avec des chiffres réels ("9/16 originaux conservés").

Lire la transcription normalisée une fois, par sections d'environ 150 lignes. Après chaque section, ajouter à un fichier de synthèse de travail : la plage de lignes, qui a parlé, les sujets, les décisions candidates, les engagements et les faits avec des citations de lignes exactes, des candidats aux citations, et de nouveaux noms propres. Les étapes ultérieures rédigent à partir de la synthèse. Revenir à la transcription uniquement pour des plages de lignes spécifiques (pour vérifier le libellé ou une citation), jamais pour une relecture complète.

Terminé quand : transcription complète conservée ; reçus de preuves en main ; la synthèse couvre chaque ligne.

2. Diviser, dédupliquer, résoudre les intervenants

Vérifier s'il s'agit d'un enregistrement multi-réunions, d'une page existante pour cette réunion, et de la carte des intervenants (intervenants).

Terminé quand : chaque réunion réelle a sa plage de segments ; les doublons sont trouvés ; chaque étiquette d'intervenant est mappée ou explicitement non résolue, avec justification.

3. Contrôler chaque revendication

Vérifier chaque assertion proposée par rapport à la transcription et aux connaissances antérieures sur la même entité.

• Rôle ou relation : passage explicite, pas d'implication.
• Propriété : langage explicite de propriété ; mentionner un nom n'est pas le posséder.
• Nouveau nom propre : rechercher dans Knowledge, puis sur le web si autorisé, l'orthographe canonique ; sinon l'écrire comme Nom (orthographe non vérifiée) et ne lui donner ni page ni lien.
• Événement majeur de vie ou d'affaires : support textuel vérifié par rapport à la chronologie existante.

Le support de la transcription ne suffit pas à lui seul. Vérifier également :

• Contradiction : cela entre-t-il en conflit avec ce que Knowledge établit déjà ? Le contenu établi l'emporte par défaut. Ne pas écrire la revendication conflictuelle dans les profils ; la conserver sur la page de réunion avec les deux citations et la lister dans le rapport pour que l'utilisateur la résolve. Ne remplacer qu'avec un support textuel explicite, et signaler quand même le changement.
• Plausibilité : est-ce possible compte tenu de ce qui est déjà connu ? (Deux personnes ne peuvent pas avoir toutes les deux démarré le même projet ; une entreprise fondée l'année dernière n'a pas été acquise il y a cinq ans.) Une impossibilité signifie généralement un charabia.
• Surprise : si l'utilisateur dirait "attends, quoi ?", appliquer toutes les vérifications. Faire remonter la surprise comme une question ; ne pas l'expliquer.

Les inférences et les identités incertaines restent étiquetées sur la page de réunion et n'entrent jamais dans les profils, les chronologies, les métadonnées ou les relations comme des faits.

Terminé quand : chaque revendication est marquée comme publier, étiqueter comme incertain ou retenir.

4. Publier

Ordre : page de réunion → pages d'entités → revendications et arêtes → modifications de liens. Regrouper les enregistrements connexes (publication).

• Page de réunion selon page de réunion.
• Pour chaque participant et entité substantielle, suivre les étapes du SKILL.md de knowledge-entities : il résout l'entité, décide si elle reçoit une page, et écrit le profil et la ligne de chronologie. Ses références avec les mêmes noms que ce skill sont des copies identiques ; utiliser celles que vous avez déjà lues et ne pas les relire. Sa seule référence supplémentaire est l'enrichissement (lire sa section "Pendant l'ingestion").
• Revendications selon assertions : décisions, engagements, faits et un événement source_event: true pour la réunion elle-même, avec toutes les entities pertinentes. Les autres événements conservent leurs propres dates.
• Une relation attended avec preuve par participant. Dans l'ontologie livrée, elle va du participant vers la réunion ; confirmer dans la définition. Définir source_page.
• Les personnes mentionnées avec des pages reçoivent également des liens. Ne pas créer de pages pour les intervenants inconnus.
• Pour le contenu juridique ou personnel, garder la page de réunion factuelle et limiter la diffusion aux profils ; demander si la portée est floue.

Terminé quand : chaque enregistrement prévu a un reçu de publication dans votre journal de travail.

5. Vérifier (passage obligatoire, toutes les réunions)

Exécuter d'abord vérifier. Puis vérifier :

• Fond : les sections obligatoires ont du contenu ou une raison fondée sur la source.
• Liens : knowledge_verify expectedLinks pour la réunion ↔ chaque entité, plus entities/dependencies des revendications, owner de l'engagement, et from/to/label/source_page des arêtes. Chaque profil lié a une ligne de chronologie pour cette réunion.
• État : aucun profil mis à jour n'a de sujet State nommé d'après une date ou une réunion.
• Style : vérifier les brouillons dans vos fichiers de travail par rapport à rédaction avant de publier : les noms en premier, pas d'exceptions empilées, pas de notes pour vous-même, pas de lignes de remplissage. Ne pas relire les pages publiées pour vérifier le style ; après une correction, ne relire que la section que vous avez modifiée.
• Intervenants : aucune étiquette brute ne passe pour une personne connue ; exécuter la vérification des participants fabriqués dans intervenants.
• Citations : lire chaque plage de lignes citée avec knowledge_evidence_read. Seuls les mots de remplissage ("genre", "tu vois") peuvent différer. Corriger une citation défaillante en restaurant les mots prononcés ou en choisissant une plage plus propre ; ne jamais conserver une paraphrase dans une citation.
• Séquence : comparer l'ordre narratif (avant/pendant/après, lieux, personnes) avec les horodatages, indépendamment de l'ordre des titres. Utiliser knowledge_chronicle_day (date et fuseau horaire de la réunion) et knowledge_timeline pour les entités connexes. Une inversion ou un lieu/une heure impossible est une contradiction ; ne jamais inventer de transit. Corriger et revérifier, ou enregistrer une dérogation explicite de l'utilisateur comme WAIVED, pas résolue. Une dérogation ne couvre que la séquence. Un participant manquant dans la chronique du jour signifie généralement une ligne de chronologie manquante : enquêter, ne pas bloquer. Un ordre véritablement ambigu est signalé dans le rapport, pas bloqué.

Terminé quand : toutes les vérifications réussissent, ou les échecs sont corrigés et revérifiés.

Rapport

Une ligne par réunion (une par page pour un enregistrement divisé) : page, sources conservées, participants enrichis, entités mises à jour ou réutilisées, éléments d'action, revendications et arêtes, résultat de vérification, séquence PASS ou WAIVED avec la contradiction ouverte. Lister les contradictions avec les connaissances existantes, les revendications retenues, les identités non résolues et le travail restant ici, dans le rapport, pas sur les pages ; l'utilisateur les résout. Si une vérification ne peut pas passer, signaler la réunion comme non ingérée et nommer la vérification. Un rapport partiel est un progrès honnête, pas un achèvement.