会議取り込み
1つのトランスクリプトを、ソースが明示された会議ページ、更新されたエンティティプロファイル、構造化されたクレームに変換し、それらを検証します。各ステップに必要な場合にのみリファレンスを参照してください。
- セットアップ: 常に、最初に（ステータス、オントロジー、検索）
- ソース取得: API（Granolaを含む）からの取得
- ソース: オリジナルの保持、引用形式
- スピーカー: 分割、重複、不明瞭なスピーカーの可能性
- 同一性: 人物、企業、プロジェクトの解決
- ライティング: ページのプローズを書く前に
- 会議ページ: 会議ページの作成
- プロファイル: プロファイルの作成または更新
- アサーション: クレーム、出席エッジ、再実行
- 公開: バッチまたはページ単位の書き込み
- リカバリ: 不確実、拒否、または競合する書き込み
- 検証: 検証とレポート
契約
- 実際の会議ごとに1ページ。完全なトランスクリプトを保持すること。レコーダーの要約はクレームであり、事実ではありません。
- スピーカーは、証拠に基づいて信頼度とともに解決され、推測は禁止です。あらゆる実際のシグナルを使用し、スピーカーラベルを解決できない場合のみ未解決のままにします。
- すべての参加者（発言した、話しかけられた、またはその他の方法で参加した）は、タイムライン行と出席エッジを持つプロファイルを取得します。招待リストのみに記載された名前は対象外です。
- 会議で実質的な言及があった企業、プロジェクト、コンセプトはすべて、ページ（発見または作成）、タイムライン行、双方向リンクを取得します。簡単な言及は対象外です。
- ページは優れた人間のメモのように読みやすくする：名前を先に、注釈は最小限に、プロセスに関するコメントは含めない。
- 決定、コミットメント、イベントはクレームになります。未検証のクレームは他のページに広がりません。
- 検証が通過するまでは、会議が完全に取り込まれたとは見なさないでください。
ステップ
1. 取得と正規化
完全なトランスクリプトを取得します。空、要約のみ、または進行中の入力はこのステップを失敗とし、報告します。ユーザーがメモの保存のみを希望する場合は、knowledge-captureを使用し、会議取り込みは完了していないと伝えます。
作業コンテキストで以下のように正規化：source、source_id、title、date、time、duration、attendees（ソースの主張）、ordered segments（speaker、speaker_raw、textを含む）、source_summary、URL。不明な値はnull。レコーダー固有の処理はここで終了。以降はすべてのレコーダーが同じステップを実行します。
元のエクスポートとトランスクリプトを保持します（ソース）。正規化されたテキストはラベル付き派生作品です。取得、保持、公開を別々に、実際の数で報告します（「9/16のオリジナルを保持」）。
正規化されたトランスクリプトを約150行のセクションで一度だけ読みます。各セクションの後、作業用ダイジェストファイルに行範囲、発言者、トピック、候補となる決定事項、コミットメント、事実（正確な行引用付き）、引用候補、新しい固有名詞を追加します。後のステップはダイジェストからドラフトを作成します。トランスクリプトに戻るのは特定の行範囲のみ（表現や引用の確認のため）、全文の再読み込みは禁止です。
完了条件： 完全なトランスクリプトが保持されている。証拠の受領書がある。ダイジェストがすべての行をカバーしている。
2. 分割、重複排除、スピーカーの解決
複数会議の録音、この会議の既存ページ、スピーカーマップを確認します（スピーカー）。
完了条件： 各実際の会議にそのセグメント範囲が割り当てられている。重複が発見された。すべてのスピーカーラベルがマッピングされるか、明示的に未解決で、その根拠がある。
3. 各クレームのゲートチェック
提案されたすべてのアサーションを、トランスクリプトおよび同じエンティティに関する既存のKnowledgeと照らし合わせてチェックします。
- 役割または関係：暗黙の示唆ではなく、明示的な記述が必要。
- 所有権：明示的な所有権の表現。名前を挙げただけでは所有とはみなさない。
- 新しい固有名詞：Knowledgeを検索し、許可されていればウェブも検索して正規の綴りを確認。それ以外の場合は
Name (unverified spelling)として書き、ページやリンクは付与しない。 - 主要な人生または取引イベント：逐語的な裏付けが必要。既存の年表と照合すること。
トランスクリプトの裏付けだけでは不十分です。以下の点もチェック：
- 矛盾： Knowledgeが既に確立していることと矛盾しないか？デフォルトでは既存のコンテンツが優先されます。矛盾するクレームをプロファイルに書き込まず、会議ページに両方の引用とともに保持し、ユーザーが解決するためにレポートにリストします。明示的で逐語的な裏付けがある場合のみ上書きし、それでも変更を報告します。
- 妥当性： 他の既知の情報から考えて可能か？（同じプロジェクトを2人が同時に開始することはできない、昨年設立された会社が5年前に買収されることはない）。不可能性は通常、誤認識を意味します。
- 驚き： ユーザーが「え、何？」と思うであろう場合、あらゆるチェックを適用します。驚きを質問として表面化し、説明してごまかさない。
推論や不確かな同一性は、会議ページ上でラベル付けされたままにし、事実としてプロファイル、タイムライン、メタデータ、関係に入力しない。
完了条件： 各クレームが「公開」「不確かとしてラベル付け」「保留」のいずれかにマークされている。
4. 公開
順序：会議ページ → エンティティページ → クレームとエッジ → リンク編集。関連レコードをバッチ処理します（公開）。
- 会議ページに従って会議ページを作成。
- 各参加者および実質的エンティティについて、
knowledge-entitiesのSKILL.mdの手順に従う：エンティティを解決し、ページを取得するかどうかを判断し、プロファイルとタイムライン行を作成します。このスキルと同じ名前のリファレンスは同一コピーであり、既に読んだものを使用し、再読み込みは不要です。追加のリファレンスはエンリッチメントのみ（「取り込み中」セクションを読むこと）。 - アサーションに従ってクレームを作成：決定、コミットメント、事実、および会議自体のための
source_event: trueの1つのイベント（関連するすべてのentitiesを含む）。他のイベントは独自の日付を保持します。 - 参加者ごとに、証拠に基づく
attended関係。出荷オントロジーでは、参加者 → 会議の方向で実行されます。定義を確認し、source_pageを設定します。 - 言及された人物でページを持つものにはリンクも付与します。不明なスピーカーに対してページを作成しない。
- 法的または個人的なコンテンツについては、会議ページを事実に基づくものに保ち、プロファイルへの拡散を制限します。範囲が不明な場合は質問します。
完了条件： 計画されたすべてのレコードが作業ログに公開済みの受領書を持っている。
5. 検証（ハードゲート、すべての会議）
最初に検証を実行します。次に以下をチェック：
- 内容： 必須セクションにコンテンツまたはソースに基づく理由がある。
- リンク：
knowledge_verifyのexpectedLinksに、会議 ↔ 各エンティティ、およびクレームのentities/dependencies、コミットメントのowner、エッジのfrom/to/label/source_pageが含まれていること。リンクされたすべてのプロファイルに、この会議のタイムライン行がある。 - 状態： 更新されたプロファイルに、日付や会議にちなんだ名前のStateトピックがない。
- 文体： 作業ファイル内のドラフトをライティングと照らし合わせて公開前にチェック：名前を先に、注釈の積み重ねなし、自分へのメモなし、埋め草の行なし。公開されたページを文体チェックのために読み返さない。修正後は変更したセクションのみを再読。
- スピーカー： 生のラベルが既知の人物として通過しない。スピーカーの偽造参加者チェックを実行。
- 引用： 引用されたスパンの行を
knowledge_evidence_readで読む。フィラー（「みたいな」「つまり」）のみが異なっていてもよい。失敗した引用は、実際の発言に戻すか、よりきれいなスパンを選んで修正。パラフレーズを引用に保持しない。 - 順序： 語られた順序（前/中/後、場所、人）をタイムスタンプと比較し、見出しの順序とは独立してチェック。
knowledge_chronicle_day（会議の日付とタイムゾーン）およびknowledge_timelineを関連エンティティに使用。逆転や不可能な場所/時間は矛盾とみなす。移動を捏造しない。修正して再チェックするか、明示的なユーザーによる放棄をWAIVED（解決済みではない）として記録。放棄は順序のみをカバー。その日の年表から参加者が欠落している場合は、通常はタイムライン行の欠落を意味するため、調査はするがブロックはしない。真に曖昧な順序はレポートにフラグを立て、ブロックはしない。
完了条件： すべてのチェックが通過するか、失敗が修正されて再チェックされた。
レポート
会議ごとに1行（分割録音の場合はページごとに1行）：ページ、保持されたソース、エンリッチされた参加者、更新または再利用されたエンティティ、アクションアイテム、クレームとエッジ、検証結果、順序PASSまたはWAIVED（未解決の矛盾付き）。既存のKnowledgeとの矛盾、保留されたクレーム、未解決の同一性、残作業をここ（レポート内）にリストし、ページには記載しない。ユーザーが解決します。チェックが通過できない場合、その会議を取り込み未完了として報告し、チェック名を挙げます。部分的なレポートは完了ではなく、正直な進捗です。