--- title: "Validar certificados de derivación de Open Ontologies" canonical: https://wavect.io/es/blog/open-ontologies-proof-verification/ language: es description: "Valida certificados de derivación de Open Ontologies: prueba reproducible, errores del comprobador, rechazo de falsificaciones y límites del contexto RAG." image: "https://wavect.io/img/blog/headers/header_open-ontologies-proof-verification.png" author: ["Kevin Riedl"] published: "2026-11-03" updated: "2026-11-03" reviewed: "2026-11-03" --- # Cómo validar certificados de derivación de Open Ontologies [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min de lectura · 3 nov 2026 Última revisión 3 de noviembre de 2026 [**Siguiente**](/es/blog/graph-engineering-ai-agents/) Resumen Open Ontologies planifica cambios en grafos y genera certificados de derivación. Nuestro caso detectó consecuencias nuevas pese al riesgo estructural bajo, rechazó una conclusión alterada y distinguió fragmentos RAG intactos y truncados. El comprobador falló al ejecutar el certificado original, por lo que su aceptación independiente sigue sin confirmar. Revisa el grafo, las reglas y el resultado exacto antes de permitir que un agente utilice la conclusión. En nuestra prueba de Open Ontologies, añadir una tripleta mantuvo el riesgo estructural en `low`, pero produjo tres consecuencias nuevas. Después, una comprobación de recuperación terminó con código de éxito aunque indicaba expresamente que la conclusión seguía sin verificar. **Para validar un certificado de derivación de Open Ontologies, conserva el grafo de aserciones y las reglas utilizadas, ejecuta el comprobador independiente sobre los archivos de aserciones y derivaciones, y revisa tanto el resultado estructurado como la salida del proceso.** Aprueba únicamente el grafo y las afirmaciones que hayan superado la comprobación. Los resultados sin verificar y los fallos del comprobador quedan pendientes. [Open Ontologies](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/README.md) es un motor de código abierto que planifica cambios de ontología y genera certificados para las inferencias admitidas. La analogía con Terraform describe un proceso de planificación, revisión y aplicación. Si todavía estás decidiendo si tu agente necesita un grafo de conocimiento, empieza por nuestra [guía para evaluar la ingeniería de grafos](/es/blog/graph-engineering-ai-agents/). **Fecha de pruebas e investigación: 3 de noviembre de 2026.** Utilizamos los ejecutables para Linux de [v2.1.0](https://github.com/fabio-rovai/open-ontologies/releases/tag/v2.1.0), publicada el 23 de octubre de 2026, tras verificar sus sumas de comprobación. Las fuentes enlazadas corresponden al commit posterior `c7fd75f`, del 2 de noviembre. La aceptación independiente sigue **sin confirmar**: el comprobador falló durante la ejecución del certificado original en nuestro entorno. Este caso comprueba el comportamiento; no establece un benchmark de rendimiento. ## ¿Qué demuestra una prueba de Open Ontologies? **Un certificado de derivación aceptado demuestra que sus conclusiones se deducen de las aserciones aportadas dentro de la semántica formal admitida.** Que un documento esté aprobado, sea correcto o siga vigente requiere evidencia adicional. Un comprobador puede validar las consecuencias de una premisa incorrecta sin detectar que esa premisa es falsa. La [arquitectura de garantías del proyecto](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/assurance-architecture.md) distingue entre comprobar una conclusión y establecer qué grafo utilizó el motor. | Pregunta | Evidencia que debes revisar | Límite | | --- | --- | --- | | ¿Se sostiene la derivación? | Resultado del comprobador independiente sobre los archivos de aserciones y derivaciones | Válido bajo esas aserciones y las reglas admitidas | | ¿Es el grafo previsto? | Revisión del grafo, resumen criptográfico de las aserciones y ámbito seleccionado | Una prueba válida puede describir la versión equivocada | | ¿Son fiables las aserciones? | Fuentes, revisión de la extracción y responsable de los datos | La consecuencia lógica no verifica el mundo exterior | | ¿Puede el agente utilizar el resultado? | Política de la aplicación y controles de acceso | El nombre de una clase no concede permisos | Nuestro [análisis de LLM-as-a-Verifier](/es/blog/llm-as-a-verifier/) trata las puntuaciones aprendidas para ordenar respuestas de modelos. Open Ontologies comprueba una derivación explícita mediante reglas. ## ¿Cómo se comprueba un certificado de derivación de Open Ontologies? **Genera el certificado y ejecuta `oo-cert` sobre `asserted.tsv` y `derivations.tsv`.** Guarda stdout, stderr y el código de salida. Para aceptar el certificado, el comprobador debe terminar y devolver el resultado satisfactorio que establece su documentación. La [guía de certificados](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/lean-certificates.md) describe un comprobador independiente en Lean que verifica los pasos de inferencia registrados. El resultado de éxito documentado exige código `0`, `ok: true` y el teorema `OOCert.certificate_sound`. Un paso rechazado debe identificar la regla, la conclusión y sus premisas. Descarga nuestro [caso de prueba de certificados de Open Ontologies con los resultados registrados](/downloads/open-ontologies-proof-verification-fixture.zip) y entra en el directorio descomprimido. El ejemplo presupone que los ejecutables verificados del motor y del comprobador están en tu PATH. El paquete contiene los archivos de entrada y un recolector de evidencias; debes obtener los binarios por separado. ``` open-ontologies --no-connect --data-dir ./review-store batch - <<'OO' load proposed.ttl reason --profile rdfs --certificate ./certificate OO oo-cert ./certificate/asserted.tsv ./certificate/derivations.tsv ``` El modo batch mantiene la carga y el razonamiento en un único proceso. El grafo propuesto contenía cuatro tripletas afirmadas; el razonamiento con `rdfs` produjo tres derivaciones. Después alteramos una conclusión para afirmar que `note42` pertenecía a `ApprovedForProduction`, sin modificar sus premisas. | Entrada | Resultado observado | Decisión de revisión | | --- | --- | --- | | Certificado generado sin modificar | Código 1, stdout vacío, stderr: `failed to locate application` | Dejar pendiente. No se emitió una aceptación independiente satisfactoria | | Conclusión alterada, premisas intactas | Código 1, JSON `ok: false`, `first_rejected: 2`, regla `rdfs9` | Rechazar la derivación alterada. Falló la comprobación de una regla concreta | Ambos procesos terminaron con código `1`. Solo el segundo devolvió un rechazo estructurado de una regla; `first_rejected: 2` identifica el tercer registro de derivación, porque el índice empieza en cero. La primera ejecución falló al localizar la aplicación. Son fallos distintos: el control negativo no sustituye la aceptación satisfactoria del certificado original. ## ¿Por qué un plan de riesgo bajo necesita una revisión semántica? **Open Ontologies informa por separado del riesgo estructural y de las consecuencias semánticas.** Un cambio que no añade clases con nombre puede permitir que las reglas existentes deduzcan nuevas clasificaciones. Revisa el bloque `conservativity` y sus conclusiones afectadas antes de decidir si el cambio cumple lo previsto. El grafo inicial contenía estas tres aserciones. La declaración de `Retrievable` incluye ese nombre deliberadamente en el vocabulario original: ``` @prefix ex: . @prefix rdfs: . ex:note42 a ex:ProjectNote . ex:ProjectNote rdfs:subClassOf ex:Document . ex:Retrievable a rdfs:Class . ``` La propuesta añade una tripleta: ``` ex:Document rdfs:subClassOf ex:Retrievable . ``` La [documentación sobre conservatividad](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/modules-and-conservativity.md) distingue esta comparación de una tabla finita de reglas de una garantía general de conservatividad lógica. Nuestro plan con `owl-rl` informó de una inserción, cero tripletas afectadas en el campo de impacto estructural, `risk_score: low` y `not_conservative_under_rule_table`. | Tripleta abreviada | Por qué aparece | | --- | --- | | Document subclass of Retrievable | La propia aserción añadida | | ProjectNote subclass of Retrievable | Nueva derivación mediante la cadena de subclases | | note42 type Retrievable | Nueva derivación a partir de esa clasificación | Son **tres consecuencias nuevas: una aserción y dos derivaciones nuevas**. El certificado de razonamiento contiene tres derivaciones porque también incluye `note42 type Document`, que ya se deducía del grafo inicial. La [demostración publicada por el proyecto](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/README.md) informa de 901 consecuencias nuevas en 0,04 segundos y de otro ejercicio con 259 derivaciones certificadas y una falsificación rechazada. No reprodujimos esos recuentos ni tiempos. Como muestra nuestro ejemplo, el recuento de consecuencias puede incluir la aserción añadida. Nuestro proceso batch también terminó con código `0`, aunque el informe de conservatividad anidado contenía `exit_code: 1`. Ese resultado semántico puede corresponder a un cambio intencionado. El proceso de aprobación debe inspeccionar el informe y registrar la decisión; comprobar únicamente el código del proceso lo pasa por alto. ## ¿Puede un contexto RAG más pequeño conservar la misma conclusión? **Open Ontologies puede evaluar si un fragmento del grafo sigue sustentando tripletas positivas concretas, sin variables, bajo el perfil de reglas elegido.** Tú aportas las afirmaciones. La herramienta no extrae ni valida todas las frases de una respuesta generada. Conservar un porcentaje de tripletas cercanas tampoco demuestra que hayan sobrevivido las premisas necesarias. En este caso, el objetivo es `note42 type Retrievable`. El fragmento intacto contiene las tres tripletas de esa derivación y omite la declaración independiente de la clase. El fragmento truncado elimina `ProjectNote subClassOf Document`. Ambos siguen siendo subconjuntos del grafo propuesto. La [guía de conservación de consecuencias en proyecciones](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/projection-entailment.md) distingue con nombres propios los resultados comprobados, afirmados y sin comprobar: | Ejecución | Resultado por objetivo | Código del proceso | Implicación para la aprobación | | --- | --- | --- | --- | | Fragmento intacto, sin comprobador configurado | `preserved_unchecked` | 0 | El motor deriva el objetivo; falta la verificación independiente | | Fragmento truncado, sin comprobador configurado | `lost_under_profile_unchecked` | 1 | El perfil seleccionado ya no deriva el objetivo a partir del fragmento | | Fragmento intacto, comprobador obligatorio | `certificate_rejected`, `STOP_THE_LINE` | 2 | Dejar pendiente y revisar el error original del comprobador | En la tercera fila, el informe incluye el mismo error de ejecución: `failed to locate application`. La etiqueta de rechazo de la capa que invoca el comprobador no demuestra que se haya refutado una regla. No obtuvimos `preserved_checked` en este entorno. El resultado de pérdida bajo un perfil también tiene un límite: es un resultado negativo del motor dentro de sus reglas admitidas; no prueba que la conclusión no pueda deducirse bajo otras lógicas de ontologías. Si el flujo exige una prueba, dejaríamos pendiente el resultado positivo sin verificar, restauraríamos la premisa perdida e investigaríamos el fallo del comprobador antes de permitir que el agente utilizase la afirmación. La conservación de consecuencias tampoco modifica la autorización. Nuestra [guía de permisos en RAG](/es/blog/rag-permissions-sharepoint-confluence-drive/) explica cómo determinar si el usuario puede recuperar esos datos. ## ¿Qué debe incluir el registro de aprobación? **El registro de aprobación debe identificar la revisión del grafo, las aserciones seleccionadas, el perfil de reglas, el cambio semántico y el resultado exacto del comprobador.** Si interviene un fragmento recuperado, añade los veredictos por objetivo. Esta es nuestra propuesta de política de aplicación; el motor no aprueba automáticamente los cambios del negocio. | Registro | Pregunta de aceptación | | --- | --- | | Identidad del motor y del comprobador | ¿Qué ejecutables o compilaciones se utilizaron? ¿Coinciden sus hashes con las versiones revisadas? | | Revisión del grafo y bytes de las aserciones | ¿Describe el certificado la entrada exacta aprobada para esta ejecución? | | Ámbito y perfil seleccionados | ¿Qué grafos y reglas se utilizaron? ¿Se rechazó alguna construcción u objetivo relevante? | | Informe de cambio semántico | ¿Ha aceptado un revisor las consecuencias y resuelto los hallazgos pendientes, con independencia de la etiqueta de riesgo estructural? | | Stdout, stderr y código del comprobador | ¿Emitió el comprobador previsto un resultado de verificación satisfactorio? | | Fragmento, objetivos explícitos y veredictos | ¿Cuenta cada afirmación derivada necesaria con la evidencia que exige tu aplicación? | El [documento sobre la base de confianza](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/trusted-computing-base.md) explica que el comprobador lee archivos de certificados, no el estado que tu aplicación pretendía utilizar. No inspecciona `scope.tsv`; quien lo invoca debe revisar esa selección. Un resumen criptográfico vincula bytes, pero no acredita su veracidad, vigencia ni permisos. En este experimento, la decisión sigue siendo **dejar pendiente la aprobación hasta completar la verificación independiente**. El rechazo del certificado falsificado aporta evidencia, pero no sustituye una comprobación satisfactoria del certificado que quieres utilizar. Repite los controles de aceptación y rechazo en tu entorno de despliegue antes de conectarlos a un agente. ## ¿Cómo se conecta Open Ontologies a Claude Code? **Registra Open Ontologies como servidor MCP local mediante stdio, con rutas explícitas al ejecutable y al almacén.** Decide cómo persistir los datos: el almacén predeterminado está en memoria y no conserva el grafo al reiniciar el proceso. Una conexión MCP activa tampoco confirma que esté instalado el comprobador de pruebas independiente. La [configuración de almacenamiento y embeddings](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/src/config.rs) de la versión consultada define el modo en memoria y el persistente. Siguiendo las [instrucciones actuales de MCP en Claude Code](https://code.claude.com/docs/en/mcp), este registro utiliza el transporte local: ``` claude mcp add \ --env OPEN_ONTOLOGIES_STORAGE_MODE=persistent \ --transport stdio open-ontologies -- \ /absolute/path/open-ontologies \ --data-dir /absolute/path/oo-store serve ``` Sustituye ambas rutas absolutas. Configura y verifica el comprobador por separado; después inspecciona la conexión con `/mcp`. Contrastamos la estructura del comando con la documentación, pero no ejecutamos una sesión de Claude Code ni probamos todos los clientes MCP. `--data-dir` es una opción de la CLI, no una variable de entorno. Reserva tiempo para instalar ambos ejecutables y completar una comprobación satisfactoria en el entorno de despliegue. Nuestra prueba no demuestra que puedas dejarlo instalado y verificado en un minuto. ## ¿Cuándo utilizaríamos Open Ontologies? **Evaluaríamos Open Ontologies cuando un agente dependa de aserciones y reglas explícitas, revisables y con consecuencias relevantes.** Empieza con una afirmación importante, un cambio de ontología y una derivación alterada deliberadamente. Amplía el alcance cuando el entorno de despliegue demuestre tanto la aceptación independiente satisfactoria como el rechazo esperado. Si necesitas integrar esta capa de razonamiento en una aplicación, nuestro [servicio de desarrollo de productos y agentes de IA](/es/services/artificial-intelligence/) puede ayudarte. Define las afirmaciones y los criterios de aprobación antes de ampliar el grafo. ## Preguntas sobre la verificación de pruebas de Open Ontologies ### ¿Es Open Ontologies un proveedor de Terraform? La analogía con Terraform describe la planificación, revisión, aplicación y reversión de cambios de ontología. No establece compatibilidad con proveedores de Terraform ni con HCL. Trata Open Ontologies como una herramienta de razonamiento y gestión de cambios con funcionamiento propio. Revisa sus comandos y formatos de evidencia antes de diseñar una integración basada en esa analogía. ### ¿Evita Open Ontologies todas las alucinaciones de un agente? No. El comprobador cubre conclusiones formales concretas a partir de aserciones aportadas y reglas admitidas. Un agente puede extraer una aserción incorrecta, omitir un objetivo necesario, describir mal el resultado o afirmar algo ajeno a la prueba. La aplicación debe vincular las tripletas comprobadas con las afirmaciones que publica y conservar las fuentes que sustentan las aserciones. ### ¿Sirve el mismo certificado para certificar razonamiento OWL DL? La vía documentada reason --certificate admite rdfs, owl-rl y owl-rl-ext; owl-dl rechaza esa opción. El proyecto ofrece otros mecanismos de verificación que debes evaluar por separado. Una comprobación satisfactoria dentro de un conjunto de reglas admitido no permite afirmar que todas las características de OWL o todas las respuestas del motor estén certificadas. ### ¿Una prueba demuestra que las reglas Horn personalizadas son correctas? Un certificado Horn con reglas aportadas demuestra una conclusión relativa a esas reglas y a las aserciones. Las reglas siguen siendo supuestos. Conserva completos los veredictos, como entailed_under_supplied_rules, y revisa la tabla de reglas y su resumen criptográfico. Reducir el resultado a una etiqueta genérica de demostrado ocultaría un supuesto que el revisor necesita conocer. ### ¿Ejecutar MCP localmente mantiene todos los datos en mi dispositivo? El razonamiento local no garantiza que todo el flujo de IA sea local. Los resultados llegan al cliente MCP, cuyo modelo puede ejecutarse remotamente. La configuración consultada también admite una API de embeddings compatible con OpenAI. La [guía de inicio](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/quickstart.md) documenta descargas de modelos para inicializar embeddings. Revisa la compilación, el proveedor y el flujo de datos del cliente antes de afirmar que todo permanece local. ### ¿Explica derivations.tsv todas las justificaciones posibles? No. Según la guía de certificados, el archivo registra un paso de derivación por cada tripleta inferida nueva y conserva la primera derivación encontrada. Una conclusión puede tener otras justificaciones válidas que el archivo no enumera. Para esa cuestión, utiliza los mecanismos específicos de justificación y procedencia del proyecto y evalúa sus garantías por separado. Modelos e infraestructura ## Qué leer después Selección de modelos, economía de inferencia, despliegue local, compresión y serving. [Empieza aquí**Alojar LLMs en la UE: Cuándo Salen a Cuenta los Open Weights**](/es/blog/self-hosting-llms-eu-cost/) - [Cue Turn Detection: teléfonos, benchmarks y límites](/es/blog/cue-turn-detection-phone-numbers/) - [Google SAM ahora es Agent Mesh: MCP entre equipos](/es/blog/google-sam-agent-mesh-mcp-tools/) - [EdgeQuake: GraphRAG en PostgreSQL y memoria MCP para agentes](/es/blog/edgequake-postgresql-graphrag-mcp-agent-memory/) - [BitNet en CPU: 2B4T, requisitos de RAM y la cifra de 100B](/es/blog/bitnet-cpu-llm-ram-requirements/) - [SuperPenguin: costes de IA por PR, cliente y función](/es/blog/superpenguin-ai-roi-cost-per-pr-customer/) [Artículo siguiente**Cue Turn Detection: teléfonos, benchmarks y límites**](/es/blog/cue-turn-detection-phone-numbers/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min de lectura · 3 nov 2026 Última revisión 3 de noviembre de 2026 [**Siguiente**](/es/blog/graph-engineering-ai-agents/)