En este artículo
Cómo validar certificados de derivación de Open Ontologies
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 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.
Fecha de pruebas e investigación: . Utilizamos los ejecutables para Linux de 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 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 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 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 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.tsvEl 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: <https://example.com/knowledge/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
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 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 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 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 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 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 de la versión consultada define el modo en memoria y el persistente. Siguiendo las instrucciones actuales de MCP en Claude Code, 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 serveSustituye 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 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 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.