lithoglyph

Lithoglyph (do grego lithos "pedra" + glyphein "entalhar") é descrito como um núcleo de banco de dados narrativo, reversível e de nível de auditoria. Sua tese declarada é que esquemas, restrições, migrações, blocos e diários são artefatos narrativos, e não um substrato opaco, e que os dados são entalhados em pedra: permanentes, auditáveis e reversíveis. O status do projeto é declarado ativo, mas com prioridade secundária. O README afirma que está caminhando para produção para uso especializado em jornalismo, artes narrativas e mídia/comunicações, enquanto o VeriSimDB é nomeado como o projeto primário atual. Sugere que o Lithoglyph e sua linguagem de consulta GQL são provavelmente a escolha certa para a maioria dos fluxos de trabalho de jornalismo, narrativa e mídia, com o VeriSimDB e o VCL/VCL-UT tornando-se relevantes para verificação investigativa entre fontes, rastreamento de entidades em larga escala, consistência de identidade de longo prazo ou para provar que os dados entre bancos de dados não sofreram desvio. Os valores primários declarados classificam a auditabilidade acima do desempenho, o significado acima dos recursos e a reversibilidade acima da taxa de transferência, com a compreensão por agentes sendo exigida. Os domínios-alvo listados são jornalismo investigativo, governança/conformidade, ecossistemas agênticos e transferência entre múltiplos repositórios, e arquivos culturais ou institucionais de longo prazo. O repositório está organizado em spec (especificações em formato AsciiDoc e justificativas), core-forth (Form.Blocks e Form.Model, descritos como o núcleo da verdade), core-zig (Form.Bridge, ABI e enquadramento de porta), core-factor (Form.Runtime, GQL e introspecção), control-plane (um gateway opcional em Elixir/OTP), tools (utilitários de renderização/inspeção/diagnóstico), test-vectors (bytes dourados e renderizações douradas) e stories (exemplos narrativos e artefatos de integração). A arquitetura é dividida em camadas por linguagem e responsabilidade. Form.Blocks em Forth fornece armazenamento determinístico, diário e primitivas de reversibilidade: blocos de tamanho fixo com cabeçalhos simbólicos, um diário somente de acréscimo, recuperação de falhas e verificações de integridade, e orientação de reparo. Form.Model em Forth é a camada lógica multimodelo que abrange coleções de documentos, coleções de arestas, metadados de esquema e restrições, e artefatos de migração. Form.Bridge em Zig oferece uma ABI Zig estável sem dependência de C, identificadores opacos, buffers de bytes e códigos de erro explícitos, fazendo apenas marshalling e usando callconv(.C) para compatibilidade FFI sem uma cadeia de ferramentas C. Form.Runtime em Factor lida com análise/planejamento/execução de GQL, explain e introspecção, introspecção de etapas do planejador, superfícies de explicação de restrições e superfícies de proveniência. Form.Normalizer combina Factor e Lean 4 para descoberta automática de dependência funcional (DFD/TANE/FDHits), codificação de tipos de FDs em GQL-DT, predicados de forma normal de 1NF a BCNF, evolução de esquema com prova embutida e explicações narrativas para decisões de normalização. Form.ControlPlane em Elixir/OTP é opcional e fornece um mecanismo central fora do processo via porta, sessões, supervisão e coordenação de borda de cluster. Os invariantes centrais são apresentados como não negociáveis: a verdade em disco é de propriedade da camada de bloco/diário e as camadas superiores não a contornam; toda operação de mutação é registrada no diário antes de ser considerada confirmada; toda operação confirmada deve ter um inverso definido ou ser explicitamente marcada como irreversível-com-história; blocos e entradas de diário devem ser deterministicamente renderizáveis em forma legível por humanos/agentes; resultados de consulta podem opcionalmente incluir ponteiros de proveniência para o diário e blocos; e as restrições são explicáveis, com rejeições retornando motivos, ponteiros e justificativa narrativa. GQL (Glyph Query Language) é a interface de consulta nativa. O subconjunto de prova de conceito abrange INSERT de um documento em uma coleção, INSERT de uma aresta com from, to, type e props, SELECT com predicados simples, EXPLAIN retornando plano e motivos, INTROSPECT de esquema e restrições, e saída opcional de proveniência. Os não-objetivos explícitos incluem ser um substituto direto do Postgres, vencer microbenchmarks e entregar consenso distribuído completo na primeira PoC. Os critérios de aceitação da PoC incluem abertura/fechamento de nó único, um diário somente de acréscimo com renderização determinística, inserção/seleção de documentos e arestas, rejeição de restrição retornando um payload de explicação, um artefato de migração registrado e reversível, vetores de teste dourados aprovados e verificações de junção (B↔M, M↔R, B↔R) aprovadas no congelamento. Questões em aberto são rastreadas em um arquivo de transferência legível por máquina, abrangendo layout mínimo do cabeçalho do bloco, esquema mínimo de entrada do diário, escolha de codificação de blob da ABI, gramática da PoC de GQL, momento de introdução do Elixir/OTP e vários tópicos auto-normalizantes, como algoritmo padrão de descoberta de FD, tratamento de FD aproximada, escopo de desnormalização, integração de prova GQL-DT e reescrita de consulta. O README vincula documentação para início rápido, versionamento, changelog, arquitetura, roteiro, filosofia, especificação GQL, tipos dependentes GQL, banco de dados auto-normalizante, formatos de bloco e diário, implantação, observabilidade, segurança e autenticação, referência de API, migração de RDBMS, padrões de integração e um pacote de trabalho interativo de documentário/jornalismo. Projetos relacionados listados incluem GQL-DT, Lithoglyph Studio, BoFIG, Zotero-Lithoglyph, Lithoglyph Debugger e FormBase. O código é MPL-2.0 e a documentação é CC-BY-SA-4.0.