KAUT — Actualización de conocimiento bajo confianza

Hace que los códigos heredados sean nativos de IA. KAUT es documentación automantenida y prioritaria para IA de tu proyecto: una capa de conocimiento que hace legible para los agentes de IA el código sin documentar y con contexto débil. No es un recuerdo de conversaciones, sino una base de conocimiento sobre el propio sistema: qué hace, cómo está estructurado y por qué. Convierte lo que los agentes aprenden mientras trabajan en documentación viva, para que ninguna sesión comience desde cero.

Dependencia cero de Node.js (≥ 20, desarrollado en 24), Apache-2.0. Desarrollado y probado en macOS y Linux (CI ejecuta Linux, Node 20 y 24); Windows no está soportado.

Un producto completo e independiente. Un solo git clone es toda la instalación; apunta tu arnés al servidor MCP incluido (o llama a la CLI desde cualquier habilidad/prompt) y funciona: sin orquestador, sin framework, sin servicios, sin cuentas, nada más que desplegar. Se compone con el framework de orquestación hermano TAUT (TAUT impulsa agentes, KAUT es lo que saben), pero esa integración es opcional, no una dependencia.

Estado: v0.8.1 — el bucle completo está activo. Lectura: lookup (respuesta lista en una llamada) con veredictos de frescura (anclados a merge-base, nunca dice "fresco" cuando no está seguro), niveles de confianza y la banda de cobertura altitude; la contención de manipulación retiene cualquier edición realizada fuera del pipeline. Multi-repo: registro de espacio de trabajo, almacenes por miembro, un almacén de sistema anclado a un repositorio lanzador. Escritura: la puerta de escritura en capas (las actualizaciones de nivel de agente aterrizan directamente; las capas controladas por el propietario y los documentos nuevos se ponen en cola como borradores para revisión asíncrona). Mantenimiento: refresh (paquetes delta de re-derivación), touched (sensor de sitios de cambio), digest/note (telemetría de uso y resultados). Interoperabilidad: los almacenes cumplen con el estándar de conformidad OKF v0.2 y kaut okf export produce paquetes OKF idiomáticos. Cualquier arnés compatible con MCP se conecta mediante el servidor MCP incluido. Lo que está activo en detalle: docs/HANDBOOK.md §16.

El problema que resuelve

Cada nueva sesión de IA comienza con amnesia: el agente vuelve a explorar tu proyecto, hace las mismas preguntas otra vez y, lo peor de todo, sigue cometiendo el tipo de error más costoso: código que compila y pasa las pruebas, pero que silenciosamente rompe una regla de negocio que no tenía forma de conocer.

El "por qué" de un proyecto generalmente no está escrito en ningún lado. KAUT le da un lugar donde vivir, y lo mantiene vivo.

Esto afecta más a los códigos heredados: años de decisiones sin documentar, sin autores originales alrededor, reglas de negocio visibles solo como efectos secundarios. Es precisamente donde las herramientas de codificación con IA rinden por debajo hoy, y precisamente el código para el que KAUT está construido. KAUT es el primer paso de un objetivo más amplio: hacer que los códigos heredados sean nativos de IA, estructurados para que los agentes puedan trabajar en ellos de forma segura y económica.

Related MCP server: 50 First Tapes MCP Server

Qué es KAUT — y qué no es

Tres categorías familiares se ven similares desde la distancia. KAUT no es ninguna de ellas, y las diferencias son exactamente donde está el valor.

No es otro sistema de memoria. La memoria responde "¿de qué hablamos, qué prefiere este usuario?" — personal, episódico, no verificable. KAUT responde "¿cómo funciona este proyecto y por qué?" — documentación: organizada por dominio, vinculada a fuentes, con verificación de frescura, etiquetada con confianza y legible por cualquier agente y por humanos. Las notas personales nunca entran en KAUT; el conocimiento del proyecto nunca queda atrapado en la memoria de un solo agente. Esa frontera está integrada en la ruta de escritura.

No es RAG. La generación aumentada por recuperación indexa cualquier texto que exista y sirve los fragmentos que mejor coinciden, sin saber si siguen siendo ciertos. KAUT almacena la selección opuesta: solo conocimiento que es costoso de re-derivar y no visible de forma barata en el código (la prueba de fuego del almacenamiento), destilado en documentos cortos que un modelo lee completos: sin embeddings, sin ranking, sin sopa de fragmentos. Y cada documento lleva un veredicto de frescura verificado por máquina: anclado al commit del que se derivó, comparado con la rama principal rastreada en cada lectura, inclinándose hacia obsoleto cuando git no puede demostrar lo contrario. Ejecuta RAG sobre tu código si quieres; KAUT es para lo que el código no dice: el porqué, los invariantes transversales, el conocimiento tribal.

No es una wiki de LLM. La documentación autogenerada es texto plausible, no verificado al nacer y abandonado en el primer commit. Un documento de KAUT no puede existir sin vinculaciones de fuentes tipadas y un commit ancla, y no puede permanecer incorrecto en silencio, porque las fuentes se comparan en cada lectura. La ruta de escritura es la otra mitad: las capas mecánicas se regeneran automáticamente, los agentes pueden aterrizar hechos operativos que verificaron en sesión, pero el conocimiento de nivel de juicio (decisiones, semántica de dominio, contratos) solo entra a través de una compuerta aprobada por humanos: las actualizaciones se ponen en cola como borradores que revisas en lote. Una wiki se degrada por defecto; el defecto de KAUT es confesar.

Y no es un silo propietario. KAUT es una implementación del Open Knowledge Format (OKF) v0.2 neutral al proveedor: los almacenes son documentos de concepto en markdown tipado que cumplen con el estándar de conformidad de OKF en el lugar, y kaut okf export proyecta cualquier almacén en un paquete OKF v0.2 completamente idiomático (con las familias de procedencia, confianza y ciclo de vida incluidas), legible por cualquier consumidor de OKF. La maquinaria de frescura/confianza de KAUT se monta encima como claves de extensión protegidas por OKF: el formato registra conocimiento; el motor es lo que lo mantiene verdadero. El mapeo normativo vive en SCHEMA.md.

Principios

1. Vinculado a fuentes, anclado a commit. Cada hecho nombra los archivos de los que proviene y el commit en el que se derivó. Sin fuente, sin documento: el contrato se valida en la puerta.

2. Inclinarse hacia obsoleto. La frescura es un cálculo puro de git (merge-base contra la rama principal rastreada). Cuando git no puede demostrar que un documento está actualizado, el veredicto lo dice. KAUT nunca dice "fresco" cuando no está seguro: un "obsoleto" falso cuesta una re-verificación; un "fresco" falso envía un error.

3. El conocimiento informa; nunca autoriza. Un veredicto saludable es permiso para omitir la re-derivación, no permiso para actuar. Los veredictos enrutan confianza: saludable + preciso = utilizable tal cual; obsoleto / roto / altitud gruesa = confirmar en el código primero.

4. No sirvas nada que no puedas garantizar. El almacén es leído por agentes de IA, por lo que una edición fuera del pipeline es un canal de inyección, no una conveniencia. Cualquier cosa que no sea byte-idéntica al último commit del pipeline se retiene por completo (tampered) hasta que se restaure o se aterrice legítimamente.

5. Los humanos poseen el juicio; los agentes poseen la mecánica. La puerta de escritura en capas: los mapas se regeneran libremente, los hechos operativos verificados aterrizan en el nivel de agente, y el conocimiento de decisiones/dominio/contratos espera en una cola de borradores para la revisión de una tecla del propietario.

6. Reparar donde es más barato. La degradación de frescura se combate estructuralmente, no heroicamente: el sitio de cambio (touched nombra los documentos que un cambio de código debe actualizar), el sitio de lectura (un veredicto obsoleto llega con un paquete delta refresh — exactamente qué cambió, contra qué re-derivar), y telemetría honesta (digest) para ver si el mantenimiento sigue el ritmo.

7. Local primero, cero dependencias, repositorio intacto. Un clon, sin paso de instalación, sin demonio, sin nube; el almacén de conocimiento vive fuera de tu repositorio, y las comprobaciones de frescura cuestan comparaciones de git, no llamadas a modelos.

Qué hace KAUT

• Un lugar conocido al que mirar. El agente consulta KAUT antes de volver a explorar tu código. O la respuesta está ahí, o KAUT anota la brecha para que se llene después.

• El conocimiento se recoge solo. Después de completar una tarea, las cosas útiles que el agente acaba de aprender se condensan en la base, un subproducto del trabajo ya pagado, no un proyecto de documentación separado.

• Nunca miente con confianza. Cada hecho almacenado permanece vinculado al código del que proviene. Cuando ese código cambia, el hecho se marca automáticamente como posiblemente desactualizado. En caso de duda, KAUT dice "revisa esto" en lugar de fingir que todo está fresco.

• Se niega a servir lo que no puede garantizar. La base de conocimiento es leída por agentes de IA, por lo que un archivo editado a espaldas de KAUT (fuera de su propio control de versiones) es un posible canal de inyección. Ese contenido se retiene por completo hasta que se restaure o se vuelva a comprometer adecuadamente: cada respuesta que ve el agente proviene de un commit con procedencia rastreada.

• Tú sigues siendo el juez. Las capas controladas por el propietario y los documentos nuevos nunca aterrizan sin tu aprobación: las actualizaciones se ponen en cola como borradores (kaut draft), y apruebas o descartas todo el lote en una sola sesión (kaut review). No tienes que estar presente cuando el agente termina.

• Tu repositorio nunca se toca. Todo el conocimiento vive en una carpeta separada fuera del proyecto. Tu historial de git, ramas y compañeros de equipo nunca lo ven.

• Cualquier agente puede conectarse. Además de la CLI, KAUT incluye un servidor MCP (node <engine>/mcp.mjs, cero dependencias): las mismas búsquedas, veredictos de frescura y escrituras con compuerta como herramientas MCP, para cualquier arnés u orquestador compatible con MCP. Un servidor maneja todo un espacio de trabajo multi-repo (cada llamada nombra su repo).

Arquitectura

flowchart LR
    subgraph clients["Clients"]
        direction TB
        HARNESS["AI agents\nany MCP-capable harness"]
        HUMAN["Humans and CI\nshell, scripts"]
        ORCH["Orchestrator, e.g. TAUT\n(optional)"]
    end

    subgraph engine["KAUT engine - stateless, zero-dep Node, no daemon"]
        direction TB
        SURF["Two surfaces\nmcp.mjs - 7 MCP tools\nkaut.mjs - CLI"]
        READP["READ path (lock-free)\nlookup / stale / digest\nfreshness verdict = pure git computation\n+ trust tier + altitude on every answer"]
        WRITEP["WRITE path (one chokepoint)\nlayered write gate + draft queue\nagent tier lands, judgment tier\nwaits for owner review"]
        MAINTP["Maintenance loop\nrefresh / touched / note\nmap collectors (stack adapters)"]
    end

    subgraph home["Knowledge data home - set once with kaut home"]
        direction TB
        STORES["One store per repo\ntyped markdown + frontmatter\nown private git = audit + rollback\njournal telemetry"]
        REG["workspaces registry\nmember stores + one system store"]
        BACK["backups/\nkaut backup / restore"]
    end

    REPOS["Your repositories\nREAD-ONLY sources\n(at most one git-ignored pointer file)"]
    OKFB["OKF v0.2 bundle\nkaut okf export"]

    HARNESS --> SURF
    HUMAN --> SURF
    ORCH --> SURF
    SURF --> READP
    SURF --> WRITEP
    SURF --> MAINTP
    READP -- "diff sources against\nthe anchor commit" --> REPOS
    MAINTP -- "derive maps from code" --> REPOS
    READP <--> STORES
    WRITEP --> STORES
    STORES --> OKFB

La forma en cuatro frases. El motor no tiene estado — cada comando (CLI o herramienta MCP) calcula su respuesta a partir de dos historiales de git y termina; no hay nada residente que ejecutar, sincronizar o corromper. El conocimiento vive fuera de tus repositorios, un almacén por repo en el directorio de datos, y cada almacén es su propio repositorio git privado — que es lo que hace posible la compuerta de escritura, la contención de manipulación, la auditoría y el rollback. La ruta de lectura nunca bloquea y nunca adivina: un veredicto se deriva comparando las fuentes tipadas de un doc contra su commit ancla en el momento en que preguntas. La ruta de escritura tiene exactamente un punto de estrangulamiento, por lo que la política (nivel de agente vs. revisión del propietario) no se puede eludir eligiendo un comando diferente.

Inicio rápido

1. Clona el motor junto a los repositorios a los que servirá (una carpeta hermana — la configuración escanea sus vecinos; no hay npm install, el motor tiene cero dependencias):

cd ~/projects && git clone https://github.com/yurgeno/kaut.git

2. Ejecuta la configuración — tres preguntas, y cada respuesta tiene una bandera para instalaciones con script:

node kaut/kaut.mjs setup

• Carpeta de datos de conocimiento — donde viven los almacenes (predeterminado: <siblings>/kaut-data). Se persiste una vez (la redirección kaut home): cada comando posterior y el servidor MCP la resuelven por sí mismos — nada que exportar, nada que pasar. Esta carpeta son datos vivos: el motor solo añade a ella; nada existente se borra o reescribe.

• Qué repositorios — la configuración lista cada repositorio git hermano; responde all, números o nombres.

• ¿Arrancar ahora? — sí crea/actualiza un almacén por repo seleccionado en el momento (idempotente: los almacenes existentes se actualizan, nunca se re-sembran); no solo registra la configuración e imprime los comandos por repo para más tarde.

No interactivo: node kaut/kaut.mjs setup --data <dir> --repos all --bootstrap --yes (--no-bootstrap, --scan <dir> para escanear en otro lugar).

3. Sigue los siguientes pasos impresos — la configuración termina con exactamente dos: conecta el servidor MCP a tu arnés, y pega el contrato de conocimiento en las instrucciones de tu agente (ambos abajo). Opcionalmente genera el mapa mecánico por repo:

node kaut/kaut.mjs map

(el arranque ya detectó tu stack y sembró los recolectores correctos — ver Stacks compatibles abajo; un recolector cuya entrada está ausente se omite con una nota, y map.collectors: [] significa que la capa de mapa simplemente permanece vacía).

Stacks compatibles

El arranque, el bucle de conocimiento, los veredictos de frescura, la compuerta de escritura — todo es agnóstico al stack: cualquier repositorio git funciona. Solo la capa mecánica map/ es específica del stack, y el arranque auto-detecta el stack y siembra map.collectors en consecuencia (las configuraciones existentes nunca se tocan; cada perilla sigue siendo anulable):

Un repo sin stack reconocible obtiene una capa de mapa vacía y todo lo demás funciona igual. Los recolectores léxicos son escaneos honestos de mejor esfuerzo, marcados como tales en el doc generado. Los adaptadores para más stacks son deliberadamente módulos pequeños — ver CONTRIBUTING.md si el tuyo falta.

Conectando tus agentes — el paso que lo hace real

Un almacén solo no cambia nada: tu agente tiene que saber que existe y cuándo consultarlo. Dos movimientos (guía completa con bloques listos para pegar y una sesión trabajada: docs/AGENT-INTEGRATION.md):

1. Conecta el servidor MCP a tu arnés (.mcp.json para Claude Code, config.toml para Codex — fragmentos en la guía). Las siete herramientas kaut_* aparecen en cada sesión, y sus descripciones ya enseñan al modelo la disciplina: consulta antes de re-explorar, enruta la confianza según el veredicto, escribe de vuelta a través de la compuerta.

2. Pega el contrato de conocimiento en lo que tu agente carga en cada sesión (CLAUDE.md / AGENTS.md / prompt del sistema) — un bloque de ~15 líneas de la guía que hace que el comportamiento sea fiable en lugar de ocasional: lee antes de re-derivar; saludable + preciso = úsalo tal cual, obsoleto/bruto = confirma en código; etiqueta los resultados con kaut_note; después de editar archivos ejecuta kaut_touched y repara o pon en cola lo que el cambio debe.

Opcionalmente envuelve el contrato como una habilidad del arnés (plantilla en la guía), o deja que un marco de orquestación compile la conexión por ti — TAUT lo hace desde una respuesta de configuración. Luego: trabaja como siempre. Si alguna vez quieres navegar tú mismo, node <engine>/kaut.mjs lookup imprime el catálogo de temas.

Uso diario — no hay ninguno

KAUT está diseñado para ser invisible. Lo notarás en exactamente tres momentos:

• Bajo tu comando — dile al agente que guarde lo que acaba de aprender ("persiste esto en KAUT"): filtra los hallazgos de la sesión a través de la prueba de fuego, los escribe con enlaces de fuente adecuados, y hace commit al git del almacén. El conocimiento con compuerta de propietario aún se detiene en la cola de borradores para tu revisión.

• Cuando se acumulan borradores — kaut review lista lo que te espera; aprueba o rechaza el lote de una sentada (doctor también advierte mientras hay una cola pendiente).

• Ocasionalmente el agente hace una pregunta que solo un humano puede responder ("¿esta regla es intencional, o un accidente?"). Tu respuesta se convierte en el tipo más valioso de conocimiento en la base.

Todo lo demás — buscar cosas, verificar frescura, reconstruir el mapa — ocurre automáticamente y en silencio.

Comandos

Ejecuta desde cualquier lugar dentro de un repositorio git de proyecto:

node <engine>/kaut.mjs setup         # guided install: data home, sibling-repo scan, bootstrap (run once, from anywhere)
node <engine>/kaut.mjs bootstrap     # create/repair the project's knowledge store (idempotent)
node <engine>/kaut.mjs index         # regenerate INDEX.md (under lock; auto-commits changes)
node <engine>/kaut.mjs doctor        # integrity checks; exit 0 = healthy
node <engine>/kaut.mjs home [<dir>]  # show or set the knowledge-data home (redirect at ~/.kaut/config.json)
node <engine>/kaut.mjs paths         # print resolved {projectId, root, engine, repo, mainBranch, source}
# reading core:
node <engine>/kaut.mjs lookup [<id>] # one-call ready block; no id = catalog; unknown id = miss (exit 0)
node <engine>/kaut.mjs stale [<id>…] # freshness verdicts for all/selected docs (read-path, no lock)
node <engine>/kaut.mjs map           # regenerate L0 maps per config map.collectors + commit
# maintenance loop:
node <engine>/kaut.mjs refresh [<id>…]        # per-doc re-derivation delta bundles (read-only)
node <engine>/kaut.mjs draft <id>             # queue a finished doc update for async owner review
node <engine>/kaut.mjs review [<id>…]         # owner side: list / diff / --approve / --reject
node <engine>/kaut.mjs touched <file>…        # which docs bind the given changed files
# telemetry:
node <engine>/kaut.mjs note <topic> <result>  # record an in-session outcome (trusted|confirmed|insufficient|stale-misled)
node <engine>/kaut.mjs digest [--since <ISO>] # aggregate journal telemetry across workspace stores
# backup / restore (the whole data home — stores, registry, setup record):
node <engine>/kaut.mjs backup                 # dated, versioned .tar.gz under <data>/backups/
node <engine>/kaut.mjs restore [latest|<file>] [--force]   # no arg = list; never overwrites without --force
# open format (OKF v0.2):
node <engine>/kaut.mjs okf check              # store-as-OKF-bundle conformance report (exit 0 = conformant)
node <engine>/kaut.mjs okf stamp              # backfill `type:` on legacy docs (through the write gate)
node <engine>/kaut.mjs okf export --out <dir> # project committed HEAD into an idiomatic OKF v0.2 bundle
# workspace (multi-repo):
node <engine>/kaut.mjs workspace init --manifest <conductor>/manifest.json
                                     # registry + member stores + ONE system store anchored to the launcher
node <engine>/kaut.mjs workspace list

Servidor MCP: node <engine>/mcp.mjs — un servidor JSON-RPC stdio de cero dependencias que expone los verbos de sesión como herramientas MCP (kaut_lookup, kaut_note, kaut_refresh, kaut_touched, kaut_write, kaut_draft, kaut_status). Cada herramienta acepta un argumento opcional repo, por lo que un servidor sirve a todo un espacio de trabajo multi-repo. Los escapes ejecutados por el propietario (review --approve, index --approve) deliberadamente no se exponen a través de MCP.

Banderas: --dry-run (imprime acciones sin actuar) · --json (salida de máquina para stale|lookup|refresh|review|touched|digest) · --quiet · --approve / --reject (ejecutado por el propietario) · --force (restore: sobrescribe datos existentes; okf export: escribe en un directorio no vacío) · --out <dir> (okf export) · --note <text> (note, review --reject) · --manifest <path> (workspace init) · --workspace <name> (doctor/stale/digest a través de un workspace) · --since <ISO-date> (digest) · --help/-h (uso, salida 0).

Códigos de salida: 0 ok · 1 fallo de validación/doctor · 2 almacén ocupado (bloqueo mantenido) · 3 entorno faltante (no es un repo git / almacén no arrancado).

lookup y stale son de ruta de lectura — no toman bloqueo y solo añaden una línea a journal.jsonl (telemetría de uso, sin seguimiento). Un veredicto de frescura es dato, no un error: stale sale con 0 incluso cuando los docs están obsoletos. Línea de veredicto, como máximo una, por prioridad tampered > disputed > broken > stale > branch-advisory; un doc saludable se muestra limpio.

Profundidad operativa — diseño del almacén en disco, orden de resolución, contención de manipulación y la compuerta de escritura en detalle, desinstalación, internos del motor: docs/OPERATIONS.md.

Configuración

Un archivo: kaut.config.json en el almacén (creado por el arranque, valores predeterminados sensatos). La mayoría de la gente solo toca el bloque map (lista de recolectores y ubicaciones de archivos — ver la nota de inicio rápido arriba). La referencia completa de lo que el motor realmente lee: docs/HANDBOOK.md §15.

¿Realmente está ayudando?

KAUT está construido para mantenerse honesto:

• Mantiene un diario de uso por almacén (journal.jsonl): cada búsqueda con su veredicto, cada escritura con compuerta, cada resultado registrado. kaut digest lo agrega a través de un workspace en números de alcance / auto-mantenimiento / señal de valor.

• Las sesiones registran cómo le fue realmente a un doc (kaut note <topic> trusted|confirmed|insufficient|stale-misled) — la señal de valor del sistema de honor que muestra dónde el conocimiento ahorró trabajo y dónde engañó.

• El benchmarking se hace externamente (ejecuta la misma tarea con y sin KAUT y compara); el motor deliberadamente no incluye ningún arnés de benchmark.

El diario es telemetría de solo añadir sin seguimiento y crece sin límite; es seguro truncar líneas antiguas manualmente (nunca es conocimiento, y digest simplemente ve una historia más corta).

Copia de seguridad

La carpeta de datos es toda la base de datos — trátala en consecuencia. kaut backup empaqueta todo el directorio de datos (cada almacén con su historial git, el registro de workspaces, el registro de configuración) en un archivo con fecha y versión bajo <data>/backups/ — un .tar.gz simple (ustar hecho a mano + node:zlib, cero dependencias) que cualquier herramienta tar estándar también puede leer. kaut restore latest (o un nombre de archivo) lo trae de vuelta; nada existente se sobrescribe jamás sin --force — un restore rechazado lista los conflictos y no toca nada.

Pruebas

cd <engine> && node --test          # 213 tests, zero deps (node:test)

Ejecuta el node --test simple — no pases el directorio de pruebas como argumento (en Node ≥ 24 esa forma falla al resolver la suite).

Desinstalación

Elimina el directorio del almacén (~/.kaut/<project-id>) y el archivo puntero (<repo>/.kaut.json), y quita la línea .kaut.json de <repo>/.git/info/exclude. Tu repositorio nunca fue modificado para empezar — no hay nada más que limpiar.

FAQ

¿Es esto solo otro sistema de memoria de agente? No. La memoria de agente recuerda conversaciones y preferencias; KAUT es la documentación del proyecto — primero para IA, con enlace a fuentes, con verificación de frescura. La ruta de escritura hace cumplir el límite: el conocimiento del proyecto va a KAUT, las preferencias personales van a la memoria propia del agente.

¿Es esto RAG? No. No hay embeddings, ni chunking, ni ranking de recuperación. KAUT almacena un pequeño conjunto de docs destilados que un agente lee completos, cada uno con procedencia y un veredicto de frescura calculado por git — y deliberadamente almacena solo lo que no es derivable barato del código. RAG sobre tu codebase y KAUT responden preguntas diferentes y coexisten bien.

¿Es esto una wiki auto-generada? No. Nada entra al almacén como prosa generada sin verificar: cada doc debe llevar enlaces de fuente tipados y un ancla de commit, las capas mecánicas se regeneran (no se alucinan), y el conocimiento de nivel de juicio pasa una compuerta aprobada por humanos. Y a diferencia de una wiki, un doc de KAUT no puede pudrirse en silencio — sus fuentes se comparan en cada lectura.

¿El formato del almacén es propietario? No — lo contrario. KAUT implementa el Open Knowledge Format (OKF) v0.2 neutral al proveedor: documentos de concepto en markdown tipado simple. Cualquier consumidor de OKF puede leer un almacén, y kaut okf export produce un paquete OKF completamente idiomático. Sin bloqueo: tu conocimiento es markdown portátil en un repo git de cualquier manera.

¿Hará commit de algo en mi repositorio? No. Como máximo un archivo puntero ignorado. El almacén de conocimiento vive fuera del repositorio.

¿Mi equipo tiene que adoptarlo? No. KAUT es local-first: un desarrollador lo instala y se beneficia; nadie más está involucrado o afectado.

¿Qué pasa si un hecho almacenado es incorrecto? Cada hecho lleva su origen y una etiqueta de confianza; el agente trata los hechos de baja confianza con escepticismo y los verifica contra el código. El almacén mantiene un historial completo, por lo que las entradas incorrectas pueden rastrearse y revertirse.

¿Cuánto cuesta ejecutarlo? La primera construcción del mapa es la parte costosa (minutos). El mantenimiento diario está diseñado para costar casi nada: las comprobaciones de frescura son comparaciones puras de git — sin llamadas de IA involucradas.

Aprende más

• La wiki del proyecto — Guía de inicio, Conexión de tu proyecto, Conceptos básicos, el Bucle de mantenimiento, Preguntas frecuentes y Solución de problemas en forma guiada

• docs/HANDBOOK.md — cómo funciona todo, en lenguaje humano pero con todo detalle

• docs/OPERATIONS.md — referencia del operador: estructura en disco, resolución, contención de manipulaciones, puerta de escritura, internals del motor

• docs/AGENT-INTEGRATION.md — conexión de agentes al almacén: el contrato de conocimiento, fragmentos por harness, una plantilla de habilidad, una sesión trabajada

• docs/MCP.md — la referencia del servidor MCP: registro, las 7 herramientas, protocolo

• SCHEMA.md — el contrato de datos normativo que implementa este motor (incl. el mapeo de conformidad con OKF v0.2)

• CHANGELOG.md — historial de versiones

• CONTRIBUTING.md · SECURITY.md · CODE_OF_CONDUCT.md

Licencia y cita

Apache-2.0 — ver LICENSE y NOTICE. Si usas KAUT o construyes sobre los conceptos que implementa, por favor cítalo mediante CITATION.cff.

Contacto: Yuriy Orlov yuriy.orlov@undertrust.dev