SovrGPT Dokumentation
GovBridge

Architektur & Datenfluss

So läuft ein Werkzeugaufruf von SovrGPT über GovBridge ins DMS und zurück zum KI-Modell: Bausteine, Datenfluss und jeder Schritt eines Aufrufs.

GovBridge besteht aus zwei getrennten Bausteinen, die sich die SovrGPT-Datenbank und einen Verschlüsselungsschlüssel teilen.

BausteinOrtAufgabe
ProvisionierungSovrGPT-Plattform (/admin/govbridge)Legt je Organisation Endpunkte an: erzeugt Slug und Bearer-Token, speichert Backend-URL und verschlüsselte Zugangsdaten.
Adapter-Dienstgovbridge.sovrgpt.com (Niederlande, europe-west4)Nimmt MCP-Aufrufe an, ordnet sie dem Mandanten zu, ruft das Backend live auf und übersetzt zwischen MCP und CMIS bzw. FIT-Connect Submission API v2.

Der Adapter kennt keine SovrGPT-Sitzungen, Benutzer oder Chatverläufe. Er sieht nur Slug, Token und den einzelnen Werkzeugaufruf mit seinen Argumenten.

Datenfluss auf einen Blick

┌─────────────┐  MCP (JSON-RPC)  ┌───────────────┐  CMIS (JSON/HTTP)  ┌─────────────┐
│ SovrGPT     │ ───────────────▶ │ GovBridge     │ ─────────────────▶ │ DMS         │
│ (Frankfurt) │ ◀─────────────── │ (Niederlande) │ ◀───────────────── │ (Ihr Haus)  │
└─────────────┘  Tool-Ergebnis   └───────────────┘  API-Antwort       └─────────────┘
     │  ▲
     │  │   ↓ Chat mit Werkzeugergebnis
     ▼  │   ↑ nächster Werkzeugaufruf oder Antwort
┌─────────────┐
│ KI-Modell   │
│ (laut Wahl) │
└─────────────┘

SovrGPT schickt den Werkzeugaufruf an den Adapter, der holt die Daten aus dem DMS, und SovrGPT gibt das Ergebnis an das im Chat gewählte KI-Modell weiter. Standort und Anbieter jeder Station: Sicherheit & Datenschutz. Bei FIT-Connect ist das Backend die Submission API der FITKO; die Nutzlast verlässt den Adapter Ende-zu-Ende-verschlüsselt (JWE).

Ein Werkzeugaufruf, Schritt für Schritt

  1. SovrGPT sendet POST https://govbridge.sovrgpt.com/<slug>/<protocol> mit Authorization: Bearer <bridge-token> und einem JSON-RPC-2.0-Body.
  2. Routing: genau zwei Pfadsegmente, nur POST; <protocol> muss in GOVBRIDGE_PROTOCOLS stehen (z. B. cmis, fit-connect).
  3. Mandant: Zwei-Faktor-Mandantenauflösung; Fehlschlag → generisches 401.
  4. Body-Limit: harte 1-MB-Grenze (Einzelaufruf oder Batch).
  5. Dispatch: initialize, tools/list, tools/call, ping; bei tools/call das Plugin zum Protokoll.
  6. Backend live aufrufen über fetch mit hartem Timeout. Das CMIS-Plugin liest oder legt Dokumente ab und wendet die Größen-Policy an; das FIT-Connect-Plugin verschlüsselt (JWE) und durchläuft announce → Anhänge → finalize.
  7. Antwort: Der Adapter protokolliert nur Metadaten und schickt die JSON-RPC-Response zurück (202 bei reinen Notifications).
  8. SovrGPT gibt das Ergebnis an das KI-Modell; es antwortet oder ruft das nächste Werkzeug auf.

Zustandslosigkeit

Jeder Request trägt seinen eigenen Mandantenkontext; Sitzungen je Verbindung gibt es nicht. Im Prozess-RAM liegen nur das OAuth-Token des Backends je Endpunkt (bis kurz vor Ablauf) und das CMIS-Repository-Service-Dokument (5 Minuten). Fachinhalte speichert der Adapter nie zwischen.

Auf dieser Seite

Datenfluss auf einen BlickEin Werkzeugaufruf, Schritt für SchrittZustandslosigkeit
Architektur & Datenfluss