Kenning Continuity

Conocimiento empresarial que se acumula en lugar de degradarse.

Un servidor MCP que permite a los agentes LLM acumular conocimiento organizativo a lo largo de las sesiones, delimitado por dominio, con Neo4j como respaldo. Cada invariante estructural la impone una herramienta en lugar de pedirse en una instrucción, y no se expone ninguna escritura Cypher en bruto, de modo que el grafo no puede corromperse sin importar lo que decida hacer el modelo.

Está en producción a escala empresarial: 37 dominios, 376 sesiones y 3,000+ entidades de conocimiento acumuladas durante cuatro meses de uso diario.

Por qué esto no se degrada al llenarse

La mayoría de los sistemas de memoria acumulativa fallan de una de dos maneras. Confabulan desde el primer día, porque nada distingue una cosa que fue observada de una cosa que fue inferida por un modelo que intenta ser útil. O sobreviven a la demo y luego se degradan bajo el peso de la acumulación, porque cada escritura es una adición sin restricciones y el almacén se llena lentamente de casi-duplicados, sobrescrituras silenciosas y afirmaciones que nadie puede rastrear hasta un autor.

Cuatro compromisos, todos impuestos estructuralmente:

Nada se sobrescribe. No existe update_knowledge ni retype_knowledge. Cambiar lo que se sabe sobre una entidad crea un nodo nuevo enlazado con su predecesor mediante EVOLVED_FROM. La comprensión anterior sigue ahí, sigue siendo legible, sigue siendo atribuible. Haber estado equivocados antes es un hecho sobre el registro, no algo que deba borrarse de él.

Toda afirmación llega a su autor en dos saltos. Una entidad de conocimiento es descubierta por una Session; una Session está dirigida por una Person. Ambas aristas las escriben herramientas que se niegan a ejecutarse sin un director real. Así, «quién dijo esto, y cuándo, y con qué propósito» siempre se puede responder, no por convención, sino porque no existe ninguna ruta de código que cree conocimiento sin ello.

La identidad nunca se infiere de una cadena. Diecisiete nodos llamados «Alice Example» en once dominios son diecisiete actos de referencia, correctamente distintos. Afirmar que dos de ellos son una misma persona es una afirmación que alguien hace, en una sesión, registrada como REFERENT_CLAIM que puede contener el valor distinct — porque un sistema sin un lugar donde registrar la respuesta no volverá a hacer la misma pregunta eternamente. La identidad por coincidencia de cadenas es donde la mayoría de los grafos de conocimiento empiezan a mentir en silencio.

La estructura transporta los hechos; las propiedades no los duplican. Una entidad de conocimiento no tiene propiedad domain. La coloca en un dominio la sesión que la descubrió y desde allí se llega a ella mediante un recorrido. La propiedad que precedió a esto se había desviado, que es lo que hacen las desnormalizaciones: 21 entidades llevaban una cadena domain que nombraba un dominio real sin ninguna ruta hacia ellas. Un hecho mantenido como texto junto a una estructura, en lugar de ser sostenido por ella, es un hecho que acabará discrepando de la estructura.

No hay campo confidence, deliberadamente. La confianza de alguien en una ocasión es un hecho sobre su experiencia y no se transmite; un lector posterior deriva la suya a partir de la descripción y de lo que sabe. Lo que las puntuaciones de confianza intentan alcanzar lo transportan en su lugar aristas que cualquier lector puede juzgar: VALIDATION, INVALIDATING y un Challenge sin Solution asociado.

Si has ejecutado un sistema de memoria acumulativa a escala y también te has topado con estos muros, queremos saber de ti.

Related MCP server: Neo4j Agent Memory MCP Server

Arquitectura

Capa de proceso (inmutable) — Person → Session, dentro de Domain → Session. NEXT_SESSION siempre apunta hacia delante en el tiempo; así lo impone la herramienta. La pertenencia a esta capa es la capacidad de contener futuros posibles y medirlos hacia su materialización; nada aquí es un referente.

Capa de conocimiento (solo anexión) — 11 tipos ontológicos y 7 subetiquetas, conectados por 13 tipos de conexión, cada nodo marcado como :Knowledge. Los cambios de descripción crean un nuevo nodo de cadena enlazado mediante EVOLVED_FROM.

Consulta HOWTO.xml para conocer la enseñanza orientada al operador que debe darse a un LLM como andamiaje de invariantes, y docs/design/ para el razonamiento que hay detrás de cada compromiso.

Requisitos previos

• Python 3.10+

• Instancia de Neo4j 5.x (local o remota)

• uv (para el desarrollo; no es necesario para instalar)

Inicio rápido

pip install kenning-continuity

kenning-continuity --db-url bolt://localhost:7687

O desde el código fuente:

uv sync
uv run kenning-continuity --db-url bolt://localhost:7687

Configuración

Los indicadores de CLI tienen prioridad sobre las variables de entorno, que a su vez tienen prioridad sobre los valores predeterminados.

Configuración del cliente MCP

Claude Desktop / Claude Code

{
  "mcpServers": {
    "temporal-knowledge": {
      "command": "kenning-continuity",
      "args": ["--db-url", "bolt://localhost:7687"]
    }
  }
}

Transporte HTTP

kenning-continuity \
  --db-url bolt://localhost:7687 \
  --transport streamable-http \
  --server-host 0.0.0.0 \
  --server-port 8000 \
  --allow-origins "http://localhost:3000" \
  --allowed-hosts "localhost,127.0.0.1"

Superficie de herramientas (23 herramientas)

Una sesión se desarrolla así: create_domain (una vez) → begin_session → crear / evolucionar / confirmar / conectar conocimiento → end_session.

El servidor no tiene estado. begin_session devuelve un session_id que el cliente pasa a todas las herramientas de conocimiento posteriores. Una sesión que nunca se cierra permanece active, por diseño.

Proceso (4)

begin_session devuelve un recuento por tipo, no el estado del dominio. Devolver el estado en línea suponía 600,820 caracteres en un dominio de producción — aproximadamente 150k tokens gastados antes de que la sesión hubiera hecho una pregunta. Llama a get_domain_state con types y limit para la parte que realmente necesitas.

Mutación de conocimiento (6)

Consulta (5)

Taxonomía (2)

Análisis de grafos (6)

Sistema de tipos

Todo nodo de conocimiento lleva :Knowledge, exactamente una etiqueta ontológica, una propiedad ont_type que nombra esa etiqueta de manera determinista y cero o más subetiquetas mediante el multietiquetado de Neo4j.

Las sub-etiquetas son una retícula, no un mapa plano

PersonReferent → Actor          System        → Structure
Organization   → Actor          Process       → Structure
Team           → Organization → Actor         Configuration → Structure
                                              Service       → Structure

create_knowledge acepta un tipo ontológico (Actor) o una sub-etiqueta (Team), y aplica la cadena completa: :Knowledge:Actor:Organization:Team. Por lo tanto, una consulta de organizaciones encuentra equipos. Un mapa plano emitiría :Actor:Team, descartando silenciosamente el nivel intermedio, y nada lo reportaría.

Tipos de conexión (13)

EVOLVED_FROM, ENABLING, REQUIRING, INFORMING, CAUSING, COMPOSING, EXTENDING, RECOGNITION, VALIDATION, INVALIDATING, ASSOCIATED_WITH, SITUATED_AT, REFERENT_CLAIM.

Los bordes de proceso — HAS_SESSION, NEXT_SESSION, DIRECTED, DISCOVERED, CONFIRMED — solo los escriben las herramientas de proceso y no pueden crearse mediante create_connections.

Qué debe decir una descripción

Una descripción dice lo que la entidad es, no lo que le sucedió o lo que sucedió a su alrededor. Las observaciones temporales pertenecen a los nodos Event alcanzados por bordes.

• Correcto, para un Actor:PersonReferent: "Fundador de lululemon. Mayor accionista individual (8,4%). Presentado bajo Schedule 13D — no pasivo."

• Incorrecto: "SCHEDULE 13D/A Enmienda n.º 10 presentada el 8 de octubre de 2025. WILSON SE HACE PÚBLICO…"

La presentación es un Event. Wilson es el fundador. Que la presentación revele algo sobre él es un borde INFORMING. Su descripción debería sobrevivir sin cambios a cualquier número de presentaciones futuras, a menos que su identidad misma cambie.

Desarrollo

uv sync --group dev

./.venv/bin/pytest tests/unit          # mocked substrate, no database
./.venv/bin/pytest tests/integration   # real Neo4j via testcontainers; needs Docker
./.venv/bin/pyright

Un defecto que vive en una consulta Cypher es invisible para las pruebas unitarias — simulan el sustrato, y un error de fabricación de bordes llegó a pasarlas todas de forma idéntica antes y después de la corrección. Cualquier cosa que toque una consulta pertenece a tests/integration/.

Licencia y atribución

Licenciado bajo la Apache License, Version 2.0. Úsalo, modifícalo, ejecútalo en producción, comercialmente o de cualquier otra forma.

El trabajo aquí es la ontología — la retícula de tipos, la resolución por recorrido, la colocación de la posición epistémica en los bordes, el principio de que cada invariante vive en una herramienta. Eso se entrega libremente, y Apache-2.0 solo pide que la atribución viaje con ello: conserva LICENSE y NOTICE, y marca lo que cambiaste.

El nombre Kenning AI no forma parte de esa concesión (Apache-2.0 §6). Consulta TRADEMARKS.md para saber qué puedes hacer sin pedir permiso — que es casi todo, incluido decir sobre qué está construido tu software.

Contacto

contact@kenningai.com — sin formularios, sin embudos, nos llega directamente.

Estamos especialmente interesados en escuchar a cualquiera que haya ejecutado un sistema de memoria acumulativa a escala y haya formado una opinión sobre por qué fallan. Ese modo de fallo es la razón de casi todas las decisiones en este repositorio, y el desacuerdo de alguien que lo ha experimentado en primera persona vale más para nosotros que el acuerdo de quien no lo ha hecho.

Kenning AI · kenningai.com