Foundgine - Plataforma de ejecución semántica programable para .NET

Qué es Foundgine

Foundgine es una plataforma de ejecución semántica programable para .NET que resuelve un problema estructural creciente en las aplicaciones modernas: la proliferación de llamadores heterogéneos. Hoy, una aplicación típica recibe peticiones desde la web, aplicaciones móviles, APIs REST, clientes GraphQL, servicios internos, automatizaciones y agentes de IA. Sin una frontera de ejecución común, cada una de estas superficies tiende a desarrollar su propio camino de autorización, validación, traducción de consultas y acceso a datos. El resultado es duplicación de lógica, inconsistencias de seguridad y un mantenimiento costoso.

Foundgine ataca ese problema desde la raíz: crea un límite controlado entre los llamadores de aplicación y los datos u operaciones que se les permite ejecutar. En lugar de que cada llamador implemente su propia validación y autorización, Foundgine convierte la intención estructurada en un plan de ejecución autorizado, y ejecuta ese plan a través de un proveedor concreto.

La idea central es directa:

"Los llamadores describen lo que desean. Foundgine determina qué se permite, cómo ejecutar y qué proveedor lo ejecuta."

Es importante delimitar con precisión lo que Foundgine no es. No es un reemplazo de ORM, no es una base de datos, no es un servidor GraphQL, no es un LLM, no es un framework de agentes ni un proveedor de identidad. Es una capa de ejecución que se sitúa debajo de esos sistemas, actuando como intermediaria semántica entre lo que un sistema solicita y lo que la aplicación está dispuesta a ejecutar.

El pipeline central de ejecución formaliza ese flujo:

Intención
  ↓
Modelo Semántico
  ↓
Resolución
  ↓
Autorización
  ↓
Plan
  ↓
Reescritura / Optimización
  ↓
Compilación del Proveedor
  ↓
Ejecución
  ↓
Resultado + Evidencia

La visión a largo plazo es ambiciosa y clara: establecer un límite de ejecución semántica estable entre lo que un sistema pide y lo que una aplicación está dispuesta a ejecutar — un límite que funcione tanto para software tradicional como para agentes inteligentes. Esta frontera convierte las capacidades de la aplicación en entidades comprensibles y ejecutables de forma segura por máquinas.

Arquitectura Central y Detalles Técnicos

La arquitectura de Foundgine se fundamenta en una separación estricta de preocupaciones que permite que cada componente evolucione de forma independiente. El modelo semántico define las capacidades visibles a la aplicación; la intención describe lo que el llamador quiere sin vincularse directamente a un proveedor físico; la autorización determina qué partes de la operación solicitada están permitidas y puede contribuir con predicados o restricciones al plan; el planificador construye una representación independiente del proveedor; la reescritura y optimización transforman el plan preservando la semántica y las restricciones de autorización; y el proveedor compila y ejecuta el plan contra un backend concreto.

Modelo de ejecución multi-llamador

El diseño de Foundgine normaliza todas las superficies de entrada a un único modelo de intención semántica:

REST/API
GraphQL
JSON
Agente IA
Automatización
   │
   ▼
Intención Semántica
   │
   ▼
Planificador Foundgine
   │
   ├── SQL
   ├── InMemory
   └── Proveedores futuros

El objetivo es explícito: evitar implementar semánticas de ejecución separadas para cada interfaz. Un llamador REST, un cliente GraphQL y un agente de IA describen su intención de la misma manera, y Foundgine se encarga de que esa intención se traduzca de forma consistente y segura hacia la ejecución física.

Por qué importa el plan intermedio

El plan no es un detalle de implementación; es la frontera arquitectónica entre la intención semántica y la ejecución física. El runtime utiliza ese plan como punto de anclaje para:

• preservar las restricciones de autorización

• validar dependencias

• reescribir operaciones

• estimar costos

• razonar sobre las capacidades del proveedor

• optimizar la ejecución

• producir evidencia de ejecución

Este mecanismo es el que permite que múltiples superficies de entrada y proveedores compartan la misma semántica de ejecución, sin comprometer la seguridad ni la coherencia.

Modelo semántico vs. modelo de persistencia

Un modelo de persistencia describe cómo se almacenan los datos. Un modelo semántico describe qué está dispuesta a exponer y operar la aplicación. Estos modelos no tienen por qué ser idénticos. De hecho, la superficie semántica puede ser más pequeña, más segura y más propositiva que el modelo físico. Por ejemplo, un modelo de persistencia puede contener campos internos como TenantId o InternalRiskScore que el modelo semántico orientado a la aplicación no expone. Esto permite granularidad de seguridad a nivel de modelo, no solo a nivel de consulta.

Foundgine y Agentes de IA

El auge de los agentes de IA ha vuelto más urgente que nunca la necesidad de una frontera de ejecución controlada. El patrón ingenuo IA → generar SQL → base de datos es problemático por varias razones: el modelo de IA decide qué quiere lograr, pero no debería convertirse en la autoridad sobre qué datos de aplicación puede acceder, ni debería necesitar credenciales directas de base de datos.

Foundgine invierte ese paradigma. En lugar de darle al agente acceso directo a la base de datos, el flujo se canaliza a través de la capa semántica:

Agente IA
    │
    │ intención estructurada
    ▼
Foundgine
    ├── resolver
    ├── validar
    ├── autorizar
    ├── planificar
    └── ejecutar
            │
            ▼
        PostgreSQL

La diferencia es deliberada y de fondo: la aplicación mantiene el control sobre la autorización y la ejecución, mientras que la IA y otros llamadores estructurados pueden usar las capacidades de la aplicación sin exceder los límites definidos.

Ecosistema de paquetes para IA

Foundgine ofrece un conjunto de paquetes NuGet específicamente diseñados para la integración con agentes:

• Foundgine.AI — integración de herramientas mediante Microsoft.Extensions.AI, permitiendo que agentes invoquen capacidades semánticas como herramientas.

• Foundgine.Agent.OpenAI — integración específica para agentes OpenAI.

• Foundgine.MCP — adaptador del Model Context Protocol que expone capacidades semánticas e intención neutral respecto a proveedores. Utiliza transporte HTTP Streamable en /mcp, con metadatos de descubrimiento en .well-known/mcp.json.

La identidad, el contexto de inquilino y la autorización permanecen como responsabilidad del host y se suministran a través de SecurityExecutionContext — los agentes nunca reciben credenciales de base de datos.

Validación empírica del camino de IA

Foundgine incluye un benchmark específico del camino de agente que mide cómo un agente que llama a Foundgine vía MCP se compara con un agente que llama directamente al camino EF Core convencional. La suite evalúa cantidad de llamadas a herramientas, rendimiento, tiempo de pared y carga estimada de tokens/contexto por transacción, presentando resultados en una matriz interactiva de workload/concurrencia.

La historia E2E de cadena de suministro hace tangible la arquitectura completa: agente → MCP → Foundgine → PostgreSQL. El workload mezcla operaciones válidas, inválidas y no autorizadas a través de identidades de cliente, servicio al cliente, almacén, compras y administrador. PlaceOrder es la rebanada vertical de alta garantía que integra autorización, verificación de propiedad, validación, precios del lado del servidor, verificación de inventario, mutación atómica, protección de idempotencia/replay y evidencia de ejecución.

Evidencia de Rendimiento

Foundgine ha sido sometido a benchmarks reproducibles para cuantificar su rendimiento real. El benchmark de grafo PostgreSQL CoffeeBeanery es el más representativo, ejercitando un workload determinista de grafo relacional con la siguiente estructura:

Customer
  → CustomerBankingRelationship
      → Contract
          → Transaction

Configuración del fixture

• 1.000 clientes, 4.000 relaciones, 12.000 contratos, 48.000 transacciones

• Concurrencia de 1, 8 y 32

• Medición de 10 segundos por caso con calentamiento de 3 segundos

• Timeout de solicitud de 5 segundos

Resultados de consulta a concurrencia 32

Estos números se traducen en mejoras relativas contundentes:

• ~20,0× el rendimiento de la línea base sin caché

• ~20,4× con caché de plan

• ~16,7× menor latencia p95 sin caché

• ~17,0× menor latencia p95 con caché

Es notable que la ventaja de rendimiento en consultas no depende de la caché de planes: incluso sin ella, Foundgine supera ampliamente a la línea base. Esto indica una ventaja estructural en el diseño, no un artefacto de optimización.

Confiabilidad

Las tres ejecuciones independientes reportaron 0 errores de aplicación, 0 timeouts y 0 solicitudes canceladas, lo que respalda la estabilidad del runtime bajo carga.

Alcance honesto de la reivindicación

Es necesario acotar el alcance. El rendimiento de mutación es más variable y, según la documentación del proyecto, no debe presentarse como la principal reivindicación de rendimiento. Además, estos resultados son evidencia específica de este workload, no una afirmación universal de que Foundgine sea más rápido que todo workload EF Core o GraphQL. Los resultados dependen del workload, esquema, versiones de proveedor, host, fixture y versiones de implementación.

Ecosistema, Paquetes e Integraciones

Foundgine se distribuye como un ecosistema coordinado de paquetes NuGet en lugar de una biblioteca monolítica. Este diseño modular ofrece a los desarrolladores un camino claro desde los contratos y semántica independientes del proveedor, hasta la planificación, ejecución, SQL, IA, MCP, GraphQL, AOT y componentes de autorización de alta garantía.

Snapshot actual de NuGet: versión 0.5.2, objetivo .NET 9.0, 18 paquetes publicados y 7.801 descargas totales en el conjunto.

Paquetes clave y su función

Nota: los números de descargas son descargas reportadas por NuGet, no usuarios únicos ni instalaciones.

Integración GraphQL

La integración con GraphQL se realiza mediante el adaptador Foundgine.GraphQL.HotChocolate, que convierte selecciones GraphQL en solicitudes semánticas Foundgine. De esta manera, GraphQL puede usarse como interfaz sin convertir GraphQL en el modelo de ejecución — el plan semántico intermedio sigue siendo la fuente de verdad sobre autorización y ejecución.

Integración MCP

El adaptador Foundgine.MCP expone las capacidades semánticas mediante transporte HTTP Streamable en /mcp. Los hosts mantienen la identidad, el contexto de inquilino y la autorización, suministrados a través de SecurityExecutionContext. Los metadatos de descubrimiento están disponibles en .well-known/mcp.json para herramientas de descubrimiento automatizado.

Auditoría de seguridad independiente

Foundgine ha sido analizado de forma independiente por UnofficialOS (directorio comunitario independiente de herramientas MCP y agentes IA). Su AST Security Audit & Verification otorga actualmente a Foundgine 90/100, con calificación máxima en Edge Sandbox Safety, Open-Source License Compliance, Documentation & Quickstart Quality y Repository Hygiene & Provenance. Los puntos restantes se registraron en Ecosystem & MCP Alignment porque esa exploración no detectó evidencia de implementación MCP. Foundgine ya incluye metadatos explícitos de descubrimiento MCP en mcp.json y .well-known/mcp.json, pendientes de confirmación en la próxima exploración independiente.

Conformidad de Seguridad y Mutaciones de Alta Garantía

Foundgine trata los requisitos de seguridad como parte del contrato de ejecución semántica. Los invariantes de seguridad requeridos se propagan a los planes y se verifican contra las capacidades del proveedor antes de la ejecución. Esto evita que un proveedor ejecute silenciosamente una capacidad cuyas garantías de seguridad no puede preservar.

Progresión de seguridad

La progresión actual de la seguridad incluye:

1. Registro de invariantes de seguridad

2. Prueba de invariantes a nivel de plan

3. Conformidad del proveedor SQL

4. Conformidad de mutación de alta garantía

5. Conformidad entre proveedores

Responsabilidad compartida

Es importante ser transparente sobre el alcance: los límites de autorización y ejecución de Foundgine están diseñados para reducir vías de acceso inseguras, pero la seguridad de la aplicación sigue siendo una responsabilidad compartida. La autenticación, gestión de secretos, seguridad de transporte, rate limiting, permisos de base de datos y seguridad de despliegue permanecen como responsabilidades de aplicación e infraestructura.

Seguridad de mutación de alta garantía

La propagación de cancelación de mutación es particularmente robusta: la cancelación se propaga hasta el límite de ejecución del proveedor, y la mutación no puede confirmarse después de que una comprobación de cancelación falle.

La seguridad del ciclo de vida del contexto de autorización PostgreSQL es a prueba de ciclos de vida:

• La identidad de actor/inquilino es inmutable

• Las versiones son estrictamente monotónicas

• Las identidades eliminadas retienen un tombstone de versión

• La configuración de contexto de autorización ausente falla cerrada

Los writes de ciclo de vida usan la misma frontera de serialización de bloqueo de fila que las lecturas de autorización de mutación.

Integridad criptográfica de la autorización

La evidencia de autorización PostgreSQL persistida está criptográficamente vinculada a su carga de seguridad canónica completa mediante una clave HMAC-SHA256 externa, respaldada por un ciclo de vida de clave externa autorizado con estados activo/solo-verificación/retirado, proveniencia de rotación monotónica, snapshots de anillo atómicos inmutables y comprobaciones de retirada seguras contra la evidencia persistida.

El sistema falla cerrado ante claves desconocidas, discrepancias de algoritmo, valores alterados de actor/inquilino/estado/versión/fingerprint y tombstones de ciclo de vida manipulados. La rotación de claves se soporta a través de un anillo de claves de verificación, manteniendo el material criptográfico fuera de la base de datos y de la identidad de caché.

Portones de verificación

El camino de verificación de Foundgine está diseñado en capas progresivas:

El flujo CI de release convierte las pruebas unitarias, integración PostgreSQL, penetración de autorización, adversariales y de rendimiento en prerrequisitos de publicación de paquetes.

Primeros Pasos y Estado Actual

Para los desarrolladores que quieren comenzar con Foundgine, el camino recomendado sigue una progresión práctica desde la iteración local hasta workloads SQL reales.

Punto de entrada recomendado

El proveedor InMemory (Foundgine.InMemory) es el punto de partida ideal para desarrollo y pruebas. Permite ejecutar el mismo modelo semántico sin base de datos, lo que acelera la iteración en las primeras fases sin sacrificar la fidelidad semántica. Una vez validado el modelo y la lógica de autorización, la transición al proveedor SQL (Foundgine.Sql con PostgreSQL) es directa, ya que ambos comparten el mismo plan semántico intermedio.

Documentación y recursos

El sitio publicado está disponible en Foundgine.io, construido desde docs-site/. La documentación incluye:

• Guía conceptual: "What is Foundgine?" y "AI agents and PostgreSQL"

• Referencia de arquitectura y rendimiento

• llms.txt / llms-full.md: índice de documentación legible por máquina para agentes IA y herramientas LLM

Este último recurso es particularmente valioso: permite que un agente IA se oriente automáticamente sobre las capacidades y el modelo de Foundgine, alineándose con la visión del proyecto.

Objetivo .NET y despliegues AOT

El objetivo es .NET 9.0, y el paquete Foundgine.Aot proporciona atributos de metadatos y soporte en runtime para despliegues orientados a Native AOT, una consideración relevante para entornos con restricciones de arranque o footprints reducidos.

Expectativas de madurez

La versión actual es 0.5.x y en el momento de escribir este artículo se registra como 0.5.2 en NuGet. La estabilidad de la API pública está en evolución y debe tratarse según la política de release y compatibilidad del proyecto. El CHANGELOG.md mantiene notas de ingeniería fechadas y detalladas para cada release — por ejemplo, la 0.5.0 se centró en limpieza de empaquetado y documentación, la 0.4.0 introdujo el plano de control de recuperación de autorización con quórum de testigos, y la 0.3.0 validó la arquitectura de ejecución semántica como superficie de release.

Estructura del repositorio

• src/Foundgine.MCP — adaptador MCP

• benchmarks/CoffeeBeanery.Performance/ — benchmark de consultas con runner y artefactos

• benchmarks/AgentEndToEnd/ — benchmark del camino de agente

• docs-site/ — fuente del sitio de documentación

FAQ