Current shipped release: 0.5.0. The repository has passed restore, build, and full automated tests for the current release. PostgreSQL E2E and benchmark workflows remain separate environment-dependent evidence.
This file concatenates all public Foundgine documentation pages for full-context ingestion by AI agents and LLMs. See llms.txt for a linked index of the same pages.
Foundgine is a semantic execution platform for .NET that turns structured intent into authorized execution plans.
Applications increasingly have multiple callers:
Each caller can otherwise grow its own rules for validation, authorization, query construction, and data access.
That makes the application harder to reason about and creates multiple execution paths.
Foundgine introduces a semantic boundary:
Caller
↓
Intent
↓
Semantic Model
↓
Authorization
↓
Execution Plan
↓
Provider
↓
Result
The caller expresses an operation. The application defines the semantic capabilities and authorization rules. Foundgine builds the execution plan and the provider performs it.
A persistence model describes how data is stored.
A semantic model describes what an application is willing to expose and operate on.
Those models do not have to be identical.
For example, a persistence model might contain:
Customer
├── Id
├── TenantId
├── Name
├── InternalRiskScore
└── Accounts
An application-facing semantic model might expose:
Customer
├── id
├── name
└── accounts
└── balance
The semantic surface can therefore be smaller, safer, and more purposeful than the physical model.
An AI agent is good at producing intent. It should not be trusted with unrestricted database authority.
A safer architecture is:
AI
↓
structured intent
↓
Foundgine
├── resolve
├── validate
├── authorize
├── plan
└── execute
↓
database
The application remains the authority over what the agent can do.
Foundgine’s public mental model can remain simple:
Model → Request → Authorize → Plan → Execute → Result
The deeper architecture adds metadata, expression trees, relationship traversal, rewriting, optimization, cost estimation, provider capabilities, and execution evidence.
Foundgine can sit underneath interfaces rather than replacing them:
REST/API ──────┐
GraphQL ───────┤
Automation ────┤
AI Agent ──────┤
▼
Foundgine
▼
SQL / InMemory / ...
This lets the interface and the execution model evolve independently.
The purpose of the Foundgine AI integration is not to make the model responsible for database access.
The intended boundary is:
AI Agent
↓
Tool / structured intent
↓
Foundgine
↓
Authorization + planning
↓
Provider
↓
PostgreSQL
Avoid:
LLM
↓
generated SQL
↓
database credentials
↓
PostgreSQL
The model should not be the authority over database schema access, tenant isolation, or application authorization.
LLM
│
│ "Find customers with balances over $10k"
▼
Agent tool
│
│ structured request
▼
Foundgine
├── semantic resolution
├── validation
├── authorization
├── relationship traversal
├── planning
└── provider execution
│
▼
PostgreSQL
The first E2E scenario should prove the complete chain:
Steps 3–7 above — structured intent, semantic resolution, authorization, planning, and provider execution — are the same core pipeline documented in the Architecture section; that pipeline is not specific to AI agents.
The semantic lifecycle itself is shipped and tested in 0.5.0. A general autonomous-agent runtime that owns model selection, orchestration, deployment infrastructure, and autonomous end-to-end behavior is not a current core guarantee.
The E2E suite should include at least:
Agent → customer.name
→ authorized
→ SQL
→ result
Agent → customer.internalRiskScore
→ denied
→ no database execution
Agent → another tenant's customer
→ authorization predicate prevents access
A malicious value in application data must not become an instruction that changes the agent’s authorization or Foundgine execution boundary.
Build the E2E in this order:
1. Agent process
2. Foundgine
3. PostgreSQL
4. Deterministic E2E
5. HTTP boundary
6. Docker
7. Kubernetes
8. Terraform
9. CI/CD
The local deterministic test should prove the architecture before infrastructure is introduced.
Intent
↓
Semantic Model
↓
Resolution
↓
Authorization
↓
Plan
↓
Rewrite / Optimize
↓
Provider Compilation
↓
Execution
↓
Result + Evidence
Defines the application-facing capabilities.
Describes what the caller wants without binding it directly to a physical provider.
Determines which parts of the requested operation are permitted and can contribute predicates or constraints to the execution plan.
Builds a provider-independent representation of the requested operation.
Transforms the plan while preserving semantics and authorization constraints.
Compiles and executes the plan against a concrete backend.
REST/API
GraphQL
JSON
AI Agent
Automation
│
▼
Semantic Intent
│
▼
Foundgine Planner
│
├── SQL
├── InMemory
└── Future providers
The goal is to avoid implementing separate execution semantics for every interface.
The plan is the architectural boundary between semantic intent and physical execution.
It gives the runtime a place to:
This is the core mechanism that allows multiple input surfaces and providers to share execution semantics.
Three independent successful runs were performed against a deterministic PostgreSQL graph workload.
Customer
→ CustomerBankingRelationship
→ Contract
→ Transaction
Fixture:
At concurrency 32:
| Implementation | Average RPS | Average p95 |
|---|---|---|
| Conventional graph/API path | 139.4 | 338.4 ms |
| Foundgine — no cache | 2,781.0 | 20.3 ms |
| Foundgine — provider-plan cache | 2,838.9 | 19.9 ms |
That is approximately:
The large query advantage is therefore not dependent on provider-plan caching.
The three successful runs reported:
Mutation performance is more variable.
The benchmark supports the conclusion that Foundgine can perform well at higher concurrency, but mutation performance should not currently be presented as the primary performance claim.
The strongest evidence is for:
read/query execution over a relationship-heavy PostgreSQL graph workload.
The results consistently show substantially higher query throughput and lower p95 latency in this controlled workload.
This is not a universal benchmark of every:
Results depend on the workload, schema, provider versions, host, fixture, and implementation versions.
The appropriate claim is:
Foundgine demonstrates a substantial performance advantage for this relationship-heavy graph query workload.