Foundgine - Plataforma de execução semântica programável para .NET

O que é Foundgine

Aplicações modernas raramente têm um único chamador. Web, mobile, APIs REST, clientes GraphQL, serviços internos, automação e, cada vez mais, agentes de IA — todos precisam acessar os mesmos dados e operações de negócio. O problema é que, sem uma fronteira comum, cada interface acaba desenvolvendo seu próprio caminho de autorização, validação, tradução de consulta e acesso a dados. O resultado é um ecossistema fragmentado, com regras de segurança duplicadas, semânticas divergentes e superfícies de ataque maiores.

Foundgine é uma plataforma de execução semântica programável para .NET que cria uma fronteira controlada entre os chamadores da aplicação e os dados e operações que eles estão autorizados a executar. Em vez de permitir que cada chamador implemente sua própria lógica de validação, autorização, tradução de consulta e acesso a dados, o Foundgine converte intenção estruturada em um plano de execução autorizado e executa esse plano através de um provedor.

A ideia central pode ser resumida assim:

Os chamadores descrevem o que desejam. O Foundgine determina o que é permitido, como deve executar e qual provedor executa.

O pipeline central de execução segue um fluxo determinístico: Intenção → Modelo Semântico → Resolução → Autorização → Plano → Reescrita/Otimização → Compilação do Provedor → Execução → Resultado + Evidência. Cada etapa é uma fronteira arquitetural — a autorização não é um middleware opcional, mas um estágio obrigatório que alimenta restrições diretamente no plano de execução.

É importante esclarecer o que o Foundgine não é: não é um substituto de ORM, não é um banco de dados, não é um servidor GraphQL, não é um LLM, não é um framework de agentes e não é um provedor de identidade. Ele é uma camada de execução que pode ficar abaixo desses tipos de sistemas, atuando como o cérebro que decide o que pode ser executado e como.

A visão de longo prazo é estabelecer um limite de execução semântica estável entre o que um sistema pede e o que uma aplicação está disposta a executar — um limite que funcione tanto para software tradicional quanto para agentes inteligentes.

Arquitetura Central e Detalhes Técnicos

Separação de preocupações

A arquitetura do Foundgine é deliberadamente modular, com cada componente responsável por uma única preocupação:

• Modelo semântico — define as capacidades voltadas para a aplicação, independente de detalhes físicos de persistência

• Intenção — descreve o que o chamador deseja, sem amarrar diretamente a um provedor físico

• Autorização — determina quais partes da operação solicitada são permitidas e pode contribuir com predicados ou restrições ao plano de execução

• Planejador — constrói uma representação independente do provedor da operação solicitada

• Reescrita e otimização — transforma o plano preservando semântica e restrições de autorização

• Provedor — compila e executa o plano contra um backend concreto

Modelo de execução multi-callers

O ponto arquitetural central é que REST/API, GraphQL, JSON, agentes de IA e automação — todos normalizam para uma Intenção Semântica que alimenta o Planejador Foundgine. Esse planejador roteia a operação para um provedor SQL, InMemory ou provedores futuros. O objetivo é evitar implementar semânticas de execução separadas para cada interface.

Por que o plano intermediário importa

O plano é a fronteira arquitetural entre intenção semântica e execução física. Ele dá ao runtime um ponto único para: preservar restrições de autorização, validar dependências, reescrever operações, estimar custo, raciocinar sobre capacidades do provedor, otimizar execução e produzir evidência de execução. Esse é o mecanismo que permite que múltiplas superfícies de entrada e provedores compartilhem a mesma semântica de execução.

Modelo semântico vs. modelo de persistência

Um modelo de persistência descreve como os dados são armazenados. Um modelo semântico descreve o que uma aplicação está disposta a expor e operar. Esses modelos não precisam ser idênticos — e não deveriam ser. A superfície semântica pode ser menor, mais segura e mais proposital que o modelo físico. Por exemplo, um modelo de persistência pode conter campos internos como TenantId ou InternalRiskScore que um modelo semântico voltado para aplicação não expõe.

Foundgine e Agentes de IA

O paradigma convencional de agentes de IA acessando dados é perigoso em sua simplicidade: IA → gerar SQL → banco. Esse padrão dá ao modelo de linguagem autoridade direta sobre consultas SQL, exigindo credenciais de banco acessíveis ao agente e removendo a aplicação da equação de autorização. O Foundgine inverte essa lógica.

No modelo do Foundgine, o fluxo é: Agente de IA → intenção estruturada → Foundgine (resolver/validar/autorizar/planejar/executar) → PostgreSQL. O agente declara o que deseja alcançar, mas o Foundgine — não o modelo de IA — é a autoridade sobre quais capacidades de aplicação são permitidas e como são executadas.

Um modelo de IA decide o que quer realizar, mas não se torna a autoridade sobre quais dados de aplicação pode acessar, nem precisa de credenciais diretas de banco. Isso é deliberadamente diferente do padrão AI → generate SQL → database. O Foundgine mantém a aplicação no controle de autorização e execução enquanto permite que agentes de IA e outros chamadores estruturados usem as capacidades da aplicação.

Para suportar essa integração, o ecossistema oferece pacotes dedicados:

• Foundgine.AI — integração de ferramentas via Microsoft.Extensions.AI

• Foundgine.Agent.OpenAI — integração de agentes OpenAI

• Foundgine.MCP — adaptador MCP que expõe capacidades semânticas via transporte HTTP Streamable em /mcp, com descoberta automatizada em .well-known/mcp.json

A identidade, o contexto de locatário e a autorização permanecem propriedade do host, fornecidos através do SecurityExecutionContext. Um benchmark dedicado mede o caminho do agente: como um agente chamando o Foundgine via MCP se compara a um agente chamando um caminho EF Core convencional diretamente, cobrindo contagem de chamadas de ferramentas, throughput, tempo de parede e carga estimada de tokens por transação.

A história E2E da cadeia de suprimentos torna essa arquitetura concreta: agente → MCP → Foundgine → PostgreSQL, com PlaceOrder como fatia vertical de alta garantia cobrindo autorização, propriedade, validação, precificação no servidor, verificações de inventário, mutação atômica, proteção contra replay e evidência de execução.

Evidência de Performance

O benchmark de performance mais documentado do Foundgine é o CoffeeBeanery PostgreSQL graph benchmark (12 de agosto de 2026). Três execuções independentes foram realizadas contra um workload de grafo PostgreSQL determinístico com a seguinte estrutura: Customer → CustomerBankingRelationship → Contract → Transaction.

Fixture do benchmark:

Resultados de consulta na concorrência 32

Traduzindo em melhorias relativas:

• ~20,0× o throughput da baseline sem cache

• ~20,4× com cache de plano

• ~16,7× menor latência p95 sem cache

• ~17,0× menor latência p95 com cache

A vantagem em consultas grandes não depende do caching de plano de provedor — o ganho substancial já está presente sem ele. Em termos de confiabilidade, as três execuções bem-sucedidas reportaram 0 erros de aplicação, 0 timeouts e 0 requisições canceladas.

Quanto a mutações, o benchmark é transparente: a performance de mutação é mais variável e não deve ser apresentada como a principal reivindicação de performance do Foundgine. Os resultados são evidência específica de workload, não uma declaração universal de que o Foundgine é mais rápido que qualquer workload de EF Core ou GraphQL. A reivindicação apropriada é: Foundgine demonstra forte performance de consulta para este workload de grafo com muitos relacionamentos, com o caching de plano de provedor medido separadamente.

Ecossistema, Pacotes e Integrações

Ao contrário de uma biblioteca monolítica, o Foundgine é distribuído como um conjunto coordenado de pacotes NuGet. Isso dá aos usuários um caminho claro: dos contratos independentes de provedor, passando por semântica, planejamento e execução, até SQL, IA, MCP, GraphQL, AOT e componentes de autorização de alta garantia.

Snapshot NuGet: versão mais recente 0.5.2, alvo .NET 9.0, com 18 pacotes publicados e 7.801 downloads totais no conjunto de pacotes.

A integração GraphQL é feita via adaptador Hot Chocolate (Foundgine.GraphQL.HotChocolate), que converte seleções GraphQL em requisições semânticas Foundgine — o GraphQL é usado como interface, mas não se torna o modelo de execução. O transporte MCP expõe capacidades semânticas via HTTP Streamable em /mcp, com metadados de descoberta disponíveis em .well-known/mcp.json.

A documentação está publicada no site Foundgine.io, incluindo um índice legível por máquina (llms.txt / llms-full.md) para ferramentas de IA e agentes LLM. Em termos de verificação externa, o Foundgine recebeu 90/100 na auditoria AST Security Audit & Verification da UnofficialOS, com notas máximas em Edge Sandbox Safety, Open-Source License Compliance, Documentation & Quickstart Quality e Repository Hygiene & Provenance.

Conformidade de Segurança e Mutações de Alta Garantia

O Foundgine trata requisitos de segurança como parte do contrato de execução semântica. Invariantes de segurança exigidos são propagados nos planos e verificados contra as capacidades do provedor antes da execução. Isso evita que um provedor execute silenciosamente uma capacidade cujas garantias de segurança ele não pode preservar.

A progressão de segurança inclui atualmente: registro de invariante de segurança, prova de invariante no nível do plano, conformidade do provedor SQL, conformidade de mutação de alta garantia e conformidade entre provedores.

Responsabilidade compartilhada

É fundamental entender o escopo: as fronteiras de autorização e execução do Foundgine visam reduzir caminhos de acesso inseguros, mas a segurança da aplicação permanece uma responsabilidade compartilhada. Autenticação, gestão de segredos, segurança de transporte, rate limiting, permissões de banco e segurança de implantação permanecem responsabilidades da aplicação e da infraestrutura.

Segurança de mutação de alta garantia

O cancelamento de mutação é propagado até a fronteira de execução do provedor e não pode confirmar após uma checagem de cancelamento falhar. O contexto de autorização de alta garantia PostgreSQL é seguro quanto ao ciclo de vida: identidade de ator/locatário é imutável, versões são estritamente monotônicas, identidades deletadas mantêm um tombstone de versão, e configuração de autorização ausente falha fechada (fail closed). Escritas de ciclo de vida usam o mesmo limite de serialização de bloqueio de linha que as leituras de autorização de mutação.

Integridade criptográfica

A evidência de autorização PostgreSQL persistida é criptograficamente vinculada à sua carga de segurança canônica completa usando uma chave HMAC-SHA256 mantida externamente, com ciclo de vida autorizado de chaves (estados ativo/verificação-apenas/retirado), proveniência de rotação monotônica, snapshots de anel atômicos imutáveis e verificações seguras de retirada contra evidência persistida. Chaves desconhecidas, incompatibilidade de algoritmo, valores alterados de ator/locatário/estado/versão/fingerprint e tombstones adulterados falham fechados. A rotação de chaves é suportada através de um anel de verificação de chaves, mantendo o material criptográfico fora do banco e da identidade de cache.

Portões de verificação

A arquitetura de verificação do Foundgine segue uma progressão rigorosa: testes unitários → integração PostgreSQL → penetração de autorização → entrada semântica adversarial → smoke de performance → E2E da cadeia de suprimentos. Cada portão cobre um aspecto específico, dos contratos determinísticos até o workflow completo agente → MCP → Foundgine → PostgreSQL. No workflow CI de release, os portões de unidade, integração, penetração, adversarial e performance são pré-requisitos para a publicação de pacotes.

Primeiros Passos e Status Atual

Para desenvolvedores começando com o Foundgine, o caminho mais eficiente é começar pelo índice de documentação no site publicado em Foundgine.io.

A recomendação central de onboarding é: comece com o provedor InMemory (Foundgine.InMemory) para desenvolvimento e teste local antes de adotar SQL. Esse provedor executa o mesmo modelo semântico sem necessidade de banco de dados, permitindo iterar rapidamente sobre definições de modelo, intenção e autorização — e só depois validar contra um PostgreSQL real.

O alvo é .NET 9.0, e para implantações orientadas a Native AOT, o pacote Foundgine.Aot fornece atributos de metadados e suporte em runtime para metadados gerados, permitindo builds AOT sem perda de funcionalidade semântica.

É importante estabelecer expectativas de maturidade: a versão atual é 0.5.x, e a estabilidade da API pública deve ser tratada conforme a política de release e compatibilidade do projeto. Para notas de engenharia detalhadas e datadas, consulte o CHANGELOG.md — que registra mudanças significativas como a promoção do Foundgine.Authorization a biblioteca real (com quorum de testemunhas, ciclo de vida de credenciais, reconciliação de journal e failover) na versão 0.5.0.

A estrutura central do repositório inclui:

• src/Foundgine.MCP — adaptador MCP de primeira classe

• benchmarks/CoffeeBeanery.Performance/ — benchmark de consulta PostgreSQL

• benchmarks/AgentEndToEnd/ — benchmark do caminho de agente

• docs-site/ — fonte do site publicado

Para onboarding orientado a agentes, o llms.txt legível por máquina fornece um índice de documentação que agentes de IA e ferramentas LLM podem consumir diretamente.

FAQ