knowledge-meeting-ingest

Meeting-Erfassung

Ein Transkript in eine mit Quellen versehene Meeting-Seite, aktualisierte Entitätsprofile und strukturierte Behauptungen umwandeln, diese dann verifizieren. Lies eine Referenz nur dann, wenn der Schritt sie benötigt:

• Setup: immer, zuerst (Status, Ontologie, Suche)
• Quellenbeschaffung: Abrufen aus einer API, einschließlich Granola
• Quellen: Originale beibehalten; Zitierformat
• Sprecher: mögliche Teilung, Duplikat oder unklarer Sprecher
• Identität: Auflösen einer Person, eines Unternehmens oder Projekts
• Schreiben: vor dem Schreiben von Prosa auf einer Seite
• Meeting-Seite: Schreiben der Meeting-Seite
• Profile: Erstellen oder Aktualisieren eines Profils
• Behauptungen: Claims, Teilnahme-Kanten, Wiederholungen
• Veröffentlichen: Batch- oder Seiten-Schreibvorgänge
• Wiederherstellung: Unsichere, abgelehnte oder widersprüchliche Schreibvorgänge
• Verifizieren: Verifikation und Bericht

Vertrag

• Eine Seite pro tatsächlichem Meeting. Das vollständige Transkript beibehalten; Zusammenfassungen des Aufzeichnungstools sind Behauptungen, keine Fakten.
• Sprecher werden anhand von Beweisen mit einer Konfidenz aufgelöst, niemals geraten. Jedes reale Signal nutzen; einen Sprecher nur dann unaufgelöst lassen, wenn es kein Signal gibt.
• Jeder Teilnehmer (hat gesprochen, wurde angesprochen oder hat anderweitig teilgenommen) erhält ein Profil mit einem Zeitleisten-Eintrag und einer Teilnahme-Kante. Nur auf der Einladungsliste stehende Namen erhalten beides nicht.
• Jedes Unternehmen, Projekt oder Konzept, über das das Meeting etwas Substanzielles sagt, erhält eine Seite (gefunden oder erstellt), einen Zeitleisten-Eintrag und Links in beide Richtungen. Flüchtige Erwähnungen nicht.
• Seiten lesen sich wie gute menschliche Notizen: zuerst die Namen, wenige Einschränkungen, keine Prozesskommentare.
• Entscheidungen, Verpflichtungen und Ereignisse werden zu Claims. Nicht verifizierte Claims verbreiten sich nicht auf andere Seiten.
• Ein Meeting erst dann als vollständig erfasst bezeichnen, wenn die Verifikation bestanden ist.

Schritte

1. Erfassen und normalisieren

Das vollständige Transkript holen. Leere, nur zusammenfassende oder in Bearbeitung befindliche Eingaben scheitern an diesem Schritt: dies melden. Wenn der Benutzer nur Notizen speichern möchte, knowledge-capture verwenden und mitteilen, dass die Meeting-Erfassung nicht vollständig ist.

Im Arbeitskontext normalisieren auf: source, source_id, title, date, time, duration, attendees (Quellenangaben), geordnete Segmente mit speaker, speaker_raw und text, Quellzusammenfassung, URL. Unbekannte Werte sind null. Aufzeichnungsspezifische Behandlung endet hier; jeder Aufzeichnungsdienst durchläuft danach die gleichen Schritte.

Den ursprünglichen Export und das Transkript aufbewahren (Quellen). Normalisierter Text ist ein gekennzeichnetes Derivat. Erfassung, Aufbewahrung und Veröffentlichung getrennt melden, mit echten Zählwerten ("9/16 Originale beibehalten").

Das normalisierte Transkript einmal lesen, in Abschnitten von etwa 150 Zeilen. Nach jedem Abschnitt an eine Arbeits-Digest-Datei anhängen: den Zeilenbereich, wer gesprochen hat, Themen, Kandidaten für Entscheidungen, Verpflichtungen und Fakten mit genauen Zeilenzitaten, Zitatkandidaten und neue Eigennamen. Spätere Schritte verfassen auf Grundlage des Digests. Nur für bestimmte Zeilenbereiche zum Transkript zurückkehren (um Formulierung oder ein Zitat zu prüfen), niemals für ein vollständiges erneutes Lesen.

Erledigt, wenn: vollständiges Transkript beibehalten; Beweisbelege vorhanden; Digest deckt jede Zeile ab.

2. Aufteilen, deduplizieren, Sprecher auflösen

Auf eine Aufnahme mit mehreren Meetings, eine bestehende Seite für dieses Meeting und die Sprecherzuordnung prüfen (Sprecher).

Erledigt, wenn: jedes reale Meeting seinen Segmentbereich hat; Duplikate gefunden; jede Sprecherbezeichnung ist zugeordnet oder explizit unaufgelöst, mit Begründung.

3. Jede Behauptung prüfen

Jede vorgeschlagene Behauptung gegen das Transkript und vorhandenes Knowledge über dieselbe Entität prüfen.

• Rolle oder Beziehung: explizite Passage, nicht Implikation.
• Eigentum: explizite Eigentumssprache; die Nennung eines Namens bedeutet nicht, dass man es besitzt.
• Neuer Eigenname: Knowledge durchsuchen, dann bei Erlaubnis das Web, nach der kanonischen Schreibweise; ansonsten als Name (unverified spelling) schreiben und keine Seite oder keinen Link vergeben.
• Wichtiges Lebens- oder Geschäftsereignis: wörtliche Unterstützung, gegen bestehende Chronologie geprüft.

Die Unterstützung durch das Transkript reicht allein nicht aus. Zusätzlich prüfen:

• Widerspruch: Steht es im Konflikt mit dem, was Knowledge bereits festgestellt hat? Etablierter Inhalt gewinnt standardmäßig. Die widersprüchliche Behauptung nicht in Profile schreiben; auf der Meeting-Seite mit beiden Zitaten belassen und im Bericht zur Klärung durch den Benutzer aufführen. Nur mit expliziter, wörtlicher Unterstützung überschreiben, und die Änderung trotzdem melden.
• Plausibilität: Ist es möglich angesichts dessen, was sonst bekannt ist? (Zwei Personen können nicht beide dasselbe Projekt gestartet haben; ein letztes Jahr gegründetes Unternehmen wurde nicht vor fünf Jahren übernommen.) Eine Unmöglichkeit deutet normalerweise auf eine Verunstaltung hin.
• Überraschung: Wenn der Benutzer "Moment, was?" sagen würde, jede Prüfung anwenden. Die Überraschung als Frage darlegen; nicht wegerklären.

Schlussfolgerungen und unsichere Identitäten bleiben auf der Meeting-Seite gekennzeichnet und gelangen niemals als Fakten in Profile, Zeitleisten, Metadaten oder Beziehungen.

Erledigt, wenn: jede Behauptung als veröffentlichen, als unsicher kennzeichnen oder zurückhalten markiert ist.

4. Veröffentlichen

Reihenfolge: Meeting-Seite → Entitätsseiten → Claims und Kanten → Link-Bearbeitungen. Zusammengehörige Datensätze in Batches verarbeiten (Veröffentlichen).

• Meeting-Seite gemäß Meeting-Seite.
• Für jeden Teilnehmer und jede substanzielle Entität den Schritten in knowledge-entities' SKILL.md folgen: es löst die Entität auf, entscheidet, ob sie eine Seite erhält, und schreibt das Profil und den Zeitleisten-Eintrag. Deren Referenzen mit denselben Namen wie in diesem Skill sind identische Kopien; die bereits gelesenen verwenden und nicht erneut lesen. Die einzige zusätzliche Referenz ist die Anreicherung (den Abschnitt "During ingestion" lesen).
• Claims gemäß Behauptungen: Entscheidungen, Verpflichtungen, Fakten und ein source_event: true-Ereignis für das Meeting selbst, mit allen relevanten entities. Andere Ereignisse behalten ihre eigenen Daten.
• Eine mit Beweisen belegte attended-Beziehung pro Teilnehmer. In der ausgelieferten Ontologie verläuft sie von Teilnehmer → Meeting; in der Definition bestätigen. source_page setzen.
• Erwähnte Personen mit Seiten erhalten ebenfalls Links. Keine Seiten für unbekannte Sprecher erstellen.
• Bei rechtlichen oder persönlichen Inhalten die Meeting-Seite sachlich halten und die Verbreitung auf Profile beschränken; bei Unklarheit nachfragen.

Erledigt, wenn: jeder geplante Datensatz einen Veröffentlichungsbeleg im Arbeitsprotokoll hat.

5. Verifizieren (harte Prüfung, jedes Meeting)

Zuerst Verifizieren ausführen. Dann prüfen:

• Inhalt: Erforderliche Abschnitte haben Inhalt oder einen quellenbasierten Grund.
• Links: knowledge_verify expectedLinks für Meeting ↔ jede Entität, plus Claim entities/dependencies, Commitment owner und Kante from/to/label/source_page. Jedes verlinkte Profil hat einen Zeitleisten-Eintrag für dieses Meeting.
• Status: Kein aktualisiertes Profil hat ein State-Thema, das nach einem Datum oder Meeting benannt ist.
• Stil: Die Entwürfe in den Arbeitsdateien vor der Veröffentlichung gegen Schreiben prüfen: zuerst die Namen, keine gestapelten Einschränkungen, keine Notizen an sich selbst, keine Füllzeilen. Veröffentlichte Seiten nicht erneut lesen, um den Stil zu prüfen; nach einer Korrektur nur den geänderten Abschnitt erneut lesen.
• Sprecher: Keine Rohbezeichnung als bekannte Person durchgehen; den Test auf erfundene Teilnehmer in Sprecher ausführen.
• Zitate: Jede zitierte Textspanne mit knowledge_evidence_read lesen. Nur Füllwörter ("ähm", "weißt du") dürfen abweichen. Ein fehlerhaftes Zitat korrigieren, indem die gesprochenen Wörter wiederhergestellt oder eine sauberere Spanne gewählt wird; niemals eine Paraphrase in einem Zitat belassen.
• Reihenfolge: Erzählte Reihenfolge (vor/während/nach, Orte, Personen) mit Zeitstempeln vergleichen, unabhängig von der Überschriftenreihenfolge. knowledge_chronicle_day (Meeting-Datum und Zeitzone) und knowledge_timeline für verwandte Entitäten verwenden. Eine Umkehrung oder unmöglicher Ort/Zeit ist ein Widerspruch; niemals Transit erfinden. Korrigieren und erneut prüfen, oder einen expliziten Benutzerverzicht als WAIVED, nicht als gelöst, aufzeichnen. Ein Verzicht deckt nur die Reihenfolge ab. Ein Teilnehmer, der in der Chronik des Tages fehlt, deutet normalerweise auf einen fehlenden Zeitleisten-Eintrag hin: untersuchen, nicht blockieren. Echte Ambiguität in der Reihenfolge wird im Bericht gekennzeichnet, nicht blockiert.

Erledigt, wenn: alle Prüfungen bestanden sind, oder Fehler korrigiert und erneut geprüft wurden.

Bericht

Eine Zeile pro Meeting (eine pro Seite für eine geteilte Aufnahme): Seite, beibehaltene Quellen, angereicherte Teilnehmer, aktualisierte oder wiederverwendete Entitäten, Aktionspunkte, Claims und Kanten, Verifikationsergebnis, Sequenz PASS oder WAIVED mit dem offenen Widerspruch. Widersprüche mit vorhandenem Knowledge, zurückgehaltene Claims, unaufgelöste Identitäten und verbleibende Arbeit hier im Bericht auflisten, nicht auf den Seiten; der Benutzer löst sie auf. Wenn eine Prüfung nicht bestanden werden kann, das Meeting als nicht erfasst melden und die Prüfung benennen. Ein Teilbericht ist ehrlicher Fortschritt, kein Abschluss.