Foundgine.Sql 0.5.2

<picture> <source media="(prefers-color-scheme: dark)" srcset="docs-site/assets/logo/foundgine-logo-dark.png"> <img src="docs-site/assets/logo/foundgine-logo.png" alt="Foundgine" width="360"> </picture>

Foundgine.io

From intent to authorized execution.

Foundgine is a programmable semantic execution platform for .NET.

It creates a controlled boundary between application callers — including APIs, GraphQL, automation, and AI agents — and the data and operations they are allowed to execute.

Instead of allowing every caller to implement its own validation, authorization, query translation, and data-access logic, Foundgine turns structured intent into an authorized execution plan and executes that plan through a provider.

Caller
  │
  ▼
Intent
  │
  ▼
Semantic Model
  │
  ▼
Authorization
  │
  ▼
Execution Plan
  │
  ▼
Provider
  │
  ▼
Result

What is Foundgine?

Foundgine separates what a caller wants from how the application executes it.

A caller submits structured intent. Foundgine resolves that intent against an application-defined semantic model, validates the requested capabilities, applies authorization constraints, builds an execution plan, and sends the plan to a provider such as SQL or InMemory.

The result is a reusable execution boundary that can sit underneath multiple interfaces.

                 Intent Sources

     API       GraphQL       Automation       AI Agent
       \          |              |              /
        \         |              |             /
         └────────┴──────────────┴─────────────┘
                          │
                          ▼
                  ┌───────────────┐
                  │   Foundgine   │
                  │               │
                  │ Semantic      │
                  │ Authorization │
                  │ Planning      │
                  │ Execution     │
                  └───────┬───────┘
                          │
              ┌───────────┼───────────┐
              ▼           ▼           ▼
             SQL       InMemory     Providers

Why does Foundgine exist?

Modern applications increasingly have many callers:

• web and mobile applications
• APIs
• GraphQL clients
• internal services
• automation
• AI agents

Without a common execution boundary, each interface can grow its own authorization, validation, query translation, and data-access path.

Foundgine is designed to centralize the semantic execution model so that different callers can share the same application-defined capabilities and execution rules.

The key idea

Callers describe what they want. Foundgine determines what is allowed, how it should execute, and which provider performs it.

Security conformance

Foundgine treats security requirements as part of the semantic execution contract. Required security invariants are propagated into plans and checked against provider capabilities before execution. This prevents a provider from silently executing a capability whose security guarantees it cannot preserve.

The security progression currently includes security invariant registration, plan-level invariant proof, SQL provider conformance, high-assurance mutation conformance, and cross-provider conformance.

Foundgine and AI agents

AI agents make this boundary particularly important.

An AI model can decide what it wants to accomplish. It should not become the authority over which application data it is allowed to access, nor should it need direct database credentials.

Instead:

AI Agent
    │
    │ structured intent
    ▼
Foundgine
    ├── resolve
    ├── validate
    ├── authorize
    ├── plan
    └── execute
            │
            ▼
        PostgreSQL

This is deliberately different from:

AI → generate SQL → database

Foundgine is intended to keep the application in control of authorization and execution while allowing AI and other structured callers to use application capabilities.

Website

Foundgine.io

Capabilities

A 30-second example

A caller asks:

Find customers with accounts over $10,000.

The caller does not need to know the database schema or generate SQL.

Conceptually:

Request
  ↓
Customer
  └── Accounts
        └── Balance > 10,000
  ↓
Authorization
  ↓
Execution plan
  ↓
SQL provider
  ↓
Result

The important boundary is:

What the caller requested
          ≠
What the database can execute

Foundgine connects those two through an application-controlled semantic and planning layer.

Performance evidence

The 12 August 2026 CoffeeBeanery benchmark contains three successful runs over a deterministic PostgreSQL graph workload.

At concurrency 32:

That corresponds to approximately 20.0× the throughput of the baseline without the cache and 20.4× with the cache for this workload.

The benchmark also reports zero application errors, zero request timeouts, and zero cancelled requests across the three successful runs.

These results are workload-specific evidence, not a universal claim that Foundgine is faster than every EF Core or GraphQL workload.

See docs-site/performance/index.md for the full query benchmark methodology and caveats.

Agent benchmark

A separate suite measures the AI-agent path specifically: how an agent calling Foundgine through MCP compares to an agent calling a conventional EF Core path directly, across workload size and concurrency. It covers tool-call count, throughput, wall time, and estimated per-transaction token/context load.

See docs-site/agent-benchmark/index.html for the interactive workload/concurrency matrix and the per-run write-ups.

What Foundgine is not

Foundgine is not:

• an ORM replacement
• a database
• a GraphQL server
• an LLM
• an agent framework
• an identity provider

It is an execution layer that can sit underneath those kinds of systems.

Vision

Make application capabilities understandable and safely executable by machines.

The long-term vision is a stable semantic execution boundary between what a system asks for and what an application is willing to execute.

That boundary should work for traditional software and intelligent agents alike.

Documentation

• What is Foundgine?
• AI agents and PostgreSQL
• Architecture
• Performance
• llms.txt / llms-full.md — machine-readable documentation index for AI agents and LLM tooling

The published site (built from docs-site/) is available at https://cristianbarragan.github.io/Foundgine/.

Development

Repository development setup, tests, benchmarks, deployment templates, and contribution guidance should remain separate from the first-time user experience.

Source data for the published benchmarks lives under benchmarks/: the query benchmark in benchmarks/CoffeeBeanery.Performance/, and the agent-path benchmark in benchmarks/AgentEndToEnd/, each with the runner and raw per-run artifacts that the corresponding docs-site/ page is built from.

Security

Foundgine's authorization and execution boundaries are intended to reduce unsafe access paths, but application security remains a shared responsibility. Authentication, secret management, transport security, rate limiting, database permissions, and deployment security remain application and infrastructure responsibilities.

Status

Foundgine is actively evolving (current version: 0.5.0). Public API stability, provider coverage, AI-agent integrations, and production deployment patterns should be treated according to the project's current release and compatibility policy.

Detailed, dated engineering notes for each release are kept in CHANGELOG.md.

High-assurance mutation security details

Mutation cancellation is propagated to the provider execution boundary and cannot commit after a cancellation check fails.

Authorization context lifecycle security

The PostgreSQL high-assurance authorization context is now lifecycle-safe. Actor/tenant identity is immutable, versions are strictly monotonic, deleted identities retain a version tombstone, and missing configured authorization context fails closed. Lifecycle writes use the same row-lock serialization boundary as mutation authorization reads.

Authorization context cryptographic integrity

Persisted PostgreSQL authorization evidence is cryptographically bound to its complete canonical security payload with an externally held HMAC-SHA256 key, backed by an authorized external key lifecycle with active/verification-only/retired states, monotonic rotation provenance, atomic immutable ring snapshots, and safe retirement checks against persisted evidence. Unknown keys, algorithm mismatches, altered actor/tenant/state/version/fingerprint values, and tampered lifecycle tombstones fail closed. Key rotation is supported through a verification key ring while cryptographic material remains outside the database and cache identity.