lithoglyph

Lithoglyph (del griego lithos "piedra" + glyphein "grabar") se describe como un núcleo de base de datos narrativo, reversible y de grado auditoría. Su tesis declarada es que los esquemas, restricciones, migraciones, bloques y diarios son artefactos narrativos en lugar de un sustrato opaco, y que los datos se graban en piedra: permanentes, auditables y reversibles. El estado del proyecto se declara activo pero con prioridad secundaria. El README dice que avanza hacia producción para uso especializado en periodismo, artes narrativas y medios/comunicaciones, mientras que VeriSimDB se nombra como el proyecto principal actual. Sugiere que Lithoglyph y su lenguaje de consulta GQL son probablemente la elección correcta para la mayoría de los flujos de trabajo de periodismo, narrativa y medios, y que VeriSimDB y VCL/VCL-UT cobran relevancia para la verificación investigativa entre fuentes, el seguimiento de entidades a gran escala, la consistencia de identidad a largo plazo o la demostración de que los datos entre bases de datos no se han desviado. Los valores primarios declarados sitúan la auditabilidad por encima del rendimiento, el significado por encima de las características y la reversibilidad por encima del throughput, con la comprensión por agentes como requisito. Los dominios objetivo enumerados son periodismo de investigación, gobernanza/cumplimiento, ecosistemas agénticos y traspaso multi-repositorio, y archivos culturales o institucionales a largo plazo. El repositorio se organiza en spec (especificaciones en formato AsciiDoc y justificación), core-forth (Form.Blocks y Form.Model, descritos como el núcleo de verdad), core-zig (Form.Bridge, ABI y encuadre de puertos), core-factor (Form.Runtime, GQL e introspección), control-plane (una puerta de enlace opcional Elixir/OTP), tools (utilidades de render/inspección/diagnóstico), test-vectors (bytes dorados y renders dorados) y stories (ejemplos narrativos y artefactos de incorporación). La arquitectura está estratificada por lenguaje y responsabilidad. Form.Blocks en Forth proporciona almacenamiento determinista, diario y primitivas de reversibilidad: bloques de tamaño fijo con cabeceras simbólicas, un diario de solo anexado, recuperación ante fallos y comprobaciones de integridad, y guía de reparación. Form.Model en Forth es la capa lógica multimodelo que cubre colecciones de documentos, colecciones de aristas, metadatos de esquema y restricciones, y artefactos de migración. Form.Bridge en Zig ofrece una ABI estable de Zig sin dependencia de C, handles opacos, búferes de bytes y códigos de error explícitos, realizando solo marshalling y usando callconv(.C) para compatibilidad FFI sin una cadena de herramientas C. Form.Runtime en Factor gestiona el parseo/planificación/ejecución de GQL, explain e introspección, introspección de pasos del planificador, superficies de explicación de restricciones y superficies de procedencia. Form.Normalizer combina Factor y Lean 4 para el descubrimiento automático de dependencias funcionales (DFD/TANE/FDHits), la codificación de tipos de FDs en GQL-DT, predicados de forma normal desde 1NF hasta BCNF, evolución de esquema con prueba portante y explicaciones narrativas para las decisiones de normalización. Form.ControlPlane en Elixir/OTP es opcional y proporciona un motor central fuera de proceso mediante puerto, sesiones, supervisión y coordinación de borde de clúster. Los invariantes centrales se presentan como no negociables: la verdad en disco es propiedad de la capa de bloques/diario y las capas superiores no la eluden; toda operación mutante se registra en el diario antes de considerarse confirmada; toda operación confirmada debe tener una inversa definida o marcarse explícitamente como irreversible-con-historia; los bloques y las entradas del diario deben ser renderizables de forma determinista en forma legible por humanos/agentes; los resultados de consulta pueden incluir opcionalmente punteros de procedencia a diario y bloques; y las restricciones son explicables, con rechazos que devuelven razones, punteros y justificación narrativa. GQL (Glyph Query Language) es la interfaz de consulta nativa. El subconjunto de prueba de concepto cubre INSERT de un documento en una colección, INSERT de una arista con from, to, type y props, SELECT con predicados simples, EXPLAIN que devuelve plan y razones, INTROSPECT de esquema y restricciones, y salida de procedencia opcional. Los no objetivos explícitos incluyen ser un reemplazo directo de Postgres, ganar microbenchmarks y enviar consenso distribuido completo en la primera PoC. Los criterios de aceptación de la PoC incluyen apertura/cierre de nodo único, un diario de solo anexado con renderizado determinista, inserción/selección de documentos y aristas, rechazo de restricciones que devuelve una carga útil de explicación, un artefacto de migración registrado y reversible, vectores de prueba dorados que pasan, y comprobaciones de costura (B↔M, M↔R, B↔R) que pasan en el congelamiento. Las preguntas abiertas se rastrean en un archivo de traspaso legible por máquina, que cubre el diseño mínimo de cabecera de bloque, el esquema mínimo de entrada de diario, la elección de codificación de blob ABI, la gramática de la PoC de GQL, el momento de introducción de Elixir/OTP y varios temas autonormalizantes como el algoritmo de descubrimiento de FD predeterminado, el manejo de FD aproximadas, el alcance de la desnormalización, la integración de pruebas GQL-DT y la reescritura de consultas. El README enlaza documentación para inicio rápido, versionado, registro de cambios, arquitectura, hoja de ruta, filosofía, especificación de GQL, tipos dependientes de GQL, base de datos autonormalizante, formatos de bloque y diario, despliegue, observabilidad, seguridad y autenticación, referencia de API, migración desde RDBMS, patrones de integración y un paquete de trabajo interactivo de documental/periodismo. Los proyectos relacionados enumerados incluyen GQL-DT, Lithoglyph Studio, BoFIG, Zotero-Lithoglyph, Lithoglyph Debugger y FormBase. El código es MPL-2.0 y la documentación es CC-BY-SA-4.0.