Foundgine - Programmierbare semantische Ausführungsplattform für .NET

Was ist Foundgine

Moderne Anwendungen sind heute von einer Vielzahl unterschiedlicher Aufrufer umgeben: Web- und Mobile-Clients, REST-APIs, GraphQL-Consumer, interne Microservices, Automatisierungsskripte und zunehmend auch KI-Agenten. Jede dieser Schnittstellen tendiert dazu, eigene Autorisierungslogik, Validierungsregeln, Abfrageübersetzungen und Datenzugriffspfade zu implementieren. Das Ergebnis ist ein fragmentiertes Ausführungsmodell, in dem dieselbe Geschäftsfähigkeit an verschiedenen Stellen unterschiedlich interpretiert, autorisiert und ausgeführt wird.

Foundgine adressiert genau dieses Problem als eine programmierbare semantische Ausführungsplattform für .NET. Die Plattform schafft eine kontrollierte Grenze zwischen den Aufrufern einer Anwendung und den Daten und Operationen, die diese Aufrufer ausführen dürfen. Anstatt jedem Aufrufer zu erlauben, eigene Validierungs-, Autorisierungs-, Abfrageübersetzungs- und Datenzugriffslogik zu implementieren, übersetzt Foundgine strukturierte Absichten in einen autorisierten Ausführungsplan und führt diesen Plan über einen Provider aus.

Die Kernidee lässt sich prägnant formulieren:

Aufrufer beschreiben, was sie wollen. Foundgine bestimmt, was erlaubt ist, wie es ausgeführt wird und welcher Provider es ausführt.

Diese Trennung von Absicht und Ausführung wird durch eine klar definierte Pipeline realisiert:

Absicht → Semantisches Modell → Auflösung → Autorisierung → Plan → Umschreiben/Optimierung → Provider-Kompilierung → Ausführung → Ergebnis + Evidenz

Ebenso wichtig ist, was Foundgine bewusst nicht ist: keine ORM-Ablösung, keine Datenbank, kein GraphQL-Server, kein LLM, kein Agenten-Framework und kein Identitätsanbieter. Foundgine ist eine Ausführungsschicht, die unterhalb solcher Systeme angesiedelt werden kann. Die langfristige Vision ist eine stabile semantische Ausführungsgrenze zwischen dem, was ein System anfordert, und dem, was eine Anwendung bereit ist auszuführen – gleichermaßen anwendbar auf traditionelle Software und intelligente Agenten.

Kernarchitektur und technische Details

Die Architektur von Foundgine basiert auf einer konsequenten Trennung von Belangen, die jede Stufe der Ausführungskette isoliert und einzeln verantwortbar macht.

Semantisches Modell definiert die anwendungsbezogenen Fähigkeiten unabhängig von physischen Persistenzdetails. Absicht beschreibt, was der Aufrufer möchte, ohne es direkt an einen konkreten Provider zu binden. Die Autorisierung bestimmt, welche Teile der angefragten Operation erlaubt sind, und kann Prädikate oder Constraints zum Ausführungsplan beisteuern. Der Planer erzeugt eine provider-unabhängige Repräsentation der angefragten Operation. Umschreiben und Optimierung transformieren den Plan unter Wahrung von Semantik und Autorisierungsbeschränkungen. Der Provider schließlich kompiliert und führt den Plan gegen ein konkretes Backend aus.

Dieses Modell erlaubt ein Multi-Aufrufer-Ausführungsmodell, in dem REST/API, GraphQL, JSON, KI-Agenten und Automatisierung zu einer einheitlichen semantischen Absicht normalisiert werden, die den Foundgine-Planer speist:

REST/API · GraphQL · JSON · KI-Agent · Automatisierung
                │
                ▼
       Semantische Absicht
                │
                ▼
        Foundgine-Planer
                │
        ├── SQL
        ├── InMemory
        └── Zukünftige Provider

Warum der Zwischenplan die entscheidende architektonische Grenze ist: Der Plan trennt die semantische Absicht von der physischen Ausführung und gibt der Laufzeit einen Ort, um Autorisierungsbeschränkungen zu bewahren, Abhängigkeiten zu validieren, Operationen umzuschreiben, Kosten zu schätzen, über Provider-Fähigkeiten nachzudenken, die Ausführung zu optimieren und Ausführungsevidenz zu erzeugen. Genau dieser Mechanismus erlaubt es, dass mehrere Eingangsoberflächen und Provider sich dieselbe Ausführungssemantik teilen.

Ein zentrales Architekturprinzip ist die Unterscheidung zwischen semantischem Modell und Persistenzmodell. Ein Persistenzmodell beschreibt, wie Daten gespeichert werden; ein semantisches Modell beschreibt, was eine Anwendung bereit ist, aufzudecken und zu bearbeiten. Diese Modelle müssen nicht identisch sein – die semantische Oberfläche kann kleiner, sicherer und zielgerichteter sein als das physische Modell. Ein Persistenzmodell kann etwa interne Felder wie TenantId oder InternalRiskScore enthalten, die das anwendungsbezogene semantische Modell bewusst nicht exponiert.

Foundgine und KI-Agenten

KI-Agenten machen die Ausführungsgrenze besonders relevant. Ein KI-Modell kann entscheiden, was es erreichen möchte – aber es darf nicht zur Autorität darüber werden, auf welche Anwendungsdaten es zugreifen darf, und es sollte keine direkten Datenbank-Anmeldedaten benötigen.

Das naive Muster KI → SQL generieren → Datenbank stellt dem Agenten faktisch uneingeschränkte Autorität über die Datenbank bereit. Foundgine kontrastiert dieses Paradigma bewusst: Die Anwendung bleibt in der Kontrolle über Autorisierung und Ausführung, während KI und andere strukturierte Aufrufer die definierten Anwendungsfähigkeiten nutzen.

KI-Agent
    │
    │ strukturierte Absicht
    ▼
Foundgine
    ├── auflösen
    ├── validieren
    ├── autorisieren
    ├── planen
    └── ausführen
            │
            ▼
        PostgreSQL

Diese Architektur wird durch ein dediziertes Set KI-bezogener Pakete unterstützt. Foundgine.AI integriert KI-Tooling über Microsoft.Extensions.AI, während Foundgine.Agent.OpenAI eine OpenAI-Agenten-Integration bereitstellt. Der Foundgine.MCP-Adapter exponiert semantische Fähigkeiten und provider-neutrale Absichten über das MCP Streamable-HTTP-Transport an /mcp, wobei Discovery-Metadaten unter .well-known/mcp.json bereitgestellt werden.

Der Agenten-Benchmark misst einen Agenten, der Foundgine über MCP aufruft, gegen einen Agenten, der einen konventionellen EF-Core-Pfad direkt nutzt – über Workload-Größe und Nebenläufigkeit hinweg, mit Auswertung von Tool-Call-Anzahl, Durchsatz, Wandzeit und geschätzter Token-/Kontextlast pro Transaktion.

Die Supply-Chain-E2E-Geschichte macht diese Architektur konkret: Agent → MCP → Foundgine → PostgreSQL. Der Workload umfasst Kunden, Bestellungen, Bestellpositionen, Produkte, Lieferanten, Kategorien, Lager, Lagerorte, Sendungen und Carrier und mischt gültige, ungültige und nicht autorisierte Operationen über Kunden-, Kundenservice-, Lager-, Einkaufs- und Administrator-Identitäten. PlaceOrder fungiert dabei als High-Assurance-Vertikalscheibe: Autorisierung, Ownership, Validierung, serverseitige Preisberechnung, Lagerprüfung, atomare Mutation, Idempotenz-/Replay-Schutz und Ausführungsevidenz in einem Pfad.

Leistungsevidenz

Foundgines Abfrageleistungsvorteil wird durch den CoffeeBeanery-PostgreSQL-Graph-Benchmark belegt. Die deterministische PostgreSQL-Graph-Workload umfasst die Beziehungskette Customer → CustomerBankingRelationship → Contract → Transaction mit 1.000 Kunden, 4.000 Beziehungen, 12.000 Verträgen und 48.000 Transaktionen. Gemessen wurde bei Nebenläufigkeit 1, 8 und 32, mit 10-Sekunden-Messung pro Fall, 3-Sekunden-Aufwärmphase und 5-Sekunden-Request-Timeout.

Die Abfrageergebnisse bei Nebenläufigkeit 32 über drei unabhängige erfolgreiche Läufe:

Das entspricht ungefähr 20,0× dem Durchsatz der Baseline ohne Cache, 20,4× mit Cache sowie 16,7× niedrigerer p95-Latenz ohne Cache und 17,0× niedrigerer mit Cache. Der große Abfragevorteil ist demnach nicht vom Provider-Plan-Caching abhängig.

Die drei erfolgreichen Läufe meldeten 0 Anwendungsfehler, 0 Request-Timeouts und 0 abgebrochene Anfragen.

Der Umfang dieser Behauptung muss präzise verstanden werden: Es handelt sich um workload-spezifische Evidenz und nicht um eine universelle Aussage, dass Foundgine bei jedem EF-Core- oder GraphQL-Workload schneller ist. Die Ergebnisse hängen von Workload, Schema, Provider-Versionen, Host, Fixture und Implementierungsversionen ab. Die angemessene Behauptung lautet: Foundgine demonstriert starke Abfrageleistung für diesen beziehungsintensiven Graph-Workload, wobei Provider-Plan-Caching separat gemessen wurde. Mutationsleistung ist variabler und sollte nicht als primäre Leistungsbehauptung präsentiert werden.

Ökosystem, Pakete und Integrationen

Foundgine wird als koordiniertes Set von NuGet-Paketen verteilt statt als monolithische Bibliothek. Der aktuelle NuGet-Schnappschuss umfasst Version 0.5.2, Zielplattform .NET 9.0, mit 18 veröffentlichten Paketen und 7.801 Gesamt-Downloads über das Paket-Set.

Die Paketlandschaft bildet einen klaren Weg von Provider-unabhängigen Verträgen und Semantik über Planung und Ausführung bis zu SQL, KI, MCP, GraphQL, AOT und High-Assurance-Autorisierung. Hinzu kommen Foundgine.Agent.OpenAI, Foundgine.GraphQL.HotChocolate.Mutations, Foundgine.CoffeeBeanery.ProductComposite, Foundgine.Authorization sowie Foundgine.HighAssurance.Postgres. Die Download-Zahlen sind NuGet-gemeldete Paket-Downloads, keine eindeutigen Nutzer oder Installationen.

Die GraphQL-Integration erfolgt über den Hot-Chocolate-Adapter, der GraphQL-Selektionen in semantische Foundgine-Anfragen konvertiert – GraphQL dient als Schnittstelle, wird aber nicht zum Ausführungsmodell. Der MCP-Transport nutzt das Streamable-HTTP-Transport an /mcp mit Discovery-Metadaten in .well-known/mcp.json. Die veröffentlichte Dokumentation ist unter Foundgine.io verfügbar, ergänzt um maschinenlesbare Indizes in llms.txt und llms-full.md für KI-Agenten und LLM-Tooling.

Foundgine wurde außerdem von UnofficialOS, einem unabhängigen Community-Verzeichnis für KI-Agent- und MCP-Tooling, mit 90/100 im AST-Security-Audit bewertet – mit vollen Punktzahlen für Edge-Sandbox-Sicherheit, Open-Source-Lizenz-Compliance, Dokumentation & Quickstart-Qualität sowie Repository-Hygiene & Provenance. Die verbleibenden Punkte entfielen auf Ecosystem & MCP-Alignment, da MCP-Implementierungsevidenz in jenem Scan nicht erkannt wurde. Die Seite befindet sich derzeit in der Scan-Cooldown-Phase.

Sicherheitskonformität und High-Assurance-Mutationen

Foundgine behandelt Sicherheitsanforderungen als Teil des semantischen Ausführungsvertrags. Erforderliche Sicherheitsinvarianten werden in Pläne propagiert und vor der Ausführung gegen Provider-Fähigkeiten geprüft. Dies verhindert, dass ein Provider stillschweigend eine Fähigkeit ausführt, deren Sicherheitsgarantien er nicht bewahren kann.

Die aktuelle Sicherheitsprogression umfasst: Invariantenregistrierung (Registrierung von Sicherheitsinvarianten), Plan-Evidenz (Invariantenbefund auf Plan-Ebene), SQL-Provider-Konformität, High-Assurance-Mutationskonformität und Cross-Provider-Konformität. Die Autorisierungs- und Ausführungsgrenzen von Foundgine sollen unsichere Zugriffspfade reduzieren, aber Anwendungssicherheit bleibt eine geteilte Verantwortung: Authentifizierung, Geheimnisverwaltung, Transportsicherheit, Rate-Limiting, Datenbankberechtigungen und Bereitstellungssicherheit bleiben Anwendungs- und Infrastrukturverantwortung.

Mutationsabbruch wird bis zur Provider-Ausführungsgrenze propagiert: Eine Mutation kann nach fehlgeschlagener Abbruchprüfung nicht mehr committen. Der PostgreSQL-High-Assurance-Autorisierungskontext ist lebenszyklussicher: Akteur-/Tenant-Identität ist unveränderlich, Versionen sind streng monoton, gelöschte Identitäten behalten einen Versions-Tombstone, und fehlende konfigurierte Autorisierungskontexte schlagen fail closed. Lebenszyklus-Schreibvorgänge verwenden dieselbe Row-Lock-Serialisierungsgrenze wie Mutations-Autorisierungslesevorgänge.

Die kryptografische Integrität persistierter PostgreSQL-Autorisierungsevidenz ist an ihre vollständige kanonische Sicherheitslast gebunden – über einen extern gehaltenen HMAC-SHA256-Schlüssel mit autorisiertem externen Schlüssellebenszyklus: aktive/Nur-Verifizierung/ausgemusterte Zustände, monotone Rotations-Herkunft, atomare unveränderliche Ring-Snapshots und sichere Ruhestandsprüfungen gegen persistierte Evidenz. Unbekannte Schlüssel, Algorithmus-Mismatches, veränderte Akteur-/Tenant-/Zustands-/Versions-/Fingerprint-Werte und manipulierte Lebenszyklus-Tombstones schlagen fail closed. Schlüsselrotation wird über einen Verifikationsschlüsselring unterstützt, während kryptografisches Material außerhalb von Datenbank und Cache-Identität verbleibt.

Die Verifikationsgates bilden eine gestaffelte Absicherung: Unit-Tests verifizieren deterministisches semantisches, Planungs-, Autorisierungs- und Laufzeitverhalten; PostgreSQL-Integrationstests üben den realen Provider aus; Autorisierungs-Penetrationstests attackieren High-Assurance-Autorisierungspfade; adversariale semantische Input-Tests replizieren feindliches Modell-Input; Performance-Smoke führt reale Benchmarktrafik in Docker aus; die Supply-Chain-E2E übt den vollständigen agentenbezogenen Geschäftsworkflow. Der CI-Release-Workflow macht diese Gates zu Voraussetzungen für die Paketveröffentlichung.

Erste Schritte und aktueller Status

Für Entwickler, die Foundgine evaluieren möchten, bietet die veröffentlichte Dokumentation unter Foundgine.io den vollständigen Einstieg – mit dem Dokumentationsindex, Architekturdetails, Performance-Berichten und maschinenlesbaren Indizes. Die Core-Struktur des Repositories umfasst src/Foundgine.MCP, benchmarks/CoffeeBeanery.Performance/, benchmarks/AgentEndToEnd/ und docs-site/.

Der empfohlene Onboarding-Pfad beginnt mit dem InMemory-Provider (Foundgine.InMemory) für Entwicklung und Tests, bevor SQL-Workloads übernommen werden. Dies erlaubt schnelle lokale Iteration über dasselbe semantische Modell ohne Datenbank-Setup. Für Native-AOT-orientierte Bereitstellungen ist die Zielplattform .NET 9.0 mit Foundgine.Aot relevant, das Metadaten-Attribute und Laufzeitunterstützung für generierte Metadaten bereitstellt.

Die aktuelle Version befindet sich bei 0.5.x. Die öffentliche API-Stabilität und Provider-Abdeckung entwickeln sich gemäß der Release- und Kompatibilitätspolitik des Projekts weiter. Detaillierte, datierte Engineering-Notizen für jedes Release finden sich in CHANGELOG.md – etwa Version 0.4.0 mit dem Autorisierungs-Recovery-Control-Plane (Publikationsschlüssel-Lebenszyklus, Rotation und Ruhestand), Authority-Term-Zertifikaten mit verkettetem Verlaufs-Hash, Multi-Witness-Validierung und konservativer Projektions-Pruning-Regel.

Für agentenorientiertes Onboarding führt der maschinenlesbare Index llms.txt/llms-full.md KI-Agenten und LLM-Tooling gezielt durch die Dokumentation. Die vollständige Laufzeitkette – von Unit-Tests über PostgreSQL-Integration, Autorisierungs-Penetration, adversariale Input-Tests und Performance-Smoke bis zur Supply-Chain-E2E – ist als Verifikationspfad dokumentiert, der Foundgine als Ausführungssystem evaluierbar macht, nicht als einzelne Benchmark-Zahl.

FAQ