TUEO Produkt-Whitepaper

1. Was ist TUEO

TUEO ist eine private AI-Kollaborationsplattform für Unternehmen — KI arbeitet als festangestellte Mitarbeiter der Organisation (mit Stelle, Verantwortlichkeiten, Entwicklungsverlauf, Verhaltensgrenzen und Langzeitgedächtnis) und betreibt das Geschäft gemeinsam mit Menschen in der Umgebung des Kunden.

Das ist kein Slogan, sondern ein bereits umgesetztes Produktsystem. TUEO besteht aus zehn Produkten und deckt alles ab, was KI braucht, um „in die Stammrolle aufgenommen zu werden”:

• Identität: KI-Mitarbeiter und menschliche Mitarbeiter teilen dieselbe Personalakte, dasselbe Login, dieselben Berechtigungen;
• Wissensgedächtnis: Das Wissen und das Gedächtnis der KI haben eine Basis, mit jeder Nutzung genauer, ordnet sich automatisch und wächst von selbst;
• Rechenleistung und Modelle: heterogene Rechenleistung einheitlich verwaltet, Modell-Serving mit Governance, ein geschlossener Steuerungskreislauf;
• Kollaboration: KI-Mitarbeiter treten wie Kollegen in Gruppenchats ein, bearbeiten Arbeitsaufträge, moderieren Routine-Meetings, speichern Organisationswissen;
• Orchestrierung: Fachleute orchestrieren mit Dialogen Prozesse zu KI-Anwendungen, die nach der Veröffentlichung von der Organisation aufgerufen werden;
• Fähigkeiten: Jeder Skill, den KI aufrufen kann, wird marktorientiert gemanagt — Beschaffung, Autorisierung, Messung, Zugangsdaten;
• Ausführung: Der Ort, an dem KI wirklich arbeitet, ist in eine isolierte Sandbox eingeschlossen, prüfbar und planbar;
• Codierung: KI-Entwicklungsteams ändern mit einer echten Coding-Engine Code, führen Tests aus und erstellen MRs;
• Lieferung: Das gesamte System wird in die eigenen Räume des Kunden installiert und unterstützt vollständigen Betrieb ohne Netzwerk.

Die Kernaussage von TUEO lautet: Die nächste Stufe von Enterprise-KI ist nicht der „intelligentere Chat”, sondern „Mitarbeiter, die in den Organisationsbetrieb eintreten können”. KI braucht Stellen, Grenzen, Wachstum und Prüfbarkeit — genau das, was eine Organisation auch bei einem echten neuen Kollegen tut. TUEO macht diese Mechanismen zu Ingenieurskunst und liefert sie privatisiert aus.

1.1 Positionierung zweiter Ebene: die intelligente Basis der Unternehmensdigitalisierung

„AI in die Stammrolle aufnehmen” ist die Positionierung erster Ebene und beschreibt, dass KI Ihr Geschäft betreibt. TUEO hat eine zweite Positionierungsebene, die die Basis der gesamten Unternehmensdigitalisierung beschreibt:

Im Zeitalter des KI-Programmierens fehlt der Unternehmensdigitalisierung nicht an weiteren Systemen, sondern an einer intelligenten Basis, die die „Definition, Produktion, den Betrieb, die Updates und die Koordination” der Systeme zu einem vollständigen Kreislauf verbindet. TUEO ist diese Basis — Systeme werden über Aufgaben definiert (statt entwickelt), vorhandene Unternehmensfähigkeiten werden wiederverwendet und KI-gestützt und laufen dauerhaft auf einer selbst betriebenen Grundlage.

Die narrative Reihenfolge nach außen lautet: zuerst klarmachen, „was für eine Basis es ist”, dann „wie AI-Mitarbeiter auf dieser Basis arbeiten”.

• Definitionsebene — Systeme über Aufgaben definieren: studio-Orchestrierung + cohort-Arbeitsauftrags-Pipeline + executor-Ausführung. Der Fachbereich beschreibt Aufgaben, KI analysiert, verteilt, entwickelt, testet, liefert;
• Koordinationsebene — Fähigkeiten KI-gestützt machen, Systeminseln managen: capabilities + skillplugins + identity. Die bereits vorhandenen Systeme OA / ERP / CRM / MES werden als Fähigkeiten registriert, autorisiert, Zugangsdaten verwahrt, sicher von KI aufrufbar — Ihre Systeme werden nicht ersetzt, sondern zum ersten Mal zu Fähigkeiten, die KI aufrufen, autorisieren, auditieren und messen kann;
• Betriebsebene — Ressourcenverwaltung, Anwendungsbereitstellung und -release, Betrieb: console + executor. Neue Systeme, alte Systeme, KI-Systeme — das gesamte System über einen Zugang betreiben.

Basis = ersetzt Ihre Systeme nicht, sondern lässt alle Ihre Systeme auf dieser Grundlage definieren, montieren, betreiben und KI-gestützt machen.

1.3 Kernphilosophie (fünf Grundsätze)

1.4 Drei Dinge, die wir nicht verkaufen

• Kein Chatbot — das ist die unterste Form eines KI-Mitarbeiters, kein Produkt;
• Kein Einzelwerkzeug für KI — keine „Noch-einmal-Schreibung” von Dify / Coze / n8n, wir verkaufen ein System, keine Komponenten;
• Kein „kann antworten” — wir verkaufen „kann antworten und laufen, managen und umsetzen”.

2. Zu lösende Probleme

2.0 Die Frage der Zeit: von der Dateninsel zur Systeminsel

KI-Programmierung hat zwei Seiten: Die gute Seite ist, dass die Kosten für die Erstellung von Systemen gegen null tendieren und „Entwicklung” keine knappe Ressource mehr ist; das neue Problem ist die Explosion der Systemzahl und das wilde Wachstum KI-generierter Systeme — niemand übernimmt den Betrieb, niemand die Updates, niemand verbindet sie mit den vorhandenen Systemen.

Dateninseln sind ein Problem des „Lesens” — Daten sind kopierbar, transportierbar, zentralisierbar; ETL / Data Warehouse / Data Platform haben zwanzig Jahre gekämpft und es im Wesentlichen gelöst. Aber Daten in einen See zu verschieben, bringt Systeme nicht zum Sprechen: KI braucht nicht nur das Lesen von Daten, sondern das Einloggen in Systeme, das Wissen um deren Fähigkeiten, sicheres Ausführen von Aktionen im System und ein Audit für jede Aktion — das ist ein Problem des „Handelns”, das Data-Governance nie gelöst hat.

Beide Enden sind Inseln: traditionelle Altsysteme sind noch nicht KI-gestützt (laufen im Rechenzentrum, niemand versteht sie, niemand wagt es anzufassen); neue KI-Systeme werden nicht gemanagt oder betrieben (man kann sie bauen, aber nicht pflegen). Systeminseln sind schwerer zu beheben als Dateninseln — Systeme sind lebendig und haben einen Explosionsradius; man kann eine ERP nicht in einen See verschieben, sondern nur am Leben erhalten und sicher aufrufbar machen.

Die Antwort von TUEO ist der vollständige Kreislauf der Softwareentwicklung: Fachbereich stellt Anforderungen → KI analysiert zu Aufgaben → KI-Team entwickelt → Tests → UAT → Produktionseinsatz → kontinuierliche Überwachung und Betrieb → zunächst vorhandene Fähigkeiten erfassen, wiederverwenden statt neu entwickeln → Fähigkeitskoordination → zurück zur Anforderung. Kernidee: Systeme über Aufgaben definieren, nicht entwickeln.

Darauf aufbauend treffen Unternehmen beim Einsatz von KI im realen Geschäft auf vier weitere Brüche:

2.1 Kann antworten, nicht handeln

Generische LLM-Anwendungen können nur „antworten”, aber im realen Umfeld eines Unternehmens nicht arbeiten: Daten im System ändern, bestehende Systeme anbinden, Code ausführen, echte Dateien produzieren. Unternehmen brauchen keinen schlaueren Assistenten, sondern ein Paar Hände, das wirklich etwas umsetzt.

2.2 KI ist Werkzeug, kein Mitarbeiter

Die meisten Unternehmen binden KI als Werkzeug in ein System ein: einen Kundenservice-Bot, einen Schreibassistenten. Ohne Stelle, ohne Verantwortungsgrenzen, ohne Entwicklungsverlauf, ohne Langzeitgedächtnis, ohne Verhaltensaudit. Eine „identitätslose” KI kann von der Organisation nicht gemanagt werden und keine kontinuierliche Geschäftsverantwortung tragen.

2.3 Mit Entscheidung, ohne Ausführungsebene

Selbst wenn KI die richtige Entscheidung trifft, wer führt sie aus? Die direkte Ausführung von KI-Code im Geschäftssystem ist gefährlich — es braucht eine isolierte, kontrollierte, prüfbare Ausführungsebene, die „Benutzercode ist nicht vertrauenswürdig” als Standardannahme behandelt.

2.4 Mit KI, ohne Governance und Audit

In stark compliance-regulierten Branchen wie Finanzen, öffentlicher Verwaltung und Gesundheitswesen muss jede KI-Entscheidung nachvollziehbar, abspielbar und prüfbar sein. Die meisten KI-Plattformen behandeln Audits als nachträglichen Patch, verteilen Berechtigungen über verschiedene Produkte und vergraben Modellschlüssel in Clients — das hält keiner Compliance-Prüfung stand und lässt sich nicht privatisiert ausliefern.

TUEO löst mit einem System aus zehn Produkten diese vier Brüche in einem Durchgang.

3. Überblick über das Produktsystem

3.1 Zehn Produkte, ein System

3.2 Schichtenstruktur

Konsumenten   cohort-desktop (Electron-Desktop-Client) · cohort-server-Verwaltungsbackend
───────────────────────────────────────────────────────────
Erlebensebene     cohort (Kollaborationskern) · studio (Anwendungs-Orchestrierung)  ← wo Mensch und KI zusammenarbeiten
Fähigkeitsebene   capabilities (Kompetenzmarktplatz · Aufruf-Gateway)               ← ein Fähigkeitsvertrag, zwei Konsumenten
Ausführungsebene  executor (Sandbox-Ausführung) · codex-build (Coding-Engine)      ← wo KI wirklich arbeitet
───────────────────────────────────────────────────────────
Grundfundament    identity (Identitäts-SSOT) · engram (Wissensgedächtnis-Basis) · inference (Rechenleistung und Modell-Serving) ← Querschnittsunterstützung für alles oben Genannte
Betriebsbasis     console (Betriebsebene der intelligenten Basis · Bereitstellung / Middleware / privater IDP)
Ökosystem         skillplugins (Plugin-Quellcode + @tueo/plugin-sdk)

3.3 Datenfluss und Verantwortungsgrenzen (wer ist die Wahrheit)

3.4 Integrationsmatrix (Zeile ruft Spalte auf)

4. identity — das Identitätsfundament

Auf einen Satz: das einheitliche Identitätsfundament der gesamten Plattform — ein Konto für alle Produkte, ein Token schreibt fest, in welchem Mandanten Sie sind, ein Verzeichnis verwaltet menschliche Mitarbeiter und KI-Mitarbeiter.

4.1 Positionierung

identity ist die Single Source of Truth (SSOT) der Identität im TUEO-System und trägt drei Arten plattformweiter Fähigkeiten:

1. OIDC-IdP: standardmäßige OpenID-Connect- / OAuth-2.0-Autorisierung, Tokens, Sitzungen, Föderation, Multi-Mandanten;
2. Organisationsverzeichnis als einzige Wahrheit: Organisationsstruktur + Personen + Dienstverhältnisse, SSOT des plattformweiten Adressbuchs;
3. Autorisierungsentscheidungszentrum: RBAC-Rollen auf drei Stufen konvergiert, Entscheidungslogik in identity zentralisiert; nachgelagerte Produkte dürfen keine Rolleninformationen halten.

Das Entwurfskriterium von identity lautet: „Gilt es noch, wenn man das Produkt wechselt?” Es übernimmt nur plattformweite Identitätsfähigkeiten und keine einzelne produktbezogene Geschäftslogik.

4.2 Kernfähigkeiten

4.2.1 OIDC-IdP (ES256 + PKCE + Token-Rotation)

Basierend auf einem standardmäßigen OIDC-Autorisierungsserver: authorization code + PKCE-Login, mit ES256 signierte JWT-Access-Tokens, Refresh-Token-Rotation (RFC 9700), RFC 8628 Device Flow, RFC 7662 Introspection, JWKS-Rotation. Signaturschlüssel werden verschlüsselt gespeichert, Hot-Reload über mehrere Replikate. Access-Tokens verwenden strikt minimale Claims — profile wird grundsätzlich über /userinfo als Autorität abgefragt, um Token-Aufblähung und Berechtigungsdrift zu vermeiden.

4.2.2 Suite-weites SSO (RFC 8693 Token Exchange)

Der Klebstoff für ein Login in sechs Produkten: mit dem identity-Root-Token wird ein Benutzertoken mit aud=<Produkt> eingetauscht; studio / executor / capabilities steigen direkt ein, kein zweites Login. Zwei Sicherheitsgates: das Subject-Token muss ein aktives Root-Token sein; die Audience muss in der Whitelist der First-Party-Produkte stehen — der Austausch erfolgt nur als horizontale oder abgesenkte Berechtigung für denselben Benutzer + First-Party-Produkte, nie als Erhöhung.

4.2.3 Abgesenkte Minimal-Privileg-Tokens

Für halb vertrauenswürdige Ausführungsträger (KI-Engine-Subprozesse, lokale Coding-Engines) werden Tokens mit minimalen Rechten ausgestellt: eigene Audience + einzelner funktionaler Scope + kurze TTL. Die schlechteste Berechtigung, die eine Engine hält, sinkt von „Modellanbieterschlüssel / Benutzer-Token mit allen Rechten” auf „ein Ticket, das nur das Kontingent des eigenen Mandanten verbrennt, nach 15 Minuten abläuft und per Audience an einen festen Pfad gebunden ist” — für jeden Explosionsradius ein eigenes Ticket.

4.2.4 Organisationsverzeichnis als einzige Wahrheit

Organisationsstrukturbaum + Mitgliedsdienstverhältnisse + Personensuche werden vollständig von identity bereitgestellt. Der Baum wird mit ltree gespeichert, Dienstverhältnisse setzen sich aus user_org_memberships JOIN users JOIN org_nodes zusammen, position_title gehört zur Dienstverhältnis-Entität. Das plattformweite Adressbuch wird zu 100 % daraus aufgebaut; Personen werden nur an einer Stelle in identity geändert, und Desktop / Server / Matrix-localpart folgen auf der gesamten Plattform.

4.2.5 RBAC-Rollen-Konvergenz + Scope-Universum

Die gesamte Plattform kennt nur die drei Rollennamen platform_admin / tenant_admin / member; 11 historische Altnamen werden über eine Alias-Tabelle normalisiert. Scopes werden programmatisch aus dem Rollenverzeichnis abgeleitet und einheitlich konsumiert (die Falle eines früheren stillen Wegfalls wegen fünf manuell gepflegter Scopes wurde beseitigt). Neues Produkt = eine Zeile im Katalog + Scope anhängen, null nachgelagerte Änderungen.

4.2.6 Mandantenwechsel = Token-Neuausstellung

„In welchem Mandanten bin ich” hat nur eine Wahrheit — das Token selbst. Wechseln = mit Mandanten-Hint die Autorisierung erneut durchlaufen, identity prüft und stellt das Token neu aus; bei jeder Ausstellung wird die Autorisierung erneut geprüft, bei Entzug einer Rolle / Löschung eines Mandanten sofortige Rückkehr zu home. Konsumstellen, die nur das Token prüfen (z. B. WebSocket-Gateway), sind automatisch korrekt und driften nicht zu Berechtigungsüberschreitungen.

4.2.7 SCIM-Inbound-Provisioning

Die Standard-SCIM-Implementierung (RFC 7643/7644) liegt unter /scim/v2/*; externe IdPs (Okta / Azure AD) schließen standardkonform an. Jeder Mandant fixiert mit einem statischen bearer token die tenantId — mandantenübergreifend unmöglich. Benutzer / Gruppen CRUD, Filteroperatoren, externalId-Abgleich, Synchronisationsprotokolle und Fehleraudits.

4.2.8 Nachvollziehbares Audit (kryptografische Hashkette)

Jede Änderung von Identität / Autorisierung / Verzeichnis geht ins Audit, und die Zeilen sind über eine SHA-256-contentHash- + prev_hash-Hashkette verknüpft — Einfügen, Löschen, Umordnen, Ändern von Zeilen wird von verifyChainIntegrity erkannt. Die Aufbewahrungsrichtlinie des Audits ist pro Mandant konfigurierbar (Standard 90 Tage), Export mit Hash-Prüfung.

4.2.9 Governance benutzerdefinierter Felder + Verschlüsselung sensibler Informationen

Mandantenadministratoren deklarieren ein Feldschema (Typ / Pflicht / Validierung / sensitiv / durchsuchbar). Sensible Felder (z. B. Personalausweisnummern) sind von normalen Feldern physisch getrennt: Nicht-Sensitives geht in metadata, Sensitives in eine eigene Tabelle, AES-256-GCM-verschlüsselt, desensibilisiert zurückgegeben, Klartextlesen hinterlässt ein Audit — erfüllt die harte PIPL-Anforderung, dass sensible persönliche Informationen nachvollziehbar sein müssen.

4.2.10 Verwaltungskonsole

Deckt Organisation / Benutzer / Rollen / Audit / Mandanten / SSO / SCIM / benutzerdefinierte Felder / Sitzungen / Webhooks / API-Keys / Branding ab, umgesetzt nach dem TUEO-Plattform-Designsystem (Papier / Tinte / Jadestein / Zinnober), mit Mehrsprachigkeit und White-Label.

4.3 Differenzierung

• KI-Mitarbeiter und menschliche Mitarbeiter teilen dieselbe Identität: users.type='ai_staff' als erstklassiger Benutzertyp, gleiche Personalakte, gleiches Verzeichnis, gleiche Adressierbarkeit;
• Autorisierungsentscheidung in identity zentralisiert: Wettbewerber verstreuen „wer gilt als Administrator” über die Produkte, identity hält es an einer Stelle;
• Beweisbares Audit: die Hashkette macht „wer hat was getan” verifizierbar und fälschungssicher;
• Privat lieferbar: Single-Domain-Appliance + Setup-Assistent + Schlüssel über die Betriebs-Konfigurationszentrale verwaltet, vollständig offline bereitstellbar.

5. cohort — der Kollaborationskern (Flaggschiff)

Auf einen Satz: KI zum festangestellten Mitarbeiter Ihrer Organisation machen — Menschen und KI-Kollegen arbeiten im selben Arbeitsbereich zusammen, wachsen und liefern gemeinsam.

5.1 Positionierung

cohort ist das Flaggschiffprodukt von TUEO und besteht aus dem Serverteil (cohort-server, NestJS 11 + Fastify + PostgreSQL) und dem Desktop-Teil (cohort-desktop, Electron mit drei Prozessen). Es trägt die gesamte Geschäftslogik des „Arbeitsbereichs der KI-Mitarbeiter”: Entitätsregistrierung der KI-Mitarbeiter, Multi-KI-Kollaboration im Gruppenchat, kognitiver Zyklus, Arbeitsauftrags-Pipeline, Organisations-Wissensgraph, Gesprächsgedächtnis, Wochenmeeting-Orchestrierung, Audit-Protokollierung und Multi-Mandanten-Isolation.

Der Server ist die Daten-SSOT, der Desktop ein schlanker Client — Unternehmensdaten liegen nicht auf den Clients.

5.2 Kernfähigkeiten

5.2.1 KI-Mitarbeiter als Entität (AiStaffRegistry)

KI-Mitarbeiter sind Entitäten erster Klasse mit „Stammrollen-Identität und Berufsprofil”, die beide SSOT-Ebenen JOINen:

• identity-Personalakte: Stammrollen-Identität / richtiger Name / Abteilung / Position, gleiche Quelle wie das Adressbuch;
• cohort-ai_staff_profiles-Berufsprofil: roleLabel / workMethod / toolPolicy.allow / leadKinds / ownedCapabilities / responsibilities / Persona-Karte.

Die gesamte Pipeline liest nur diese eine Registry. Das Hinzufügen / Löschen / Ändern eines KI-Mitarbeiters ändert nur identity (+ Berufsprofil) an einer Stelle, und Adressbuch, Arbeitsauftrags-Triage, Fähigkeits-Routing und Ansage-Signierung folgen überall, null Codeänderung, null Namensliterale. identity löscht → überall verschwunden.

5.2.2 Multi-KI-Kollaboration im Gruppenchat (coordinator)

Welcher KI-Mitarbeiter eine menschliche Nachricht im Gruppenchat übernimmt, entscheidet der Server (coordinatorJudge = SSOT):

• Schneller Pfad: keine KI → nicht übernehmen; @-Erwähnung → antworten; DM an Menschen → automatische Antwort; KI-Beitrag → Selbstantwort-Schleife verhindern; Rauschen / reine Emojis → nicht übernehmen;
• Langsamer Pfad: Gruppenchat + Mensch + erwartete Antwort → deterministische Verantwortlichkeitsbewertung anhand des realen Berufsprofils des KI-Mitarbeiters (null LLM-Kosten), bei nahe beieinanderliegenden Kandidaten LLM-Schiedsrichter, sonst Rückfall auf die Sekretärin.

Jede Entscheidung geht ins Audit (coordinator.dispatch_judged). Im Gruppenchat „übernimmt immer genau ein Verantwortlicher”, ohne Spam; die Routing-Basis ist das reale Berufsprofil, nicht fest verdrahtete Namen.

5.2.3 Kognitiver Zyklus der KI-Mitarbeiter (Perceive → Think → Act → Reflect → Wait)

Jede Entscheidung jedes KI-Mitarbeiters durchläuft den kognitiven Fünf-Phasen-Zyklus:

1. Perceive (Wahrnehmen): Gespräch, Signale und Organisationskontext lesen, zuerst durch das Prinzipien-Gate (principleEnforcer.check('perceive')), deny schreibt direkt ein Ablehnungsartefakt;
2. Think (Denken): Fusion von Langzeitgedächtnis-Retrieval + Erfahrungsregeln + Projektkontext, LLM liefert strukturierte Intention; bei nicht verfügbarer LLM regelbasierter Rückfall;
3. Act (Handeln): Hochrisiko-Aktionen erfordern menschliche Bestätigung;
4. Reflect (Reflektieren): LLM-Reflexion wird ins Gedächtnis zurückgeschrieben und treibt die Selbstevolution;
5. Wait (Warten): Übergang zur nächsten Signalüberwachung.

Der gesamte Ablauf wird mit phaseTimings gemessen, beobachtbar und nachvollziehbar.

5.2.4 Arbeitsauftragssystem (Absicht → DoR → Triage → Agent-Ausführung)

Die vollständige Pipeline von einer Chat-Nachricht bis zur echten Arbeit des KI-Entwicklungsteams:

1. Absichtserkennung: LLM-jsonMode + Validierung, erkennt bug / feature / incident;
2. DoR-Annahme: Annahme nach Severity-Stufen, KI kann ergänzen — chinesische Arbeitsaufträge per LLM in Code-Suchbegriffe übersetzen, mit lokalem ripgrep echte Dateien zur Reproduktionsschritt-Lokalisierung finden, niemals erfinden;
3. Triage: Passport-Gate → LLM leitet assigned_role / priority / AC ab → Zuweisung an dev_team_room; zuweisbare Rollen werden dynamisch aus der Registry injiziert;
4. Zustandsautomat: 14 Zustände + Übergangsmatrix, O(1)-Validierung;
5. Agent-Ausführung: 5 Phasen pro run-role, validateToolList prüft nicht autorisierte Werkzeuge serverseitig hart anhand toolPolicy.allow.

Der Desktop visualisiert mit TriageCard / BuildProgressCard; KI ändert echte Dateien, führt echte Tests aus und committed echt auf dem lokal ausgecheckten Repo, mit Rückmeldung in den Arbeitsauftrag. Menschliche Nachrichten können automatisch klassifiziert und als Aufträge angelegt werden.

5.2.5 Organisations-Wissensgraph („Organisationsluft”)

Organisationsgespräche werden zu einem Wissensgraph verdichtet: LLM extrahiert aus Nachrichten Entitäten + typisierte Beziehungen in kg_entities / kg_edges (pgvector + Beziehungstabellen + Herkunftsverfolgung); bei der Suche pgvector-Cosinus-Top-K (Mandanten-Isolation) → Graph-Mehrsprung-Nachbarn (Zusagen / Abhängigkeiten / Konflikte) → sensitivity-Gate (Standard strengstens, sensible Informationen lecken nicht).

Die Wissensspeicherung nutzt ein Schema, drei Zwecke in einer Datenbank (Postgres + pgvector + Beziehungstabellen), null Doppelschreiben, null Drift; die Air-Gap-Installation hängt nur von Postgres + identity ab.

5.2.6 Gesprächsgedächtnis (individuelles Langzeitgedächtnis + geteiltes Substrate)

Jede KI hat ein raumübergreifendes Langzeitgedächtnis (7-Tage-Halbwertszeit-Dämpfung, Obergrenze 200 Einträge), mit der serverseitigen /cognitive-loop/memory als autoritativer Kopie. Alle KI-Entscheidungen teilen denselben „Raumzustands”-Substrate: Hauptthema / entschiedene Fakten / Offenes / nicht eingelöste Zusagen. Raumwechsel und Multi-KI-Kollaboration starten nicht jeweils auf Null — die Organisation wird mit jeder Nutzung klüger.

5.2.7 Schatten-KI-Zwilling

Hinter jedem echten Menschen steckt ein unsichtbarer Zwilling: Er lernt die eigenen Nachrichten des Menschen (Stil / Tonfall / Länge) und entwirft, wenn eine vom Gegenüber erwartete Nachricht 30 Sekunden unbeantwortet bleibt, im Hintergrund im Tonfall des Menschen einen Entwurf. Die Sendeschalter-Sperre ist standardmäßig aus, es wird nur erzeugt und auditiert, nie automatisch gesendet. Das Sendegate = Hauptschalter ∧ nicht eingefroren ∧ nicht Schutzbereich ∧ Konfidenz ≥ Vertrauensschwelle ∧ Risiko ≤ L2, mit unabhängigen Schwellen in den vier Eimern Finanzen / Kunde / Technik / intern.

5.2.8 Serverseitige Wochenmeeting-Orchestrierung

8 KI-Mitarbeiter durchlaufen wöchentlich den geschlossenen Kreislauf strukturierter Bericht → Diskussion → Hilferuf → Beschluss, vollständig serverseitig: pro KI-Teilnehmer Belege holen (die letzten 50 Raumnachrichten) → Schlussfolgerung → unter der echten AI-uuid sprechen. Gesamter Fehlschlag = ehrlicher Fehlschlag ohne Phasenfortschritt mit einer Systemnachricht, die den realen Grund nennt (behebt die Produktionspanne, in der „LLM-Gateway-Quota-403” stillschweigend zu einem leeren Meeting geschluckt wurde). Startet automatisch freitags.

5.2.9 Nachrichten-Engine + Echtzeitkanal

Chat-Nachrichten-CRUD, Zustellung / gelesen, gestreamte KI-Antworten und Übersetzung sind vollständig serverseitig SSOT und werden per WS ausgestrahlt. Parallelität / Races / mandantenübergreifende Zugriffe werden serverseitig abgefangen; die Übersetzung ist begrenzt (Kontext-Hash-Deduplizierung + maskieren/wiederherstellen technischer Literale + Slot-Queue). Das WS-Gateway ist dreiachsig gehärtet (strenge tenant-claim-Prüfung, jti-Revocation, mandantenweites Sliding-Window-Rate-Limiting).

5.2.10 Engine-Modell-Gateway (Zugangsdaten bleiben auf dem Server)

Die KI-Coding-Engine hält keine Modellanbieterschlüssel: base_url der Engine zeigt auf den OpenAI-kompatiblen serverseitigen Endpunkt, die Engine hält einen serverseitig ausgestellten abgesenkten Kurz-Ticket (15 Minuten, audience-gebundener Pfad), der echte Schlüssel wird serverseitig pro Mandant aufgelöst und injiziert. Drei harte Eigenschaften: das Modell bestimmt der Server, Client-Angaben werden ignoriert; Client-Zugangsdatenfelder werden stets verworfen; Upstream-Antworten werden vor der Rückgabe desensibilisiert.

5.2.11 MCP-Tueo-Server (einheitlicher Ausgang für Geschäftsfähigkeiten in die Engine)

Setzt die Geschäftsfähigkeiten von cohort (Arbeitsaufträge / Wissen / Anhänge / Zusagen / Beiträge) als Standard-MCP-Werkzeuge für die Ausführungs-Engine frei und schließt damit den Kreislauf „KI arbeitet → Ergebnisse fließen ins Kollaborationssystem zurück”.

5.2.12 Desktop-Client (cohort-desktop)

• Drei-Prozess-Electron: Hauptprozess (OS-Integration / OIDC / IPC / Crash-Self-Healing) + Preload (contextBridge-Whitelist + kategorieweises Token-Bucket-Rate-Limiting, eigene kleine Buckets für destruktive Kanäle) + Renderer (React 19 + Zustand);
• Vier-Spalten-Arbeitsbereich: Gesprächsliste / Nachrichtenbereich / Details / WorkspacePanel (Dokumente Markdown/HTML gegenseitig konvertieren → PDF/PPTX-Export + IDE-Arbeitsbank);
• Sicherheitstiefe: OIDC PKCE + ES256, drei abgesenkte Tokens, CSP-Enforcement, Audit über einen einzelnen Trichter an die Server-Konsole, IPC-Rate-Limiting;
• Lokales Pairing: der Hauptprozess startet die Coding-Engine direkt (ACP-Protokoll), Dateizugriffe innerhalb der Arbeitsverzeichnis-Grenzen, Berechtigungsanfragen standardmäßig abgelehnt — „der Mensch kontrolliert an den kritischen Stellen” ist kein Slogan.

5.3 Stelle und Berechtigungsgrenzen der KI-Mitarbeiter (auch KI-Mitarbeiter sind gesteuert)

Die Fähigkeitsgrenzen eines KI-Mitarbeiters werden durch Stelle, Verantwortlichkeiten und gewährte Werkzeug-Berechtigungen bestimmt, nicht durch das, was er kann — das ist einer der grundlegendsten Unterschiede zwischen TUEO und „generischen KI-Assistenten”.

• Wie Grenzen festgelegt werden: jeder KI-Mitarbeiter deklariert im Berufsprofil seinen Verantwortungsbereich und eine Werkzeug-Whitelist (toolPolicy.allow). identity regelt „wer es ist” (Stammrollen-Identität), die Registry regelt „wie es arbeitet” (Stelle / Verantwortlichkeiten / Berechtigungen), beide Linien bestimmen gemeinsam, was er tun darf. Eine Sekretärin ist eine Sekretärin — Su Wan ist Sekretärin, sie kann nicht auf Betriebsservern arbeiten;
• Wie Grenzen bewacht werden: nicht autorisierte Werkzeuge werden bei der serverseitigen harten Prüfung (validateToolList anhand toolPolicy.allow) stets abgelehnt; die Wahrnehmungsphase durchläuft zuerst das Prinzipien-Gate (PrincipleEnforcer, entscheidet bei Pattern-Treffer); Hochrisiko-Aktionen erfordern menschliche Genehmigung; jede Entscheidung und Ablehnung geht ins Audit — vier Verhaltensverteidigungslinien fangen alles ab;
• Warum Grenzen hart sind: Menschen wechseln die Stelle, KI wechselt die Stelle — gleich: eine Konfigurationsänderung der Stelle, der Fähigkeitsumfang folgt überall. KI-Mitarbeiter und menschliche Mitarbeiter unterliegen derselben Steuerungslogik: Sie sind stark, aber nur innerhalb der Grenzen stark, die die Organisation ihnen gibt.

Dieser Mechanismus macht „je stärker die KI, desto klarer die Grenzen” zu einer Engineering-Tatsache: Eine KI, die Code schreiben kann, bekommt ohne gewährte Betriebsberechtigung jede Anfrage an Betriebsserver vom System hart abgelehnt und protokolliert — die Organisation kann KI-Vertrauen stufenweise erhöhen, statt auf einen Schlag alles zu riskieren.

5.4 Differenzierung

• KI ist „Mitarbeiter in der Stammrolle der Organisation” statt Werkzeug, null Namensliterale, Namens-Single-Source in identity;
• Der Gruppenchat-Verantwortliche ist ein serverseitiger Vertrag statt Client-Heuristik, verhindert Selbstantwort-Schleifen, jede Entscheidung protokolliert;
• Arbeitsaufträge sind kein Fragebogen: DoR-stufige Annahme + KI-Selbstergänzung, Rigorosität statt Bürokratie;
• Zugangsdaten bleiben auf dem Server, Audit über einen einzelnen Trichter, Unternehmensdaten liegen nicht auf den Clients;
• Stellen bestimmen die Grenzen: KI-Mitarbeiter und menschliche Mitarbeiter unterliegen derselben Steuerungslogik, nicht autorisierte Werkzeuge werden serverseitig hart abgelehnt und protokolliert.

6. studio — die Anwendungs-Orchestrierungsplattform

Auf einen Satz: Fachleute orchestrieren mit Dialogen Prozesse zu Anwendungen, in denen KI auf Geschäftsobjekten wahrnimmt, entscheidet und handelt — der KI-native Nachfolger von BPM, kein weiteres Workflow-Canvas.

6.1 Positionierung

studio ist die „Orchestrierungs-Engine-Schicht / Schicht der intelligenten Arbeitsgesetzgebung” von TUEO: die intelligente Arbeit der Organisation (KI-Mitarbeiter + Konnektoren + menschliche Prüfung) wird zu veröffentlichbaren, prüfbaren, weiterentwickelbaren Anwendungen orchestriert, die von Menschen / KI-Mitarbeitern / externen Agenten vertrauensvoll aufgerufen werden können. Kombiniert mit cohort: cohort liefert die KI-Mitarbeiter-Laufzeit, menschliche Prüfkarten und Ergebnisrückmeldung; studio liefert strukturierte Orchestrierung, Abnahme-Release-Gate und Governance-Schranken.

6.2 Kernfähigkeiten

6.2.1 Event-Sourcing-Orchestrierungs-Engine

11 Knotentypen (Start / Ende / Verzweigung / KI-Kognition / KI-Mitarbeiter / Mensch / Fähigkeit / Unterprozess / Schleife / Warten / Parallel), jeder Zustandsübergang hängt ein append-only-run-trace-Ereignis an. Zustand wird aus Ereignissen abgeleitet: Mensch / Unterprozess / Schleife / Timer / Parallel / KI-Mitarbeiter laufen alle über persistente Pausen (Prozessneustart setzt fort, null Thread-Holding). Unterstützt Breakpoint-Single-Step / Fortsetzen, Neustart ab fehlgeschlagenem Schritt, Rekursionsschutz.

6.2.2 Dialog-Co-Pilot (Orchestrierung mit natürlicher Sprache)

Der Fachbereich sagt die Absicht (z. B. „Erstattungen über 3000 gehen durch die Genehmigung des Finanzdirektors”), der Co-Pilot erzeugt eine High-Level-Genehmigungsspezifikation und kompiliert sie deterministisch zu einem gültigen FlowDef — die LLM liefert nur einfaches JSON zu „was zu prüfen ist / wie zu routen ist / wie viele Genehmigungsstufen”, die Struktur garantiert der Compiler, maximal 3 Selbstkorrekturen. Transformation deterministisch · Inhalt intelligent.

6.2.3 Release-Governance: draft/published-Versionsisolation + Abnahme-Test-Gate

Der Orchestrator speichert Entwürfe, bei der Veröffentlichung wird ein unveränderlicher semver-Versions-Snapshot erstellt, online läuft immer die neueste published-Version. Vor der Veröffentlichung wird zuerst die Abnahme-Testsuite ausgeführt (Stub-KI-Ausgaben + skriptbasierte menschliche Prüfung + Stub-Fähigkeiten, deterministische Wiedergabe), veröffentlicht wird erst, wenn alles grün ist — Abnahmetests = Release-Gate, zugleich das L2/L3-Regressions-Sicherheitsnetz. Historische Versionen sind rücksetzbar.

6.2.4 KI-Kognitions-, Entscheidungs- und Handlungsknoten

Ein Primitiv trägt Klassifikation / Bewertung / Extraktion / Bildverstehen / eigenständiges Werkzeugaufrufen: strukturierter JSON-Ausgabevertrag + starke Schema-Validierung der Modellausgabe, agentic-Agenten-Schleife (function-calling, jeder tool_call hinterlässt eine Spur), multimodales Sehen (Bilder werden über das visuelle Modell in Beschreibungen umgewandelt), knotenebene Modellfeld-Überschreibung und semantisches Routing.

6.2.5 KI-Mitarbeiter-Knoten + menschlicher Prüfknoten (Mensch-Maschine-äquivalente Akteure)

Der ai_staff-Knoten gibt Arbeit an KI-Mitarbeiter ab, die bei identity in der Stammrolle stehen (sie arbeiten in cohort), der menschliche Prüfknoten hält an, bis der Mensch entscheidet — beide Akteurstypen haben jeweils eigene SLAs und eine eigene Eskalationskette über den Organisationsvorgesetzten. KI-Mitarbeiter sind keine Skripte, sondern Kollegen; Menschen sind gleichwertige Knoten im Prozess.

6.2.6 Orchestrierungs-Variablenmodell mit den vier Scopes obj/steps/sys/env

Knoten-Eingabeabbildungen und Verzweigungsbedingungen verwenden typisierte Ausdrucks-ASTs; der Datenfluss ist deterministisch, abspielbar und testbar — Verzweigungsbedingungen sind keine Blackbox-Prompts, sondern abnahmefähige Deklarationen.

6.2.7 Governance-Rückgrat (Durchsetzung statt Anzeige)

• Kill-Switch-Trennschalter: global / pro Anwendung mit einem Klick abschalten (423);
• Kontingent-Rate-Limiting: pro-App-Laufrate (429);
• Token-Budget: Übersteigt die kumulierten Token eines einzelnen Laufs den Grenzwert, bricht die Engine ab;
• Content-Safety-Gate: verbotene Wörter + PII-RegExes (Handy / E-Mail / Personalausweis), mode = off/flag/block;
• Audit: Audit-Protokolle werden aus run-trace-Ereignissen projiziert und sind exportierbar (SOC 2 / MLPS / EU-AI-Act-Forensik).

6.2.8 cohort-Integration (app-as-tool)

In der cohort-Konversation wird die Anwendung als Werkzeug verwendet: Anwendung auswählen → Formularkarte (präzise Eingabe) → run starten, an die Gesprächsthread gebunden → Ergebnisse / menschliche Prüfkarte zurückliefern. Formular-Vorbefüllung läuft durch das Herkunfts-Gate (nur Felder mit Beleg werden befüllt); Ergebnis-Karten-Narrativvorlagen ersetzen Platzhalter mit echten Ergebnissen (ganzer Abschnitt wird verworfen, wenn kein Wert verfügbar, null LLM, null Erfindung).

6.2.9 Design-Tab + Mehrkanal-Anpassung

KI erzeugt aus echten Produktfeldern deklarative Baustein-Layouts, serverseitig hart validiert (Block-Enumeration + bind behält nur echte Felder + Array-Blöcke müssen an Array-Felder gebunden sein, Erfundenes wird verworfen). Einmal orchestrieren, mehrkanalig liefern: cohort-Vier-Spalten-Shell / Enterprise-IM (WeCom / DingTalk / Lark-Karten) / Web-Widget.

6.2.10 Automatisierte Auslösung + MCP-Exposition + Debugging-Beobachtung

Anwendungen können von manuellem Aufruf zu zeitplan- / webhook-automatisierter Auslösung wechseln; jede veröffentlichte Anwendung wird als MCP-Werkzeug exponiert, das jeder Agent aufrufen kann (kein umzäunter Garten); SSE-Stream-Debugging + dry-run-Probe + Knoten-Mock-Abdeckung + Breakpoint-Debugging.

6.3 Differenzierung

• Nicht Dify / n8n: „KI-native Orchestrierung auf Geschäftsobjekten” mit Typverträgen für Geschäftsobjekte + Event Sourcing;
• Abnahmetests = Release-Gate: KI-Orchestrierung ist so qualitätskontrollierbar wie Software-Engineering;
• KI-Mitarbeiter sind Mensch-Maschine-äquivalente Akteure: mit Stelle, SLA, Vorgesetzten-Eskalationskette;
• Governance ist echte Abfangung, keine Anzeige: Trennschalter / Kontingent / Token-Budget / Content-Safety-Gate greifen alle auf Engine-Ebene.

7. capabilities — der Kompetenzmarktplatz

Auf einen Satz: der App Store für Enterprise-KI-Fähigkeiten — ein Fähigkeitsvertrag, KI als Werkzeug, Mensch als UI, mit Vollketten-Governance von Produktion und Markt über Beschaffung, Autorisierung bis zur Air-Gap-Verteilung.

7.1 Positionierung

capabilities ist die unabhängige Plattformebene dafür, „woher Fähigkeiten kommen” (Produktion / Plattform), gehört keinem Konsumenten-Host. Die tragende Wand ist die Produktions-/Konsum-Zweiteilung: die Fähigkeitsplattform verantwortet Register-SSOT + Markt + Installations-Governance + Zugangsdaten-Tresor + Aufruf-Gateway + Plattform-Konsole; cohort (Chat / KI-Mitarbeiter) und studio (Anwendungs-Orchestrierung) sind über den SDK-Vertrag konsumierende Hosts mit jeweils eigener nativer UI, niemals mit umgekehrter Abhängigkeit.

Das behebt den früheren Architekturfehler, Register / Gateway in cohort-server zu verschweißen — studio hatte einst per env-Hardcode direct executor umgangen und die gesamte Plattform.

7.2 Kernfähigkeiten

7.2.1 Register-SSOT + Release-Lebenszyklus

Manifest, Version und Status von Skills / Plugins haben eine einzige Wahrheit. Produzentenseite draft → in_review → published / rejected, state (active / archived) orthogonal. .tueopkg-Upload wird validiert (semver / Fähigkeitsdeklaration / Payload-Integrität) und als Entwurf abgelegt, Originalpakete werden per sha256-digest inhaltsadressiert gespeichert.

7.2.2 Signatur- und Vertrauens-Governance (Ed25519)

Manifests können signiert werden → Ed25519-Detached-Signatur → aus der Signaturprüfung werden die drei Vertrauensstufen official / partner / community abgeleitet. Der Signaturalgorithmus ist byteweise identisch über Repositories (durch Drift-Lock-Tests gesichert). Deklarierte Signatur, die die Prüfung nicht besteht = Manipulation / Identitätsvortäuschung, bei der Installation abgelehnt.

7.2.3 Installations-Governance (Mandantenebene)

Welche Skills ein Mandant installiert hat + ob sie aktiviert sind. Installation = Bereitstellungszustand, Aktivierung = Laufschalter, Benutzerpräferenz = persönlicher Schalter, drei Ebenen klar getrennt. Das Aufruf-Gateway schaltet ein assertEnabled-Hart-Gate vor.

7.2.4 Zugangsdaten-Tresor (mandantenebene Verschlüsselung)

Plugin-Konfiguration: settings im Klartext + secrets verschlüsselt (AES-256-GCM), beim Gateway-invoke entschlüsselt und injiziert; Benutzer und KI sehen das Secret nie. Über Hosts hinweg (cohort / studio) gleiche Quelle, sichtbar.

7.2.5 Aufruf-Gateway (Dispatch nach kind + fest verschweißte Bezahlung / Messung)

Ein Aufruf durchläuft Installations-Gate + Bezahl-Gate + Verfügbarkeitsbereich-Gate → Zugangsdaten entschlüsselt und injiziert → Dispatch nach kind: action → executor-Sandbox / knowledge → direkte Inhaltsrückgabe in den LLM-Kontext des Hosts (null Sandbox, null Kosten).

★Bezahl-Gate und Nutzungsbuchung sind fest im Gateway verschweißt: jeder indirekte / delegierte Aufruf passiert natürlicherweise das Gate und wird gebucht — behebt die „Bezahlung umgehen”-Lücke.

7.2.6 Geschlossener Kreislauf der Beschaffungs-Governance

Testen → Antrag-Genehmigung → Bestellung (Firmenzahlung / online) → Finanzbestätigung → Rechnung, durchgängig protokolliert. Budget-Gate (verbraucht + in Bearbeitung + dieser Auftrag ≤ Obergrenze), Käuferseiten-Selbstaudit-Derivationsfluss (Aufträge / Rechte / Anträge / Installationen / Bereichsänderungen werden zu einer Timeline aggregiert).

7.2.7 Kommerzialisierung / Preisgestaltung

Preise liegen auf dem Produkt (Stripe-Paradigma): der Betreiber setzt einen globalen Preis pro Skill und kann für einen bestimmten Kundenmandanten einen B2B-Vertragspreis zur Überschreibung setzen. Eiserne Abrechnungsregel: nur einmaliger Kauf oder Abonnementdauer, keine nutzungs- / sitzplatzbasierte Abrechnung (Nutzung ist reine Betriebsanalyse, keine Messung).

7.2.8 Rechte-SSOT + Abonnement-Lebenszyklus

„Dieser Mandant ist zur Nutzung eines bezahlten Skills autorisiert” hat eine einzige Wahrheit. Online- und Offline-Pfade schreiben dieselbe Tabelle, das Gate liest einheitlich. Ablauf = sofort ungültig, regelmäßige Cleanup-Sicherung, Banner-Warnung vor Ablauf. Abonnementverlängerung durchläuft erneut Vertrag + Rechnung + Neuausstellung.

7.2.9 Offline-Autorisierungsaktivierung (signierte Lizenz als einzige SSOT)

Bezahlte Aktivierung für private / Air-Gap-Kunden: die signierte Lizenzdatei ist die einzige Vertrauenswurzel, Online ist nur der Transport, Air-Gap überträgt dieselbe Datei manuell. Software-Knotensperre = deploymentId (beim ersten Plattformstart erzeugt, verhindert das Kopieren einer Datei auf mehrere Installationen, sperrt keine Hardware und verärgert keine Kunden). Keine Online-Aktivierung / kein Heartbeat / kein technischer Widerruf (reines Vertragsvertrauen).

7.2.10 Air-Gap-Offline-Verteilung (.tueoupdate als einheitliches Artefakt)

Skill-Bits ins Intranet bringen: ein signiertes Update-Paket transportiert zugleich Verzeichnis und Plattformkomponenten, console als einziger Import-Eingang. Signiertes Manifest als unveränderliche tragende Wand (Bundle-Speicherung lokal über eigene Spalte, manifest niemals mutieren, sonst bricht die Signaturprüfung). Standard bundle-runtime ohne Images.

7.2.11 Verfügbarkeitsbereich + Nutzungs-Betriebs-Dashboard

„Wer innerhalb des Mandanten einen Skill nutzen darf” als Autorisierungszuteilung (mode = all / departments / users, Datenquelle identity-SCIM). Das Nutzungs-Dashboard beantwortet „ob sich die Fähigkeit lohnt, ob Verschwendung und Risiko vorliegen” (Erkennung ungenutzter Rechte = Rechte ohne Aufruf = verschwendetes Geld).

7.2.12 Geschlossener Vier-Schritte-Kreis der Berechtigungen

Entwickler deklarieren permission[] → Frontend-Risikostufung mit rotem Label (Netzwerk / Dateisystem / Ausführung / Schlüssel) → Einwilligungsdialog bei der Installation (Erteilungszeitpunkt, Audit) → Erzwingung zur Laufzeit in der executor-Sandbox (ohne gewährte Netzwerkberechtigung unshare-Netzwerknammensraum, wirklich netzwerkgetrennt, null ausgehend, gegen Datenabfluss).

7.3 Differenzierung

• Ein Fähigkeitsvertrag, zwei Konsumenten: dieselbe Fähigkeit kann von KI als Werkzeug (executor-Sandbox) und von Menschen als UI (deklarativ / Frontend-Bundle) genutzt werden;
• Kommerzieller Kreislauf nativ in das Aufruf-Gateway verschweißt: delegierte / indirekte Aufrufe passieren natürlicherweise das Gate + Buchung;
• Signierte Lizenz als einzige Autorisierungs-SSOT: Air-Gap und Online über denselben Mechanismus;
• Produktionszustand-Schlüssel fail-closed: fehlender offizieller Signatur-Private-Key / Tresor-Masterschlüssel / Sitzungsschlüssel / S2S-Token → Startverweigerung (verhindert, dass öffentliche Dev-Seeds die offizielle Signatur und Offline-Lizenzen fälschen);
• Hochwasser-Schutz gegen Zurückstellen der Uhr + zeitgesteuerte Bereinigung aller Mandanten bei Ablaufende — gegen Kunden, die im Air-Gap die Uhr zurückstellen, um abgelaufene Abonnements zu verlängern.

8. executor — die Sandbox-Ausführungsbasis

Auf einen Satz: die Hände der KI — nicht vertrauenswürdigen Code / Befehle / Images in eine isolierte Sandbox legen, prüfbar, planbar, skalierbar, damit KI-Mitarbeiter echte Dinge erledigen und strukturierte Ergebnisse zurückgeben.

8.1 Positionierung

cohort (Arbeitsbereich), studio (Orchestrierung) und capabilities (Kompetenzmarktplatz) entscheiden „was getan wird”, executor übernimmt „es wirklich tun” — nimmt Codepakete / Befehle / eigene Images, startet über K8s-Jobs isolierte Runner-Sandboxes, führt aus, ruft strukturierte Ergebnisse zurück, durchgängig auditiert. Es ist die einheitliche Fähigkeits-Ausführungsfläche der Plattform und die Isolationswand innerhalb der Vertrauensgrenze, in der „Benutzercode nicht vertrauenswürdig” gilt.

8.2 Kernfähigkeiten

8.2.1 Sandbox-Ausführung mit mehreren Laufzeiten (Python-Pakete / allgemeine Befehle / eigene Images)

Ein Job-Vertrag trägt drei Ausführungsarten: Python-Codepaket (pip installiert Abhängigkeiten → import entrypoint → main(**inputs)), command-Variante (sprachunabhängig, beliebige Shell ausführen), image-Variante (pro Job das angegebene Image starten). Große Eingaben (>64KB) überlaufen in eingehängte Dateien, um env-Limits zu umgehen; command-Varianten ohne Netzwerkberechtigung laufen im unshare --net-Netzwerknammensraum, netzwerkgetrennt.

8.2.2 K8s-native Isolation + Fünf-Stufen-Prioritätsscheduling + Ressourcenkontingente pro Job

Jeder Job wird ein eigener Pod: ohne Privilegien, nur-Lese-Root-Dateisystem, alle capabilities gedroppt, seccomp RuntimeDefault, nach der Ausführung automatisch recycelt. Fünf Prioritätsstufen (CRITICAL kann BACKGROUND verdrängen) + pro Job konfigurierbare CPU / Speicher.

8.2.3 Zulassungskontrolle + Prioritätswarteschlange

Globale Parallelitätsgrenze + per-Mandanten-Kontingent (zur Laufzeit in der DB änderbar) + Host-Ressourcendruck als Dreifach-Backpressure. Jobs über der Parallelitätsgrenze gehen in die QUEUED-Warteschlange und werden nach Priorität + FIFO abgearbeitet; atomare Übernahme verhindert Doppel-Dispatch, ein Mandant am Limit blockiert andere Mandanten nicht.

8.2.4 Reconciliations-Kreislauf (pull is truth, callback is optimization)

Der Callback ist eine Optimierung, der Reconciliations-Kreislauf fragt alle 30 Sekunden aktiv die Wahrheit bei K8s ab, treibt Zombie-Jobs in den Endzustand, bewertet lost und heilt in-flight-Zähler selbst. Ein fehlender Callback klemmt den Lauf nicht.

8.2.5 DAG-Workflow-Orchestrierung

Ein gerichteter azyklischer Graph drückt Abhängigkeiten und Parallelität aus (Job-Mengen mit gemeinsamer dag_id, null separate Tabellen); bei Fehlschlag punktueller Neustart möglich (incremental / full).

8.2.6 Multi-Mandanten-Isolation (fail-closed-Konvergenz)

Alle Ressourcen sind an tenant_id gebunden, Abfragen / Schreiben erzwingen Mandantenfilterung. Ohne Mandant wird direkt abgelehnt statt alles freigegeben. „Alles sehen wollen” und „Mandant vergessen” unterscheiden sich auf Codeebene; plattformweite Aggregationen müssen explizit deklariert werden.

8.2.7 Vollständiges Sicherheitsaudit + Transactional-Outbox-Ereignisse

Alle Lebenszyklusoperationen schreiben in die Audit-Tabelle; Geschäftsoperationen und Ereignisse werden im selben Transaktions-Outbox-Top geschrieben und asynchron als CloudEvents 1.0 zugestellt (CI / Benachrichtigung / Abrechnungskonsumenten), ohne dass das Geschäft blockiert.

8.2.8 Sicherheit von Zugangsdaten und Callbacks

Job-Pods erhalten MinIO-Zugangsdaten mit minimalen Rechten (bucket-scoped); die Callback-URL trägt ein pro Job eigenes HMAC-Token ein, damit Inhaber eines geteilten Tokens nicht beliebige Job-Zustände treiben können; Endzustands-Callbacks sind idempotent (verhindert Zustandsrevival).

8.2.9 KI-Coding-Agent coding-agent

Autonomer Coding-Agent: GitLab-Repo klonen → Werkzeug-Schleife zur Umsetzung des Arbeitsauftrags → Selbsttest → Commit → Branch-Push. Der Passport (tueo-passport-Erweiterungspunkt) wird zu einem harten HARD-Dateibearbeitungs-Gate kompiliert (über die Zone hinaus immer BLOCKED); visuelle Selbstprüfung = echte Chromium-Screenshots + visuelles Modell beurteilt Bilder, kein jsdom-Raten.

8.2.10 Beobachtbarkeit

Prometheus-Metriken (Scheduling-Latenz / Wartezeit in der Warteschlange / in-flight pro Mandant / Knoten-Wasserstand) + Echtzeit-Snapshots der Knotenressourcen + Echtzeit-Container-Protokolle laufender Jobs + Wiederaufbau der Ausführungs-Timeline aus persistenten Daten.

8.3 Differenzierung

• Einheitlicher Vertrag für mehrere Laufzeiten (python / command / image) statt einer einzigen Python-Sandbox;
• Scheduling ist erstklassig: mandantenebene Fairness + Prioritätsverdrängung, die meisten Sandbox-Produkte haben nur eine einfache Parallelitätszahl;
• Reconciliations-Kreislauf heilt selbst: Wettbewerber klemmen oft bei fehlendem Callback;
• HMAC-Callback-Bindung pro Job + Zugangsdaten mit minimalen Rechten + netzwerkgetrennte Sandbox — Callbacks und Zugangsdaten sind pro Job isoliert.

9. skillplugins — Skill-Plugins und SDK

Auf einen Satz: ein Fähigkeitsvertrag, zwei Konsumenten — KI-Assistenten wirklich „das Geschäft erledigen” lassen und Unternehmensprozessfähigkeiten zu Plugins machen, die signierbar, sandboxbar und marktgängig sind.

9.1 Positionierung

skillplugins ist die produktionsseitige und vertragliche tragende Wand der TUEO-Plugin-Plattform, der Ursprung der vierschichtigen Architektur: skillplugins (Plugin-Pakete + SDK) / Fähigkeitsplattform (Register + Governance + Dispatch) / executor (Backend-Sandbox) / desktop (Frontend-Rendering). @tueo/plugin-sdk ist die einzige Quelle für die vier Ebenen manifest / capability / invocation.

9.2 Kernfähigkeiten

9.2.1 Plugin-Manifest-Vertrag (PluginManifest)

Ein Plugin definieren = manifest (Fähigkeitsdeklaration) + backend (executor-Ausführung) + frontend (desktop-Rendering), drei Teile. Sprachneutral (input / output mit JSON Schema, auch das Python des executor validiert). humanSurface bietet die drei Einstiege slash (Befehl) / form (automatisch abgeleitete Formulare) / preview (Vorschau in der vierten Spalte).

9.2.2 Plugin-Signatur und Vertrauens-Governance

Die Veröffentlichungsseite signiert das manifest mit einem privaten Schlüssel (Ed25519-Detached-Signatur), die Lade-/Installationsseite verifiziert über eine vertrauenswürdige Public-Key-Registry und leitet die Vertrauensstufe ab. Manipulation = Signaturprüfungsfehler, Anti-Manipulations-Assertion bei der Installation.

9.2.3 I/O-Vertrag der Backend-Laufzeit

Eingaben werden aus cwd/inputs.json gelesen, Ergebnisse nach $OUTPUT_DIR/result.json geschrieben, große Dateiprodukte lädt der Runner einheitlich nach MinIO hoch. Autoren brauchen nur serve({capabilityId: handler}); I/O, Fehler-Normalisierung und Exit-Codes übernimmt das SDK.

9.2.4 Referenzimplementierung: deck (Präsentationen)

17 Layouts (title / section / bullets / kpi / twocol / process / chart / statement / agenda / compare / timeline / composite / scorecard / matrix / gantt / pillars / figure) + Aktionsüberschriften + 4 Design-Sprachen. Dasselbe DSL erzeugt HTML-Vorschau und bearbeitbare .pptx-Exporte (Vorschau = Export-konsistent, kein „Vorschau schön, Export zerstört”). PptxGenJS-Motiv mit eleganter Degradation.

9.2.5 Stilvererbung vorhandener PPTs

Vorhandene .pptx importieren: der Inhalt wird serverseitig geparst, der Stil extrahiert durch das Plugin die Farben + Schriften aus theme1.xml zu einer Design-Sprache, nur Farben und Schriften werden ersetzt, die Plattform-Layoutqualität bleibt erhalten — Kunden-Branding-Assets sind erbbar.

9.2.6 pharma-doc (Pharma-Compliance-Beispiel)

Plugin zur Erkennung von Arzneimittel-Lieferscheinen: VLM extrahiert 12 Felder → das Plugin führt eine deterministische Regelvalidierung durch (Format der Zulassungsnummer / Produktionsdatum < Verfalldatum / Verfalldatum > heute / Menge > 0 / Pflichtfelder) → grüne / gelbe / rote Farb-Review-Vorschau. Die Validierungsschicht ohne Modellaufrufe ist idempotent, testbar und prüfbar; nur in <1 % greift der Mensch ein.

9.3 Differenzierung

• Ein Fähigkeitsvertrag, zwei Konsumenten: dieselbe capability wird zugleich der KI (function-calling-Werkzeug) und dem Menschen (slash / Formular / Vorschau) ausgesetzt, gleiche Eingabe byteweise identisch;
• KI für Extraktion und Inhalt, Regel-Engine für deterministische Validierung: Ergebnisse idempotent, testbar, prüfbar;
• Design-Token-getriebenes Rendering: Vorschau = Export, Sprachwechsel = Token-Datei wechseln, null Engine-Änderung;
• Resilienz und ehrliche Degradation: eine kaputte Seite → Platzhalterseite, nicht das Ganze zerstören; kein Wert verfügbar → „—”, kein Erfinden.

10. codex-build — die Coding-Engine

Auf einen Satz: der Coding-Kern von TUEO — KI-Mitarbeiter „echt arbeiten, echt liefern”, kein selbsterzählender Agent mehr, sondern eine echte Coding-Ausführungs-Engine mit Unternehmensidentitätsgrenzen und prüfbarer Protokollierung.

10.1 Positionierung

codex-build ist die einheitliche Ausführungs-Engine der gesamten TUEO-Plattform und der Coding-Kern des KI-Entwicklungsteams. Sie ersetzt die drei bisher getrennt auf Server und Desktop selbst geschriebenen Agent-Schleifen (rund 13.300 Zeilen).

Architektur-Arbeitsteilung in einem Satz: die Engine übernimmt „wie” (echtes Lesen der Codebasis / Dateien ändern / shell ausführen / im Web suchen / lange Aufgaben / Subagenten), der Server übernimmt „ob überhaupt, was, und welche Spur” (Identität, Autorisierung, Kontext, Zugangsdaten, Audit), der Desktop übernimmt „sichtbar, klickbar, lokal erreichbar” (Pairing und Rendering).

Native Interaktionen der Engine und eigene Login-Fähigkeiten sind vollständig gesperrt, nur der verwaltete Einstieg bleibt — sie ist eine Runtime erster Klasse, die von der TUEO-Plattform zu einem Unternehmens-Ausführungswerkzeug „gezähmt” wurde, kein eigenständiges Terminalprodukt.

10.2 Kernfähigkeiten

10.2.1 Echte Codierungsausführung (nicht narrativ)

Von „behauptet getan” zu „wirklich getan”: der Agent klont im echten Repository-Arbeitsbereich → liest Code → ändert Dateien → führt Tests aus → committed → pusht → erstellt MR, mit echten Dateien / Diffs / Branches. Eingebaute Werkzeugfamilie: read_file (mit image / pdf / pptx / metadata-Parsern), search_replace, bash, grep, list_dir, monitor, scheduler, todo, web_search / web_fetch.

10.2.2 Die Codebasis verstehen

Aufbau und Navigation der Struktur großer Codebasen: Code-Index (index_manager + languages + scope_graph), Arbeitsbereichsverwaltung (folder trust + Dateisystem-Benachrichtigungen), Kontext-Pakete (Context Pack: Rollen-/Einschränkungsabschnitte + Arbeitsauftrag-spec / plan / AC + Modell-Routing), die pro Aufgabe materialisiert in den Arbeitsbereich injiziert werden.

10.2.3 Verwaltete Laufzeit (ACP-eingebettet)

Über das Agent Client Protocol (stdio JSON-RPC) von desktop / executor gesteuert, mit langen Sitzungen, Echtzeit-Ereignis-Rückfluss, Berechtigungs- und Genehmigungs-Popup-Karten. Erweiterungsmethoden implementieren Berechtigungsanfragen, Nutzerfragen, Subagenten-Zustimmung und Ordnervertrauen — alles über Popup-Karten des Desktops und Rückmeldung.

10.2.4 Subagenten-Kollaboration (hartes Engine-Gate)

Der Hauptagent kann je nach Aufgabekomplexität parallel / verschachtelt Subagenten starten, aber vor jedem ersten Subagenten-Spawn muss ein Engine-Hart-Gate zur Zustimmung passiert werden. Invarianten: nur einmal fragen, Anfragen pro Benutzer verfallen, keine Werkzeug-Fähigkeiten erteilen — „ob Subagenten-Kollaboration eingesetzt wird” wird zu einer pro Anfrage bestätigbaren Unternehmensentscheidung, nicht über Prompts.

10.2.5 MCP-Anbindung von Geschäftsfähigkeiten

Die Engine konsumiert als MCP-Client den serverseitigen tueo-MCP-Server: Arbeitsaufträge / Anwendungen / Konnektoren / Wissen / Zusagen / Anhänge / Nachrichten als einziger Ausgang in die Engine. Geschäftsfähigkeiten verstreuen sich nicht engine-seitig, Zugangsdaten werden nicht an den Client weitergegeben.

10.2.6 Unternehmensidentitätsgrenzen

Native API-Keys / Login mit eigenem Konto / interaktives Terminal / headless / Relay / Sitzungsverlaufsausführung sind dauerhaft vollständig deaktiviert, der verwaltete Modelleinstieg = ACP + identity. Sitzungen werden in owner-sidecar geschrieben (0600, issuer / tenant / subject), new / load / prompt / cancel alle fail-closed, mandantenübergreifende Sitzungsübernahmen werden ausgeschlossen.

10.2.7 Zugangsdaten bleiben auf dem Server

Die Engine hält keine Modellanbieterschlüssel, nur kurzfristige Sitzungstickets des Servers und leitet echte Modelle über das Engine-Gateway weiter. Der echte Schlüssel verlässt nie den Prozessspeicher des Servers.

10.2.8 Visuelle und sprachliche Multimodalität

Rein textbasierte Hauptmodelle bekommen Bilder / Audio ohne Fehler: Bilder werden über ein unterstützendes visuelles Modell in Beschreibungen umgewandelt (kein Zurückfallen auf Originalbilder für das Hauptmodell), Sprache wird über die eingebaute Sprachlaufzeit der Engine verarbeitet (Streaming-Diktat + Synthese). Das Modell-Routing bestimmt immer der Server, Clients können keine Modelle benennen.

10.2.9 Sandbox- und Prozessisolation

Eingebaute Sandbox-Profile in mehreren Stufen + deny glob + Netzwerktrennungspolitik. Mehrere Mandanten teilen dieselbe Installation und sind gegenseitig unsichtbar: Linux-Benutzer + eigenes home (alle benutzerzustandsbasierten Datenpfade) + Bubblewrap, die Engine-Daten jedes Mandanten liegen in eigenen Verzeichnissen.

10.2.10 Folder-Trust-Gate (rote Linie der Code-Ausführungsfläche)

Geklonte Repositories mit Hooks / MCP-Konfiguration / Umgebungskonfiguration werden standardmäßig nicht geladen und ausgeführt (sonst wäre Klonen gleich Remote-Code-Ausführung). Build-Zeitstempel: ungestempelte Builds verlieren folder trust still, Veröffentlichungen müssen über das Release-Skript + rote-Linie-Validierung (Repos mit Hooks müssen eine Vertrauensfrage auslösen, sonst keine Veröffentlichung).

10.2.11 Nachvollziehbare Upstream-Governance (Fork-Gesundheit)

TUEO verwaltet Änderungen am Upstream über Patch-Kontenbuch + Quellen-Äquivalenzvalidierung + eingeschränkte Schicht-Spezialisierung: TUEO_UPSTREAM.toml pinnt die Upstream-Commit-SHA, Quellarchiv-Äquivalenzprüfung (file_count + manifest_sha256 + status=passed), CI erzwingt Metadaten-Konsistenz. Jederzeit beantwortbar: „Aus welchem Upstream-Commit stammt dieser Code, von welchem Patch geändert, kann er zurückgerollt werden”.

10.3 Differenzierung

• Von „selbsterzählendem Agenten” zu „echter Ausführung”: echte Dateien / Diffs / MRs, Coding-Lieferung vertrauenswürdig;
• Eine Coding-Engine vereinheitlicht die gesamte Plattform: beseitigt die drei getrennt geschriebenen Agent-Schleifen von Desktop / Server;
• Enterprise-Vertrauens-Vierersatz: Identitätsgrenzen, Zugangsdaten bleiben auf dem Server, Dreifach-Bestätigungskarten für Subagenten / Berechtigungen / Ordnervertrauen, prüfbare Protokollierung;
• Fork-Governance ist ein Verkaufsargument: jedes Patch hat ein Kontenbuch, jede Veröffentlichung eine Quellen-Äquivalenzvalidierung, rollbar — private Kunden trauen sich;
• Multi-Mandanten-Prozessisolation + Lieferung als einzelnes Binary, direkt einsetzbar für Offline- / private Bereitstellung;
• Dogfood-Engineering: das KI-Entwicklungsteam entwickelt mit dieser Engine die TUEO-eigenen Produkte.

11. console — Betriebsebene der intelligenten Basis · private Bereitstellung und Betrieb

Auf einen Satz: die Betriebsebene der intelligenten Basis — aus der Bare-Metal-Maschine in einem Klick zu einer TUEO-Produktionsumgebung, danach Betrieb aller Dienste und Middleware über eine Oberfläche.

11.1 Positionierung

console (TUEO-Console-Betriebsplattform) ist die Betriebsebene der intelligenten Basis und die „Bereitstellungs- und Betriebsbasis”: oben tragen alle Produktlinien, unten verwaltet es k3s / Harbor / CNPG / Middleware. Neue Systeme, alte Systeme, KI-Systeme — das gesamte System über einen Zugang betreiben. Drei Bausteine bilden den vollständigen Lebenszyklus — console = privater Installer + betriebsinterne Betriebszentrale (Deploy-Orchestrierung / Konfigurationszentrale / Statuswand / Protokolle / Backup / Upgrade / Audit), tueo-ci-images = zweischichtige unveränderliche Offline-CI-Images, tueo-build = Quellcode und Release-Pipeline der Coding-Engine. Die Basis (db / redis / k3s / MinIO) ist ebenfalls ein von ihr betriebenes Managed-Objekt — sogar sie selbst ist ein Managed-Objekt (Selbst-Upgrade nur durch Image-Tausch, Genesis-Manifest bleibt dauerhaft SSOT).

11.2 Kernfähigkeiten

11.2.1 Diensteverzeichnis-SSOT (manifest)

Die an mehreren Stellen verstreuten Register werden zu einem einzigen deklarativen Diensteverzeichnis konvergiert (11+ Dienste: ops-console / postgres / redis / minio / identity / cohort-server / executor / studio-api / studio-web / capabilities-api / cohort-desktop / skillplugins), statische Topologie als einzige Wahrheit. Produktlinie hinzufügen = eine JSON-Zeile + PR, null Code.

11.2.2 Drei-Driver-Deploy-Orchestrierung (local-dev / compose / k8s)

Unter demselben Domänenmodell drei Laufzeit-Trennungen: native lokale Prozesse, Einzelmaschinen-Docker, vorhandenes K8s des Kunden. Eine Plattform verwaltet lokale Entwicklung und Einzelmaschine sowie bestehende Cluster des Kunden; Kunden ohne K8s können trotzdem installieren (eigene k3s-Basis mitgeliefert).

11.2.3 Image-Promotion-Gate + Deploy in einem Klick (Build-Registry → Runtime-Registry)

CI pusht Images nur in die Build-Registry; die Plattform kopiert den Tag über Harbor-pull in der Clusterumgebung in die Intranet-Runtime-Registry (Promotion) und wendet erst nach Tag-Bereitstellung apply + rollout an. Ein Produkt-Repo erhält durch Include einer Vorlage die vollständige Produktions-Pipeline aus build-image + deploy-prod; Images promoten automatisch von der Online-Build-Registry zur Intranet-Runtime-Registry, null Handarbeit.

11.2.4 Konfigurationszentrale (Schlüssel AES-GCM in der Datenbank + Versions-Rollback)

Normale Konfiguration deklarativ gerendert, Schlüssel verschlüsselt in der Datenbank (AES-256-GCM, Masterschlüssel), Versions-Snapshots rücksetzbar, Schlüssel kommen nie in git. Unterstützt die beiden Backends lokal-AES / Vault.

11.2.5 Lebenslinie des privaten Betriebs

Pre-Install-Health-Check (umfassende Preflight-Assertions), Vollbackup-Wiederherstellung, Air-Gap-Remote-Support-Diagnosepaket, backup-priorisierte Upgrade-Migration. Backup-first + Rollback-Punkt + Upgrade-Historie — wenn vor Ort beim Kunden wirklich etwas passiert, gibt es Backups zur Wiederherstellung und Diagnosepakete für Remote-Rettung.

11.2.6 Statuswand + Datenbetriebspanel

Betriebspersonal betreibt alle verwalteten Workloads und Middleware über eine Console-Oberfläche: kein kubectl, keine Subdomains merken, keine nackten Datenports. PG / Redis öffnen nie ein öffentliches Ingress, schwere Operationen laufen über bedarfsweise temporäre sichere Tunnel (kurze TTL + Audit).

11.2.7 Offline-Update-Import (.tueoupdate-Signaturprüfung + Pre-Check + Verzeichnisweiterleitung)

Die Plattform ist die Verteilzentrale für Offline-Updates: .tueoupdate-Paket Ed25519-offiziell signiert prüfen → Pre-Check-Kompatibilitäts-Gate → bundle-Abschnitt an capabilities zur Importierung, image-Abschnitt per skopeo in Harbor. Nicht bestanden / keine Signatur → Ablehnung.

11.2.8 Plattform-Selbst-Upgrade (dogfood, nur Image-Tausch)

Die Betriebsplattform stellt sich selbst bereit: Genesis-Bootstrap einmalig manuell, danach push main automatisch build → promote → Image-Tausch → Pollen von /api/version bis Konvergenz. Das Upgrade ändert nur den Image-Tag und sprengt das Genesis-Manifest nicht (PVC / Masterschlüssel / ConfigMap / Gateway bleiben vollständig erhalten). Klassisches Self-Managed-Plattform-Muster.

11.2.9 Reproduzierbare CI-Basisimages (Lieferketten-Sicherheit)

Zweischichtige unveränderliche Offline-CI-Images: lock pinnt alle Eingaben (Basisimage-digest + Debian-Snapshot-Zeitstempel + name=version-apt-Pakete + Binary-Checksummen), Build reproduzierbar, offline, mit Signatur und SBOM. Normale MRs null Online-Zugriff, null Downloads; Build-Zugangsdaten existieren nur im geschützten Runner — Lieferketten-Angriffsfläche minimiert.

11.2.10 Privates Bereitstellungspaket (wiederholbares Kit)

Ein Satz wiederholbarer Skripte + Manifeste, die aus einer Bare-Metal-Maschine eine TUEO-Produktionsumgebung machen: ein Standort-Manifest ausfüllen und in der Reihenfolge 00 → 60 ausführen, wiederholbar, kein manuelles Tippen von SSH. TUEO härtet sich mit demselben Paket selbst (dogfood).

11.3 Differenzierung

• Private Hauptlinie statt SaaS: pro Kunde eine unabhängige Einzelstandort-Installation, Offline- / Air-Gap-Standard, Installation in einem Klick, Lieferung als Offline-Bundle + Lizenz;
• Gegen Überdesign: kein Argo / Vault / Loki-Rundumschlag, Werkzeuggewicht passend zur Problemgröße;
• Diensteverzeichnis = manifest-Datei als SSOT: behebt die wiederkehrende Drift-Wurzel „DB ist Wahrheit, Dateien sind Seed”;
• Echtes Dogfood: die Plattform stellt sich selbst mit dem eigenen k8s-Driver bereit und stellt mit der eigenen API echte Dienste im Cluster bereit;
• Offline-Update-Lieferkette: .tueoupdate-Pakete mit Signaturprüfung + Pre-Check-Kompatibilitäts-Gate + Verzeichnisabschnitt-Weiterleitung, unsignierte Pakete abgelehnt.

12. engram — die Wissensgedächtnis-Basis

Auf einen Satz: KI beantwortet mit dem eigenen Wissen des Unternehmens die Fragen des Unternehmens — Wissensbasis, Gesprächsgedächtnis und Wissensverknüpfung auf einer Basis, mit jeder Nutzung genauer, wächst von selbst.

12.1 Positionierung

engram ist die Wissens-/Gedächtnis-Single-Source-of-Truth (SSOT) im TUEO-System und trägt drei Arten plattformweiter Fähigkeiten:

1. Unternehmens-Wissensbasis: Regeln, Dokumente und Prozesse werden zu durchsuchbarem, verifizierbarem Unternehmenswissen verdichtet;
2. Gesprächsgedächtnis: alltägliche Kollaboration und Q&A werden automatisch zu Langzeitgedächtnis verdichtet, die Organisation vergisst durch Nutzung nicht;
3. Wissensverknüpfung: versteht die Verbindungen zwischen Wissen und unterstützt mehrstufige Nachfragen — Fakten zu Urteilen verbinden.

engram ist zusammen mit identity und inference eine der drei Grundbasen und wird von allen Produkten der Suite konsumiert. Es beantwortet „was weißt du und woran erinnerst du dich” — ergänzend zu identity, das „wer bist du” beantwortet.

12.2 Kernfähigkeiten

12.2.1 Unternehmens-Wissensbasis

Regeln, Dokumente und Prozesse werden zu einer Unternehmens-Wissensbasis verdichtet; Q&A antwortet direkt auf Basis der internen Unterlagen — mit Beleg, ohne Erfindung, so lässt KI das Unternehmen mit dem eigenen Wissen antworten, statt ins Blaue mit Allgemeinwissen zu reden.

12.2.2 Gesprächsgedächtnis · automatische Verdichtung

Alltägliche Kollaboration und Q&A werden automatisch zu Langzeitgedächtnis verdichtet; das System fasst automatisch zusammen, entfernt Rauschen und löst Widersprüche auf — die Wissensbasis wird mit jeder Nutzung genauer und wächst von selbst. Raumwechsel und Multi-KI-Kollaboration starten nicht jeweils auf Null.

12.2.3 Wissensverknüpfung · mehrstufige Nachfragen

Beantwortet nicht nur Einzelpunkt-Fragen, sondern versteht auch die Verbindungen zwischen Wissen und unterstützt mehrstufige Nachfragen nach dem Muster „erst A fragen, dann B nachverfolgen” — Fakten werden zu Urteilen verknüpft statt zu verstreuten Suchergebnissen.

12.2.4 Inhaltsicherheit · stufengerechte Kontrolle

Sensible Inhalte werden stufengerecht kontrolliert; wer was sehen darf und was nicht nach außen gehen darf, ist nach den Unternehmensregeln flexibel konfigurierbar — je sensibler, desto stärker kontrolliert, Lecks an der Quelle verhindert.

12.2.5 Einheitliche Berechtigungen · durchgängige Protokollierung

Wissenszugriff und Identitätsberechtigungen werden einheitlich verwaltet; jede Einsicht und jede Antwort ist nachverfolgbar — Daten zwischen Abteilungen streng isoliert, jede sieht nur das Eigene, an dieselbe Identitätsauthentifizierung angebunden.

12.2.6 Leichte Bereitstellung · Daten verlassen die Domäne nicht

Leichte Bereitstellung, kleiner Platzbedarf, chinesisch-optimiert; Unternehmenswissen bleibt immer im Unternehmen — Daten verlassen die Domäne nicht, je mehr genutzt, desto besser versteht es das Unternehmen, vollständig offline bereitstellbar.

12.3 Differenzierung

• Drei-in-eins-Basis: Wissensbasis, Gesprächsgedächtnis und Wissensverknüpfung durchgängig auf einer Basis, statt mehrere Einzelpunkt-Werkzeuge zusammenzusetzen;
• Mit jeder Nutzung genauer: automatische Verdichtung lässt die Wissensbasis selbst wachsen; „Daten verlassen die Domäne nicht, Wissen akkumuliert, nicht austauschbar” ist eine spürbare Verkaufsgeschichte;
• Privat und leicht: leichte Bereitstellung, eine Basis, chinesisch-optimiert, trifft alle to-B-Privatisierungspunkte;
• Von allen Produkten konsumiert: die KI-Mitarbeiter von cohort nutzen sein Gedächtnis für Entscheidungen, die orchestrierten Anwendungen von studio nutzen seine Wissensbasis für bodenständige Antworten.

13. inference — Rechenleistung und Modell-Serving

Auf einen Satz: der privaten KI-Infrastruktur des Unternehmens einen einheitlichen Steuerungskreislauf für Rechenleistung und Modelle geben — heterogene Rechenleistung einheitlich verwaltet, Modell-Serving mit Governance, ein geschlossener Kreislauf, nachprüfbar und zurückrollbar.

13.1 Positionierung

inference ist die Basis für Rechenleistung und Modell-Serving im TUEO-System und trägt drei Arten plattformweiter Fähigkeiten:

1. Heterogene Rechenleistung einheitlich verwaltet: Beschleuniger-Hardware verschiedener Hersteller und Modelle wird in einem Steuerungsplan verwaltet, jeder Pool wird unabhängig betrieben;
2. Standard-Modell-Serving: bietet die branchenübliche Art des Modellaufrufs, bestehende Anwendungen schließen fast ohne Änderung an;
3. Geschlossener Governance-Kreislauf der Rechenleistung: Modelle, Bereitstellung, Training, Kontingente, Nutzung und Audit in einem Steuerungsplan, Kosten immer im Blick.

inference ist zusammen mit identity und engram eine der drei Grundbasen. Es ist der einheitliche Einstieg für Modellaufrufe des gesamten Systems — die Produkte schließen nicht mehr jeweils an eigene Modell-Servings an.

13.2 Kernfähigkeiten

13.2.1 Heterogene Rechenleistung, eine Ebene

Beschleuniger-Hardware verschiedener Hersteller und Modelle wird in einem Steuerungsplan einheitlich verwaltet — jeder Pool wird unabhängig und ohne gegenseitige Störung betrieben, die Rechenleistungslage ist transparent sichtbar, heterogene Ressourcen werden nicht in einen Topf geworfen.

13.2.2 Standard-Modell-Serving, sofort einsatzbereit

Bietet die branchenübliche Art des Modellaufrufs; bestehende Anwendungen schließen fast ohne Änderung an — welche Hardware unten liegt, bemerkt die Anwendung nicht, Laufzeitunterschiede werden verdeckt.

13.2.3 Vollständiges Modell-Lebenszyklus-Management

Vollständiges Management von Modell-Anbindung, Launch, Upgrade, Skalierung und Rollback — laufende Dienste bleiben stabil ohne Unterbrechung, Änderungen sind kontrollierbar und zurückrollbar.

13.2.4 Modell-Training, verwaltete Aufgaben

Feinabstimmung und Training von Modellen laufen als verwaltete Aufgaben und werden auf derselben Plattform wie die Online-Dienste verwaltet, Fortschritt sichtbar — Abschied von Ad-hoc-Skripten, Trainingsergebnisse einheitlich archiviert.

13.2.5 Zugriffs-Governance · Kontingente · Audit

Wer aufrufen darf, wie viel aufgerufen wird und was es kostet, einheitlich an Identität und Berechtigungen angebunden — jeder Aufruf zuordenbar, messbar und prüfbar, Kosten immer im Blick.

13.2.6 Offline-Lieferung · Abnahme vor Ort

Unterstützt vollständig offline Installation, Upgrade und Rollback; vor Ort werden Diagnose und Abnahme bereitgestellt — auch in Air-Gap-Umgebungen lieferbar, die Umsetzung der Rechenleistungsfähigkeit ist garantiert.

13.3 Differenzierung

• Rechenleistung zieht auch ins Rechenzentrum ein: nicht nur die Anwendungen werden ins Rechenzentrum installiert, auch Modell-Serving und Inferenz werden im Kundenrechenzentrum bereitgestellt — Daten und Modelle mit null ausgehenden Aufrufen;
• Ehrliche Heterogenität: verschiedene Hardware je eigener Pool, nicht als einheitlicher Ressourcenpool getarnt, Rechenleistungslage transparent sichtbar;
• Ein geschlossener Kreislauf: Modelle, Bereitstellung, Training, Kontingente, Nutzung, Audit in einem Steuerungsplan, nachprüfbar, beobachtbar, zurückrollbar;
• Von allen Produkten konsumiert: die KI-Anwendungen von cohort und studio rufen über es Modelle auf, die Wissensfragen von engram bekommen über es Rechenleistung.

14. Die vollständige Reise eines Aufrufs

Von einem Satz bis zur kontrollierten echten Ausführung, die vollständige Reise eines Arbeitsauftrags:

① Mensch im cohort-Gruppenchat: @Engineering-KI „Repariere diesen Bug"
   ↓ coordinator-Routing (serverseitige Verantwortlichkeitsbewertung + LLM-Schiedsrichter + Audit)
② KI-Entwicklungsteam-Triage: Absichtserkennung → DoR (KI ergänzt Reproduktionsschritte) → TriageService-Dispatch
   ↓ Passport-Gate + harte Werkzeug-Whitelist-Prüfung
③ Arbeitsauftrags-Zustandsautomat: triaged → spec → plan → coded → reviewed → tested → merged
   ↓ Codierungsausführung (executor-Sandbox / lokales Pairing)
④ Engine ändert echten Code, führt echte Tests aus, committed echt; visuelle Selbstprüfung
   ↓ MR per GitLab-API von cohort erstellt → Code Review → Merge-Gate
⑤ Ergebnisse in den Arbeitsauftrag zurückgeschrieben, in den Gesprächsthread zurück; KI-Review in das Langzeitgedächtnis

Durchgängig von identity-Authentifizierung, capabilities-Governance (bei Aufruf von Drittanbieter-Fähigkeiten), executor-/Engine-Isolation, Audit-Protokollierung — je stärker die KI, desto klarer die Grenzen.

15. Produktübergreifende Designprinzipien

TUEO ist keine Ansammlung von Produkten, die jeweils für sich arbeiten, sondern ein System mit einheitlicher Designphilosophie:

Produktions-/Konsum-Zweiteilung ist die zentralste Architekturentscheidung des gesamten Systems: wer hält die „Wahrheit der Fähigkeiten” (capabilities), wer „konsumiert nur Fähigkeiten” (cohort / studio) — keine Grenzüberschreitung, keine Parallelwelten.

SSOT-Konvergenz ist die zweite zentrale Entscheidung des gesamten Systems: Organisationsverzeichnis → identity, KI-Mitarbeiternamen → identity, KI-Mitarbeiter-Berufsprofile → registry, Fähigkeiten → capabilities, Nachrichten → cohort, Ausführung → executor, Orchestrierung → studio, Lieferung → console. Jede Grenze hat eine einzige Wahrheit, die Wurzel „jeweils eine eigene Kopie an zwei Orten, langsamer Drift” ist beseitigt.

16. Sicherheits- und Compliance-System

14.1 Tiefenverteidigung

14.2 Beweisbares Audit

• identity: pro-Mandanten-SHA-256-contentHash + prev_hash-Hashkette, Manipulation (Einfügen / Löschen / Umordnen / Ändern von Zeilen) erkennbar;
• cohort: 20 Audit-Ereignistypen serverseitig konvergiert + Admin-Web-Konsole zum Abfragen / Aufbewahren / Archivieren;
• studio: run-trace-Ereignisprotokolle (append-only), projiziertes Audit, jedes Ereignis zurück in die Laufspur „abspielbar”;
• capabilities: erstklassige unveränderliche Audit-Tabelle (Migrationen erteilen nur SELECT + INSERT, nicht manipulierbar);
• executor: Volloperationen-Audit + CloudEvents-Ereignis-Ausgang.

14.3 Multi-Mandanten-Isolation

Einheitliches Modell der gesamten Plattform: das identity-Token schreibt den Mandanten fest → RLS-physische Isolation in jedem Produkt → fail-closed (ohne Mandant direkte Ablehnung). Ein System bedient mehrere Mandanten / Abteilungen, null Leckage zwischen Mandanten.

17. Private und Offline-Lieferung

15.1 Lieferformen

• Offline-Bundle + Lizenz: das gesamte System wird zu einem Offline-Bundle gepackt, signierte Lizenz aktiviert, vollständiger Betrieb ohne Netzwerk unterstützt;
• Eigenes k3s: keine Abhängigkeit von einem vorhandenen K8s-Cluster des Kunden; auch Übernahme eines dedizierten Namespace im bestehenden Kunden-Cluster möglich;
• Single-Domain-Appliance: eine externe Domain + Pfad-Routing, alle Produkte gleiche Quelle, eine Sitzungsnorm OIDC;
• Daten verlassen das Unternehmen nicht: Modelle über das eigene Gateway des Kunden / lokale Modelle, Schlüssel verlassen das Kundennetz nicht, durchgängig prüfbar.

15.2 Air-Gap-Lieferkette

• Reproduzierbare CI: zweischichtige unveränderliche Offline-Images, Build ohne Netzwerk, mit Signatur und SBOM;
• Kontrollierte Updates: signierte .tueoupdate-Pakete (Ed25519-Signaturprüfung + Pre-Check-Kompatibilitäts-Gate + Verzeichnisabschnitt-Weiterleitung), unsignierte Pakete abgelehnt;
• Offline-Aktivierung: signierte Lizenz aktiviert ohne Netzwerk + Software-Knotensperre deploymentId.

15.3 Betriebszugänglichkeit

Ein Zugang für den Betrieb aller Dienste + Middleware: Konfiguration / Protokolle / Status / Bereitstellung / Backup / Upgrade / Audit, alles in einer Oberfläche der Betriebsplattform. Datenports nicht nackt, schwere Operationen über bedarfsweise temporäre sichere Tunnel.

18. Einsatzszenarien und Kundenwert

16.1 Zielbranchen

Branchen mit hoher Komplexität, hoher Governance und hoher Echtzeit-Kollaboration: Produktion (Vertragserfüllung), Finanzen (Risikoprozesse), Gesundheitswesen (sensible Zusammenarbeit), öffentliche Verwaltung, Polizei, Energie, Logistik, Handel, Bildung, Recht.

16.2 Typisches Kundenprofil

• Hauptkunden: mittelgroße und große Unternehmen mit vorhandenen digitalen Systemen, die KI in den Organisationsbetrieb bringen wollen; Unternehmen, die bereits KI einsetzen, denen aber Ausführungs- / Sicherheits- / Wiederherstellungsebene fehlen;
• Nebenkunden: abteilungsweite Kunden, die einen Enterprise-KI-Plattform-Piloten starten wollen.

16.3 Kundenwert

19. Status und Route

Folgendes ist der Status von 2026-08. Alle zehn Produkte sind bereits vollständig im Produktionsbetrieb; kontinuierlich weiterentwickelte Erweiterungsfunktionen sind in den jeweiligen Produktartikeln markiert.

17.1 Vollständig getestete End-to-End-Fähigkeiten

Die folgenden Fähigkeiten wurden in realen Umgebungen betrieben und validiert und können nach außen sicher kommuniziert werden:

• KI-Entwicklungsteam-Dogfood-Kreislauf: Arbeitsauftrag → Passport-Gate → LLM-Triage → echtes Codieren → LLM-Review → echte GitLab-CI → automatische Fehlerbehebung bei Fehlschlag → echter Merge → automatische Bereitstellung → Health-Check → Rollback. TUEO entwickelt mit seinen eigenen 8 KI-Mitarbeitern die eigenen 5 Code-Repositories;
• KI betreibt Altsysteme: der Betriebs-KI ai-ops ist über MCP angebunden und trägt Alarmierung / Inspektion / Kapazitätswache / lokale Mehrschritt-Ausführungspläne zur Unterstützung des Betriebs traditioneller Systeme;
• Fähigkeitskoordination (System-as-Capability): vorhandene Systeme wie OA / ERP / CRM / MES werden zu Fähigkeiten angebunden, die KI aufrufen, autorisieren, auditieren und messen kann, und mit dem Gateway der Fähigkeitsplattform fusioniert;
• studio-Orchestrierungs-Engine: 11 Knotentypen + Event Sourcing + persistente Pause-Fortsetzung im Produktionsbetrieb, als Orchestrierungs-Herz der Definitionsebene der intelligenten Basis;
• Konsumseite der Fähigkeitsplattform konvergiert: cohort / studio konsumieren die Fähigkeitsplattform über SDK / S2S (Installations-Gate / Bezahl-Gate / Bereichs-Gate / Zugangsdaten-Injektion), die Konsumseite verbindet nicht mehr direkt mit der Ausführungsbasis.

Meilensteine: private Lieferung ist die verfassungsmäßige Hauptlinie; alle zehn Produkte sind vollständig im Produktionsbetrieb; das KI-Entwicklungsteam, das TUEO mit TUEO-eigenen Produkten entwickelt (dogfood), ist die Normalität; der vollständige Kreislauf der intelligenten Basis (Definition → Entwicklung → Test → Produktionseinsatz → Betrieb → Fähigkeits-Wiederverwendung → Koordination) ist in realen Umgebungen durchgelaufen.

Anhang C · Glossar

TUEO — machen Sie KI zum festangestellten Mitarbeiter Ihrer Organisation.