knowledge-meeting-ingest

Ingestão de Reunião

Transforme uma transcrição em uma página de reunião com fontes, perfis de entidades atualizados e alegações estruturadas, depois verifique-as. Leia uma referência apenas quando sua etapa precisar:

• setup: sempre, primeiro (status, ontologia, pesquisa)
• aquisição de fonte: busca de uma API, incluindo Granola
• fontes: retenção de originais; formato de citação
• falantes: possível divisão, duplicata ou falante não claro
• identidade: resolução de uma pessoa, empresa ou projeto
• escrita: antes de escrever qualquer prosa de página
• página de reunião: escrita da página de reunião
• perfis: criação ou atualização de um perfil
• asserções: alegações, arestas de participação, reexecuções
• publicar: escritas em lote ou por página
• recuperação: qualquer escrita incerta, rejeitada ou conflitante
• verificar: verificação e relatório

Contrato

• Uma página por reunião real. Retenha a transcrição completa; resumos do gravador são alegações, não fatos.
• Falantes são resolvidos por evidência com confiança, nunca adivinhados. Use todo sinal real; deixe um falante não resolvido apenas quando não houver nenhum.
• Todo participante (falou, foi abordado ou participou de outra forma) recebe um perfil com uma linha de Linha do Tempo e uma aresta de participação. Nomes apenas da lista de convite não recebem nem um nem outro.
• Toda empresa, projeto ou conceito sobre o qual a reunião diz algo substantivo recebe uma página (encontrada ou criada), uma linha de Linha do Tempo e links em ambas as direções. Menções passageiras não.
• As páginas são lidas como boas notas humanas: nomes primeiro, poucas ressalvas, nenhum comentário de processo.
• Decisões, compromissos e eventos viram alegações. Alegações não verificadas não se espalham para outras páginas.
• Nunca chame uma reunião de totalmente ingerida até que a verificação passe.

Etapas

1. Adquirir e normalizar

Obtenha a transcrição completa. Entrada vazia, apenas resumo ou em andamento falha nesta etapa: reporte. Se o usuário quiser apenas salvar notas, use knowledge-capture e diga que a ingestão da reunião não está completa.

Normalize no contexto de trabalho para: fonte, source_id, título, data, horário, duração, participantes (alegações da fonte), segmentos ordenados com speaker, speaker_raw e text, resumo da fonte, URL. Valores desconhecidos são nulos. O tratamento específico do gravador termina aqui; todo gravador executa as mesmas etapas depois disso.

Retenha a exportação original e a transcrição (fontes). O texto normalizado é um derivado rotulado. Reporte aquisição, retenção e publicação separadamente, com contagens reais ("9/16 originais retidos").

Leia a transcrição normalizada uma vez, em seções de cerca de 150 linhas. Após cada seção, anexe a um arquivo de resumo de trabalho: o intervalo de linhas, quem falou, tópicos, decisões candidatas, compromissos e fatos com citações de linha exatas, citações candidatas e novos substantivos próprios. Etapas posteriores redigem a partir do resumo. Retorne à transcrição apenas para intervalos de linha específicos (para verificar redação ou uma citação), nunca para uma releitura completa.

Feito quando: transcrição completa retida; recibos de evidência em mãos; resumo cobre cada linha.

2. Dividir, deduplicar, resolver falantes

Verifique se há uma gravação de múltiplas reuniões, uma página existente para esta reunião e o mapa de falantes (falantes).

Feito quando: cada reunião real tem seu intervalo de segmento; duplicatas encontradas; cada rótulo de falante está mapeado ou explicitamente não resolvido, com base.

3. Avaliar cada alegação

Verifique cada asserção proposta contra a transcrição e Conhecimento anterior sobre a mesma entidade.

• Papel ou relacionamento: passagem explícita, não implicação.
• Propriedade: linguagem explícita de propriedade; mencionar um nome não é possuí-lo.
• Novo substantivo próprio: pesquise no Conhecimento, depois na web se permitido, pela grafia canônica; caso contrário, escreva como Nome (grafia não verificada) e não lhe dê página ou link.
• Evento importante de vida ou negócio: suporte textual, verificado contra a cronologia existente.

O suporte da transcrição não é suficiente por si só. Verifique também:

• Contradição: entra em conflito com o que o Conhecimento já estabelece? O conteúdo estabelecido vence por padrão. Não escreva a alegação conflitante nos perfis; mantenha-a na página da reunião com ambas as citações e liste-a no relatório para o usuário resolver. Substitua apenas com suporte explícito e textual, e ainda assim reporte a mudança.
• Plausibilidade: é possível dado o que mais se sabe? (Duas pessoas não podem ter iniciado o mesmo projeto; uma empresa fundada no ano passado não foi adquirida há cinco anos.) Uma impossibilidade geralmente significa uma distorção.
• Surpresa: se o usuário dissesse "espera, o quê?", aplique todas as verificações. Traga a surpresa como uma pergunta; não a explique.

Inferências e identidades incertas permanecem rotuladas na página da reunião e nunca entram em perfis, linhas do tempo, metadados ou relacionamentos como fato.

Feito quando: cada alegação está marcada como publicar, rotular-como-incerto ou reter.

4. Publicar

Ordem: página de reunião → páginas de entidade → alegações e arestas → edições de links. Agrupe registros relacionados (publicar).

• Página de reunião conforme página de reunião.
• Para cada participante e entidade substantiva, siga as etapas no SKILL.md de knowledge-entities: ele resolve a entidade, decide se recebe uma página e escreve o perfil e a linha de Linha do Tempo. Suas referências com os mesmos nomes que as desta habilidade são cópias idênticas; use as que você já leu e não as releia. Sua única referência extra é enriquecimento (leia sua seção "Durante a ingestão").
• Alegações conforme asserções: decisões, compromissos, fatos e um evento source_event: true para a própria reunião, com todas as entities relevantes. Outros eventos mantêm suas próprias datas.
• Um relacionamento attended baseado em evidência por participante. Na ontologia enviada, ele vai de participante → reunião; confirme na definição. Defina source_page.
• Pessoas mencionadas com páginas também recebem links. Não crie páginas para falantes desconhecidos.
• Para conteúdo legal ou pessoal, mantenha a página da reunião factual e limite a propagação aos perfis; pergunte se o escopo não estiver claro.

Feito quando: todo registro planejado tem um recibo publicado em seu registro de trabalho.

5. Verificar (portão rígido, toda reunião)

Execute verificar primeiro. Depois verifique:

• Substância: seções obrigatórias têm conteúdo ou uma razão baseada em fonte.
• Links: knowledge_verify expectedLinks para reunião ↔ cada entidade, mais entities/dependencies de alegação, owner de compromisso e from/to/label/source_page de aresta. Todo perfil vinculado tem uma linha de Linha do Tempo para esta reunião.
• Estado: nenhum perfil atualizado tem um tópico de Estado nomeado por data ou reunião.
• Estilo: verifique os rascunhos em seus arquivos de trabalho contra escrita antes de publicar: nomes primeiro, sem ressalvas empilhadas, sem notas para si mesmo, sem linhas de preenchimento. Não leia páginas publicadas de volta para verificar o estilo; após uma correção, releia apenas a seção que você alterou.
• Falantes: nenhum rótulo bruto passa como pessoa conhecida; execute a verificação de participante fabricado em falantes.
• Citações: leia as linhas de cada intervalo citado com knowledge_evidence_read. Apenas preenchimento ("tipo", "sabe") pode diferir. Corrija uma citação falhando restaurando as palavras faladas ou escolhendo um intervalo mais limpo; nunca mantenha uma paráfrase em uma citação.
• Sequência: compare a ordem narrada (antes/durante/depois, lugares, pessoas) com carimbos de data/hora, independentemente da ordem dos cabeçalhos. Use knowledge_chronicle_day (data e fuso horário da reunião) e knowledge_timeline para entidades relacionadas. Uma inversão ou lugar/hora impossível é uma contradição; nunca invente trânsito. Corrija e verifique novamente, ou registre uma isenção explícita do usuário como WAIVED, não resolvida. Uma isenção cobre apenas sequência. Um participante ausente da crônica do dia geralmente significa uma linha de Linha do Tempo faltando: investigue, não bloqueie. Ordem genuinamente ambígua é sinalizada no relatório, não bloqueada.

Feito quando: todas as verificações passam, ou falhas são corrigidas e verificadas novamente.

Relatório

Uma linha por reunião (uma por página para uma gravação dividida): página, fontes retidas, participantes enriquecidos, entidades atualizadas ou reutilizadas, itens de ação, alegações e arestas, resultado da verificação, sequência PASS ou WAIVED com a contradição em aberto. Liste contradições com o Conhecimento existente, alegações retidas, identidades não resolvidas e trabalho restante aqui, no relatório, não nas páginas; o usuário as resolve. Se uma verificação não puder passar, reporte a reunião como não ingerida e nomeie a verificação. Um relatório parcial é progresso honesto, não conclusão.