Knowledge IR

Uma regra não é uma unidade de conhecimento. Ela é um contêiner para uma.

Um único parágrafo escrito por uma pessoa costuma dizer, ao mesmo tempo, coisas de naturezas bem diferentes: que algo nunca pode acontecer, que outra coisa precisa ser verificada e por que tudo isso existe. Entregues como um bloco só, essas coisas se reduzem a "aqui está um texto, por favor leve em conta". Mantidas separadas, continuam sendo três coisas diferentes, com três pesos diferentes.

Knowledge IR é o nome dessa forma estruturada: o tipo e a autoridade de cada conhecimento, guardados junto com o texto que sua equipe escreveu, e não no lugar dele.

Tipos de conhecimento

Cada conhecimento que um agente recebe pertence a um de poucos tipos, e é o tipo que decide como ele é apresentado.

O que não pode acontecer. Uma restrição que uma pessoa definiu para um escopo. Ela rege os caminhos aos quais se aplica e nada além disso, e é o único tipo de conhecimento sobre o qual o runtime pode agir, em vez de apenas mencionar.

O que precisa ser verificado. Uma checagem que tem que acontecer antes de o trabalho ser considerado concluído.

O que funcionou quando esse problema apareceu. Uma condição e a correção que a resolveu. É conselho: diz ao agente o que já funcionou, não o que ele está proibido de fazer.

O que deve ser preferido em determinada condição. Uma escolha preferida, junto com as alternativas em relação às quais ela foi preferida. Ela declara a preferência e nunca proíbe a alternativa. Só uma regra pode fazer isso.

Como algo deve ser feito. Um procedimento ordenado, com os passos na ordem original, porque um procedimento reordenado é outro procedimento. As Skills são onde fica a maioria dos procedimentos.

O que é verdadeiro e útil aqui. Um fato descritivo que muda a abordagem correta sem proibir nada. O banco de dados por trás de um módulo ser uma réplica somente leitura é um fato desse tipo, e é por isso que o agente deve recorrer à fila em vez de fazer um insert.

Por que algo funciona desse jeito. O raciocínio por trás de uma decisão. Ele existe porque um agente que conhece a regra, mas não o motivo, está a uma refatoração bem-intencionada de desfazê-la.

Faixas de autoridade

Os tipos não têm o mesmo peso, e a entrega deixa isso explícito, em vez de depender da ordem em que as coisas aparecem no prompt.

Nada no caminho de entrega pode apresentar uma faixa inferior como capaz de se sobrepor a uma superior. As regras chegam em uma seção própria. As descobertas de agentes chegam enquadradas como conselhos a serem verificados. Suas preferências pessoais chegam sob um título que avisa ao agente que as regras e as verificações obrigatórias do espaço de trabalho vêm primeiro. Um parágrafo que soa com a mesma força de um requisito é um parágrafo que pode ser seguido no lugar dele, e a estrutura existe justamente para evitar isso.

É isso que "a autoridade é codificada, não achatada" significa na prática, e é a diferença entre uma representação estruturada e um amontoado de frases.

Documentos e átomos

Suas memórias, regras e skills continuam sendo exatamente o que são: a superfície que uma pessoa escreve, edita e discute. A forma estruturada é uma representação delas, não uma substituta.

Rule document
    |
    +-- what must not happen
    +-- what must be verified
    +-- why

Um mesmo documento pode conter vários tipos de conhecimento. Isso é normal, e é justamente por isso que contêiner e unidade não são a mesma coisa.

O que mais importa é de onde vêm os tipos que obrigam. Um requisito vem apenas de uma regra definida por uma pessoa. Uma regra também pode trazer uma restrição executável; uma restrição proposta por um agente é armazenada como proposta e só é aplicada depois que uma pessoa a aprova. Nada inferido por um modelo vira requisito por conta própria. Veja Proposed Knowledge.

Conflitos

Dois conselhos podem parecer válidos e, ainda assim, discordar. O Pathrule não repassa essa discordância para o agente resolver.

• Descobertas. Quando duas descobertas que agentes registraram sobre o código se contradizem, as duas são retidas, em vez de se tentar adivinhar qual delas vale.
• Preferências. Quando você ensina uma preferência que contradiz outra anterior sobre o mesmo tipo de trabalho, a mais nova a substitui, e a mais antiga é aposentada com uma referência ao que a substituiu.
• Regras e preferências. Uma regra sempre prevalece sobre uma preferência pessoal. Veja User Intelligence.

Dois conselhos contraditórios são piores do que nenhum, e é a estrutura que permite ao Pathrule perceber quando isso está acontecendo.