Glossar
Diese Seite erklärt die wiederkehrenden Begriffe des AI Systems Manager in je ein bis zwei Sätzen. Die Einträge sind alphabetisch geordnet; wo ein Begriff eine eigene Seite hat, verweist der Eintrag dorthin. Für eine Begriffsdefinition genügt der Eintrag hier, für Bedienschritte folgt der Link.
Englische Fachbegriffe (Agent Contract, Eval, Provider, Risk Tier) bleiben in der Oberfläche und in dieser Doku englisch; die deutsche Bedeutung steht jeweils in Klammern.
Begriffe
Abschnitt betitelt „Begriffe“Agent Contract
Abschnitt betitelt „Agent Contract“Die zentrale, versionierte Definition eines Features: Prompt, Output-Schema, Tool-Schemas/-Pins, Provider-Konfiguration, Eval-Kriterien und Risikoklasse (Risk Tier) zusammengefasst an einer Stelle. Der Contract ist das Interface zwischen Fach-Iteration und aufrufendem Code. Siehe Agent Contract.
Audit-Trail
Abschnitt betitelt „Audit-Trail“Das fortlaufende, fälschungssichere Protokoll aller Vorgänge auf der Plattform: wer was wann geändert hat, durchsuchbar und gefiltert. Liegt im Sidebar-Bereich Audit. Siehe Audit.
Compliance / EU AI Act
Abschnitt betitelt „Compliance / EU AI Act“Der Bereich, in dem Risikoklassen-Übersicht und Compliance-Reports im Hinblick auf den EU AI Act zusammenlaufen. Die Plattform ist On-Premise-first und auf die Nachweispflichten des EU AI Act ausgelegt. Siehe Compliance.
Default-Modell
Abschnitt betitelt „Default-Modell“Das Modell, gegen das ein Feature ausgeführt wird, wenn beim Aufruf nichts anderes vorgegeben ist. Fehlt es, lässt sich kein Eval-Run starten. Eingestellt wird es im Feature-Detail-Tab Models (Modelle). Siehe Modelle und Provider.
Domänen-Glossar
Abschnitt betitelt „Domänen-Glossar“Das feature-interne Glossar im Feature-Detail-Tab Prompt: eine Liste fachlicher Begriffe samt Definition, die Domänenexperten und Entwicklern die Sprache des Prompts erklärt (UI-Beschriftung Domänen-Glossar, maximal 50 Terme pro Feature). Nicht zu verwechseln mit dieser übergreifenden Referenz-Seite. Siehe Prompt bearbeiten.
Kurz für Evaluation, die messbare Qualitätsprüfung eines Features. Ein Eval-Run führt das Feature gegen bekannte Quellen aus und vergleicht das Ergebnis mit der erwarteten Ausgabe — Bewertung statt Bauchgefühl. Siehe Evaluation durchführen.
Eval-Baseline
Abschnitt betitelt „Eval-Baseline“Die hinterlegten Schwellwerte, die ein Eval-Run mindestens erreichen muss (etwa Mindest-Pass-Rate). Eine bestandene Eval-Baseline gehört zu den Reife-Kriterien fürs Veröffentlichen; fehlt sie, bleibt das Veröffentlichen gesperrt. Siehe Evaluation durchführen.
Feature-Lebenszyklus
Abschnitt betitelt „Feature-Lebenszyklus“Die Zustände eines Features über die Zeit: Entwurf (draft) → aktiv (active) → veraltet (deprecated) → stillgelegt (sunset, mit Schonfrist). Ein stillgelegtes Feature kann niemand mehr bearbeiten. Siehe Features verwalten.
Feature-Token
Abschnitt betitelt „Feature-Token“Ein vom Master-Token abgeleitetes, eng begrenztes Token für genau ein Feature. Das SDK nutzt es, um beim Aufruf des Features die Inferenz auszuführen; es wird automatisch erzeugt. Siehe Master-Tokens und Feature-Tokens.
Der Bewerter eines Eval-Felds. Drei Arten, abgeleitet aus dem Output-Schema: Code-Grader (exact_match, deterministischer Eins-zu-eins-Vergleich), LLM-as-Judge (llm_judge, ein Bewertungsmodell vergibt eine Note) und Human-Review (human_review, ein Mensch bewertet manuell). Siehe Evaluation durchführen.
Die automatische Vorprüfung einer Version vor dem Veröffentlichen: Sie meldet formale Mängel im Contract, bevor die Version aktiv geschaltet wird. Siehe Veröffentlichen.
Major-Bump
Abschnitt betitelt „Major-Bump“Eine Breaking-Schema-Änderung erzwingt eine neue Hauptversion des Contract und muss ausdrücklich bestätigt werden, weil sich das stabile Interface für aufrufenden Code ändert. Siehe Output-Schema definieren.
Master-Token
Abschnitt betitelt „Master-Token“Der zentrale Zugang zu einem Provider; enthält den eigentlichen Provider-API-Key, verschlüsselt gespeichert. Aus einem Master-Token werden die Feature-Tokens abgeleitet. Siehe Master-Tokens und Feature-Tokens.
Das konkrete Sprachmodell eines Providers, gegen das ein Feature ausgeführt wird (etwa ein bestimmtes Modell von OpenAI oder Anthropic). Modelle werden je Provider verwaltet. Siehe Modelle und Provider.
Output-Schema
Abschnitt betitelt „Output-Schema“Das maschinenlesbare Ergebnis-Format eines Features und das stabile Interface, an dem sich aufrufender Code orientiert. Solange das Schema stabil bleibt, bleibt auch der aufrufende Code stabil. Siehe Output-Schema definieren.
Ein Maß aus mehreren Versuchen desselben Falls: Der Fall wird k-mal versucht, und es wird gezählt, wie viele Versuche bestanden haben (zum Beispiel 2/3). So werden zufällig schwankende Antworten sichtbar. Siehe Evaluation durchführen.
Primär- und Fallback-Provider
Abschnitt betitelt „Primär- und Fallback-Provider“Die Provider-Konfiguration eines Contract benennt einen Primär-Provider für die reguläre Ausführung und optional einen oder mehrere Fallback-Provider, auf die das SDK ausweicht, wenn der Primär-Provider nicht antwortet. Siehe Modelle und Provider.
Production-Readiness
Abschnitt betitelt „Production-Readiness“Die Reife-Prüfung einer Version: Mehrere Kriterien (etwa bestandene Eval-Baseline) werden als Fortschrittsleiste angezeigt. Erst wenn sie erfüllt sind, lässt sich die Version veröffentlichen. Siehe Veröffentlichen.
Provider
Abschnitt betitelt „Provider“Ein LLM-Anbieter, dessen Modelle die Plattform anspricht (etwa OpenAI, Anthropic, Google oder ein lokal betriebenes Modell). Das SDK ist provider-agnostisch, sodass ein Wechsel des Providers eine Konfigurationsänderung bleibt. Siehe Modelle und Provider.
Quelle (Source)
Abschnitt betitelt „Quelle (Source)“Eine Wissens- oder Testunterlage eines Features (Text, PDF, Bild oder E-Mail), die im Feature-Detail-Tab Sources (Quellen) verwaltet wird. Eine Quelle plus die dazu erwartete Ausgabe (Label) bildet ein Test-Paar für Eval-Runs. Siehe Quellen verwalten.
Risk Tier
Abschnitt betitelt „Risk Tier“Die Risikoklasse eines Features in drei Stufen (Tier 1/2/3). Sie ordnet ein Feature nach Schadenspotenzial ein und steuert, wie streng es behandelt wird. Siehe Compliance.
Rollout
Abschnitt betitelt „Rollout“Das stufenweise Ausrollen einer Feature-Version. Das Rollout-Cockpit visualisiert Beispielszenarien mit Schiebereglern. Siehe Rollout.
Das provider-agnostische Software-Paket, das ein Feature lokal in der Kundenumgebung ausführt. Es lädt den freigegebenen Contract, prüft die Schema-Kompatibilität und meldet Telemetrie zurück, während die Governance zentral auf der Plattform bleibt. Siehe SDK-Überblick.
Eine registrierte, von Features nutzbare Fähigkeit (etwa eine Datenbankabfrage, ein API-Aufruf oder eine Schreiboperation) mit Eingabe-Schema, Ausgabe-Schema, Ansprechpartner und Risiko-Klassifizierung (Read-Only, Mutating, High-Risk-Mutating). Siehe Tools und Tool-Requests.
Tool-Registry
Abschnitt betitelt „Tool-Registry“Der zentrale Katalog aller registrierten Tools. Ein Feature ruft Tools nicht direkt auf, sondern verweist auf Einträge der Registry, sodass nachvollziehbar bleibt, welche Fähigkeit ein Feature in welcher Version nutzt. Siehe Tools und Tool-Requests.
Tool-Request
Abschnitt betitelt „Tool-Request“Eine Anfrage für ein noch nicht freigegebenes Tool. Tool-Requests sammeln sich im gleichnamigen Sidebar-Bereich und werden dort gesichtet und freigegeben. Siehe Tools und Tool-Requests.
Versions-Lebenszyklus
Abschnitt betitelt „Versions-Lebenszyklus“Die Zustände einer Contract-Version: Entwurf (draft) → aktiv (active) → abgelöst (superseded). Nach dem Veröffentlichen ist eine Version schreibgeschützt; Änderungen erfordern einen neuen Draft. Siehe Veröffentlichen.
Die geführte Konversation zum Anlegen und Schärfen eines Features. Statt ein Formular auszufüllen, beantwortet man Fragen, aus denen die Plattform einen ersten Contract-Entwurf ableitet. Siehe Wizard nutzen.
Weiterführend
Abschnitt betitelt „Weiterführend“Die gesamte Oberfläche mit Bereichen, Tabs und Rollen-Sichtbarkeit listet die Oberflächen-Referenz. Den Funktionsstand jedes Bereichs führt der Bau-Stand auf.