Knowledge IR

Una regla no es una unidad de conocimiento. Es un contenedor de conocimiento.

Un solo párrafo escrito por una persona suele decir varias cosas de distinto tipo al mismo tiempo: que algo nunca debe ocurrir, que otra cosa tiene que verificarse y por qué existe todo ese planteamiento. Si se entrega como un único bloque, todo eso se reduce a "aquí tienes un texto, tenlo en cuenta". Si se mantiene separado, siguen siendo tres cosas distintas con tres pesos distintos.

Knowledge IR es el nombre de esa forma estructurada: el tipo y la autoridad de cada pieza de conocimiento, conservados junto al texto que escribió tu equipo, no en su lugar.

Tipos de conocimiento

Cada pieza de conocimiento que recibe un agente pertenece a uno de unos pocos tipos, y el tipo determina cómo se presenta.

Lo que no debe ocurrir. Una restricción que una persona estableció para un ámbito. Rige las rutas a las que se aplica y nada más, y es el único tipo de conocimiento sobre el que el runtime puede actuar en lugar de solo mencionarlo.

Lo que debe verificarse. Una comprobación que tiene que hacerse antes de que el trabajo se considere terminado.

Lo que funcionó cuando ocurrió este problema. Una condición y la corrección que lo resolvió. Es un consejo: le dice al agente qué ha funcionado, no qué tiene prohibido hacer.

Lo que conviene preferir bajo cierta condición. Una opción preferida, junto con las alternativas frente a las que se eligió. Expresa la preferencia y nunca prohíbe la alternativa. Eso solo puede hacerlo una regla.

Cómo debe hacerse algo. Un procedimiento ordenado, con sus pasos en el orden original, porque un procedimiento reordenado es otro procedimiento. La mayoría de los procedimientos viven en las skills.

Lo que es cierto y útil aquí. Un hecho descriptivo que cambia cuál es el enfoque correcto sin prohibir nada. Que la base de datos detrás de un módulo sea una réplica de solo lectura es un hecho de este tipo, y es la razón por la que un agente debería recurrir a la cola en lugar de a un insert.

Por qué algo funciona así. El razonamiento detrás de una decisión. Existe porque a un agente que conoce la regla pero no la razón le basta una refactorización bienintencionada para deshacerla.

Niveles de autoridad

Los tipos no tienen el mismo peso, y la entrega lo indica de forma explícita en lugar de depender del orden en que aparecen las cosas en un prompt.

Nada en el proceso de entrega puede presentar un nivel inferior como capaz de anular uno superior. Las reglas llegan en su propia sección. Los hallazgos de agentes llegan planteados como consejos que hay que verificar. Tus preferencias personales llegan bajo un encabezado que le indica al agente que las reglas y las verificaciones obligatorias del espacio de trabajo van primero. Un párrafo que suena con la misma fuerza que un requisito es un párrafo que se puede seguir en su lugar, y la estructura existe precisamente para evitarlo.

Esto es lo que significa en la práctica que "la autoridad se codifica, no se aplana", y es la diferencia entre una representación estructurada y un montón de frases.

Documentos y átomos

Tus memorias, reglas y skills siguen siendo exactamente lo que son: la superficie que una persona escribe, edita y discute. La forma estructurada es una representación de ellas, no un reemplazo.

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

Un mismo documento puede contener varios tipos de conocimiento. Es lo normal, y es la razón por la que un contenedor y una unidad no son lo mismo.

Lo más importante es de dónde provienen los tipos que obligan. Un requisito solo proviene de una regla que estableció una persona. Una regla también puede incluir una restricción ejecutable; una restricción que propone un agente se guarda como propuesta y no se aplica hasta que una persona la aprueba. Nada que infiera un modelo se convierte por sí solo en un requisito. Consulta Proposed Knowledge.

Conflicto

Dos consejos pueden parecer válidos y aun así contradecirse. Pathrule no le pasa esa contradicción al agente para que la resuelva.

• Hallazgos. Cuando dos hallazgos que registraron agentes sobre el código se contradicen, ambos se retienen en lugar de adivinar cuál elegir.
• Preferencias. Cuando enseñas una preferencia que contradice otra anterior sobre el mismo tipo de trabajo, la nueva la reemplaza, y la anterior se retira con una referencia a la que la sustituyó.
• Reglas y preferencias. Una regla siempre prevalece sobre una preferencia personal. Consulta User Intelligence.

Dos consejos contradictorios son peores que ninguno, y la estructura es lo que le permite a Pathrule detectar cuándo ocurre eso.