Nachweise — Referenzsystem
Gesteuertes Fallbearbeitungssystem
Ein vollständiges operatives System zur Lösung eingehender Fälle: strukturierte und unstrukturierte Aufnahme, ein deterministischer Ablauf rund um gesteuerte KI, konsequenzgesteuerte menschliche Befugnis, und ein vollständiges Prüfprotokoll. Lesen Sie es durch sieben verbundene Ansichten.
Referenzimplementierung
Eine Referenzimplementierung auf einem synthetischen Fallszenario mit synthetischen Daten. Sie ist keine Kundenarbeit und beschreibt keine reale Organisation.
Die Arbeitsoberfläche
Ein Fall, drei Zustände — derselbe gesteuerte Ablauf.
Wechseln Sie zwischen Zuständen, um zu sehen, wie sich ein Fall bewegt: aufgezeichnete Modellbewertung, eine Person mit Befugnis über die folgenreiche Entscheidung, und jeder Schritt im Prüfprotokoll festgehalten. Eine Referenzimplementierung auf synthetischen Daten.
FALL CO-2480
Neubewertung eines Anspruchs — Police 88-4471
- Verantwortlich
- Schadensteam · SLA 2 Tage
- Modellbewertung
- Anspruchsberechtigt · Konfidenz 0,86 Anspruchsberechtigt · Konfidenz 0,86 Unzureichende Nachweise · Konfidenz 0,41
- Quellen
- Police §4.2 · Gutachterbericht · 12 Dokumente
- Befugnis
- Entscheidung mit hoher Auswirkung — eine Person genehmigt
- 14:02:11 Modellbewertung erfasst · Quellen angehängt
- 14:02:11 an menschliche Genehmigung weitergeleitet · hohe Auswirkung
- 14:07:52 genehmigt von A. Rivas · in ERP und CRM ausgeführt
- 14:09:03 an Annahme zurückgegeben · fehlendes Formular angefordert
- 13:51:02 Ausnahme EXC-04 · Bediener benachrichtigt
Ansicht 01 · Führung
Der gesamte Betrieb funktioniert als ein System.
Ein Fall ist eine einzelne Arbeitseinheit: eine strukturierte Anfrage, begleitet von unterstützenden Dokumenten oder Korrespondenz. Ihn gut zu lösen bedeutet, die Dokumente zu lesen, Richtlinien anzuwenden, zu entscheiden, in den Systemen der Aufzeichnung zu handeln, und später genau zeigen zu können, was passiert ist und warum.
Manuell über getrennte Werkzeuge ausgeführt, ist diese Arbeit langsam, inkonsistent und schwer zu prüfen. Das Gesteuerte Fallbearbeitungssystem macht daraus eine deterministische Operation: KI beschleunigt das routinemäßige Lesen und Entwerfen, Menschen bleiben für folgenreiche Entscheidungen verantwortlich, und jeder Schritt wird aufgezeichnet.
-
Durchsatz mit Kontrolle
Routineschritte laufen automatisch innerhalb festgelegter Grenzen; Menschen richten ihre Aufmerksamkeit auf Urteilsvermögen, nicht auf administrative Weiterleitung.
-
Konsistenz
Dieselbe Richtlinie, dasselbe Retrieval und dieselben Prüfungen gelten für jeden Fall, sodass Ergebnisse nicht davon abhängen, wer ihn zufällig übernommen hat.
-
Nachweisbar
Ein nur anfügbares Prüfprotokoll erfasst jeden Akteur, jede Aktion, Zitation und Genehmigung — sodass eine Entscheidung erklärt und verteidigt werden kann.
-
Sichere KI
Das Modell unterstützt innerhalb einer Kontrollgrenze; folgenreiche Aktionen erfordern menschliche Genehmigung. Die Fähigkeit steigt, ohne dass die Befugnis die Konsequenz überholt.
Die obigen Ergebnisse sind auf Designebene. Dieses Referenzsystem berichtet keinen gemessenen Produktionsdurchsatz, keine Genauigkeit oder Kosten — siehe die Ansicht Evaluation.
Ansicht 02 · Operativ
Wie sich ein Fall bewegt.
Jeder Fall folgt demselben deterministischen Pfad. Der Ablauf — nicht das Modell — entscheidet, was als Nächstes passiert; die KI erledigt ihre Arbeit innerhalb eines Zustands, und folgenreiche Fälle halten für einen Menschen an.
Fall-Zustandsmaschine
Textbeschreibung dieses Diagramms
Ein Fall durchläuft sieben benannte Zustände: empfangen (ein strukturiertes Formular plus Belegdokumente), triagiert und weitergeleitet, angereichert mit abgerufener Richtlinie und Kontext, bewertet mit einem KI-generierten Entwurf und Zitaten, eine nach Konsequenz gestufte menschliche Genehmigung, bearbeitet in den Systemen der Aufzeichnung, dann geschlossen und auditiert.
Der Workflow ist deterministisch; die KI unterstützt nur innerhalb des Zustands „bewertet“. Am Freigabe-Gate kann ein Fall mit geringer Konsequenz genehmigt und bearbeitet werden, während ein Fall, der eine Prüfung nicht besteht, zurückgewiesen oder eskaliert wird (der gestrichelte Ausnahmepfad) und wieder bei „angereichert“ eintritt. Jeder Übergang wird im Audit-Trail protokolliert.
Rollen und Übergaben
- Aufnahme- und Ablaufdienste empfangen, sichten, bereichern und leiten weiter — kein menschlicher Aufwand für administrative Schritte.
- Fallbearbeiter prüfen den KI-Entwurf und seine Zitate, korrigieren ihn, und entscheiden über Fälle mittlerer Konsequenz.
- Leitende Genehmiger halten die Befugnis für folgenreiche Aktionen und zeichnen am Genehmigungstor ab.
Ausnahmen und Grenzfälle
- Eine fehlgeschlagene Richtlinienprüfung gibt den Fall zur Anreicherung zurück oder eskaliert ihn, statt fortzufahren.
- Fehlende oder unlesbare Dokumente pausieren den Fall und fordern das Benötigte an — sie erzeugen niemals eine stille Vermutung.
- Die Zeit in einem Zustand wird verfolgt, sodass ein Fall nicht unbemerkt stagnieren kann; überfällige Arbeit taucht bei einem Verantwortlichen auf.
Ansicht 03 · Architektur
Komponenten, Grenzen und Daten.
Ein deterministischer Orchestrator ist das Rückgrat. Er besitzt den Ablauf und ruft gesteuerte Dienste für die Arbeit auf, die sie benötigt, überträgt ihnen aber niemals die Kontrolle. Der Zustand lebt innerhalb einer Falldatengrenze.
Systemarchitektur
Textbeschreibung dieses Diagramms
Ein deterministischer Workflow-Orchestrator steuert jeden Fall. Er ruft drei gesteuerte Dienste auf — Retrieval (Richtlinie und vorheriger Kontext), ein Modell-Gateway (den KI-Entwurf) und eine Richtlinien- und Regel-Engine — übergibt ihnen aber niemals die Kontrolle. Fälle und Dokumente sowie ein Append-only-Audit-Log leben innerhalb einer Falldaten-Grenze; der Orchestrator liest und schreibt dort unter geringsten Rechten.
Aktionen erreichen die Systeme der Aufzeichnung der Organisation nur über Integrationsadapter, sodass die Grenze und das Audit-Log jede Änderung immer zuerst sehen. Observability — Protokolle, Metriken und Spuren — erstreckt sich über das gesamte System und wird in der Evaluationsansicht beschrieben.
Komponenten
- Orchestrator — die deterministische Ablauf-Engine; die einzige Komponente, die einen Fall vorantreibt.
- Retrieval — ruft die Richtlinie und den vorherigen Kontext ab, den ein Fall benötigt, mit Herkunftsnachweis.
- Modell-Gateway — der einzige, beobachtbare Pfad zum KI-Modell; erzwingt Grenzen und Protokollierung.
- Richtlinien & Regeln — deterministische Prüfungen, die der Entwurf bestehen muss.
- Integrationsadapter — der einzige Weg, auf dem Aktionen die Systeme der Aufzeichnung erreichen.
Datengrenzen
- Fälle, Dokumente und ein nur anfügbares Prüfprotokoll leben innerhalb einer Grenze; der Zugriff erfolgt nach dem Prinzip der geringsten Berechtigung.
- Das Modell-Gateway sendet nur den minimal benötigten Kontext und zeichnet auf, was gesendet wurde.
- Nichts erreicht ein System der Aufzeichnung außer über einen Adapter, den die Grenze sehen kann.
Die folgenreichen Entscheidungen sind im Architektur-Entscheidungsprotokoll festgehalten.
Ansicht 04 · Kontrolle & Risiko
Befugnis, Berechtigungen und Audit.
Kontrolle wird von Anfang an konzipiert, nicht nachträglich hinzugefügt. Die Befugnis zum Handeln wird proportional zur Konsequenz der Aktion gewährt, Berechtigungen sind nach Rolle eingeschränkt, und jeder Schritt wird aufgezeichnet.
Befugnis proportional zur Konsequenz
Textbeschreibung dieses Diagramms
Befugnis wird proportional zur Konsequenz der Handlung gewährt. Schritte mit geringer Konsequenz laufen automatisch innerhalb expliziter Grenzen. Arbeit mit mittlerer Konsequenz wird von einem Fallbearbeiter mit KI-Unterstützung entschieden. Aktionen mit hoher Konsequenz erfordern einen Senior-Genehmiger.
Dies ist das menschliche Befugnismodell hinter dem Freigabe-Gate in der Zustandsmaschine. Daneben sind Datenberechtigungen nach Rolle eingegrenzt: Jeder Akteur — Mensch oder Dienst — sieht nur die Falldaten, die seine Rolle benötigt.
Berechtigungen und Grenzen
- Rollen tragen nur die Berechtigungen, die sie benötigen; ein Fallbearbeiter kann keine folgenreiche Aktion genehmigen.
- Dienste laufen nach dem Prinzip der geringsten Berechtigung — das Modell-Gateway kann nicht in ein System der Aufzeichnung schreiben.
- Jeder Akteur sieht nur die Falldaten, die seine Rolle erfordert.
Die Bedrohungen und Minderungen sind in der Bedrohungs-, Evaluations- und Abnahmespezifikation dargelegt.
Audit
Das Prüfprotokoll ist nur anfügbar und erfasst jeden Akteur, jede Aktion und Zitation. Ein Auszug für einen Fall:
| Zeit | Akteur | Rolle | Ereignis |
|---|---|---|---|
| 09:02:11 | Intake | Dienst | Fall CASE-4837 empfangen — Antragsformular + 2 Dokumente |
| 09:02:12 | Workflow | Dienst | Triagiert: Typ=Anspruch, Priorität=Standard, Warteschlange=A |
| 09:03:04 | Retrieval | Dienst | Richtlinienabschnitte P-12, P-19 abgerufen |
| 09:03:05 | Model gateway | Dienst | Bewertungsentwurf erstellt (3 Zitate) |
| 09:03:06 | Policy engine | Dienst | Regel R-07 bestanden; R-11 zur Prüfung markiert |
| 09:05:22 | u_214 | Fallbearbeiter | Entwurf bearbeitet; Genehmigung angefordert |
| 09:07:40 | u_038 | Senior-Genehmiger | Mit Bedingung genehmigt |
| 09:07:41 | Integration | Dienst | Aktion im System der Aufzeichnung erfasst (SOR-99213) |
| 09:07:41 | Workflow | Dienst | Fall geschlossen; Audit-Eintrag versiegelt |
Ansicht 05 · Evaluation
Wie es gemessen und abgenommen wird.
Ein System wie dieses ist nur vertrauenswürdig, wenn es gemessen und an einem Standard gehalten werden kann. Evaluation ist kontinuierlich: ein Build wird gemessen, muss ein Abnahmetor passieren, und läuft dann unter Überwachung, während Ergebnisse zurückfließen.
Evaluationsschleife
Textbeschreibung dieses Diagramms
Evaluation ist eine Schleife, keine einmalige Abzeichnung. Ein Build wird gegen definierte Datensätze und Metriken gemessen und muss dann ein Abnahme-Gate bestehen, dessen Schwellenwerte vorab festgelegt sind. Erst dann läuft er im Betrieb — unter Überwachung, die Qualität, Kosten, Latenz und menschliche Übersteuerungen beobachtet.
Operative Ergebnisse fließen in die nächste Verbesserung zurück, und das geänderte System wird vor der Abnahme erneut evaluiert. Die Datensätze, Metriken und Schwellenwerte sind in der Bedrohungs-, Evaluations- und Abnahmespezifikation festgelegt.
Was gemessen wird
- Extraktionsgenauigkeit — liest das System die Dokumente korrekt?
- Fundiertheit — wird jede KI-Behauptung durch ein abgerufenes Zitat gestützt?
- Präzision und Recall der Richtlinienprüfung — werden die richtigen Fälle markiert?
- Menschliche Übersteuerungsrate — wie oft korrigieren Bearbeiter den Entwurf?
- Eskalationskorrektheit — erreichen folgenreiche Fälle einen Menschen?
- Latenz und Kosten pro Fall — ist es bei Volumen betreibbar?
Abnahme und Wiederherstellung
- Schwellenwerte für jede Metrik werden vor der Abnahme eines Builds festgelegt; ein Build, der sie verfehlt, wird nicht bereitgestellt.
- Überwachung beobachtet dieselben Metriken im Betrieb; Drift löst eine Prüfung aus.
- Fehlerbehandlung ist explizit: Wiederholungen mit Backoff, Dead-Lettering für giftige Fälle, und ein dokumentierter Wiederherstellungspfad.
Gemessene Ergebnisse werden nicht veröffentlicht. Diese Ansicht definiert die Datensätze, Metriken und Schwellenwerte, nach denen das System evaluiert und abgenommen würde — sie behauptet keine Produktionszahlen, und eine unabhängige Prüfung durch leitende Personen wurde noch nicht durchgeführt.
Ansicht 06 · Fehler & Wiederherstellung
Was passiert, wenn ein Schritt fehlschlägt.
Die Ansicht Operativ zeigte den Normalpfad und seine Ausnahmen; die Ansicht Evaluation nannte Wiederherstellung als Abnahmeanforderung. Diese Ansicht ist diese Anforderung, dargestellt: eine fehlgeschlagene Aktion wird wiederholt, dann eingedämmt, dann wiederhergestellt — niemals stillschweigend verloren, und niemals in der Lage, den Fall zu beschädigen.
Fehler und Wiederherstellung
Textbeschreibung dieses Diagramms
Jede Aktion wird idempotent versucht, sodass sie entweder genau einmal committet wird oder gar nicht committet wird. Eine fehlgeschlagene Aktion blockiert den Betrieb nicht:
- Sie wird mit Backoff erneut versucht, bis zu einer begrenzten Anzahl von Versuchen.
- Schlägt sie weiterhin fehl, wird sie in die Dead-Letter-Warteschlange verschoben — sicher aufbewahrt, niemals stillschweigend verworfen.
- Ein Bediener prüft den Dead-Letter, behebt die Ursache und wiederholt ihn.
- Da die Aktion idempotent ist, kann die Wiederholung die Wirkung nicht doppelt anwenden.
Der gesamte Pfad bleibt innerhalb einer Eindämmungsgrenze: Ein Fehler kann den Fallzustand nicht beschädigen, und jeder Versuch, Fehler und jede Wiederholung wird in das Audit-Log geschrieben.
Behandelte Fehlermodi
- Ein vorübergehender nachgeschalteter Fehler wird mit begrenztem Backoff wiederholt.
- Ein anhaltender Fehler wird dead-lettered, nicht verworfen, sodass kein Fall verschwindet.
- Eine giftige Nutzlast kann nicht endlos schleifen; sie landet im Dead-Letter für einen Menschen.
- Eine doppelte Einreichung löst sich zu einem einzigen festgeschriebenen Effekt auf (Idempotenz).
Wiederherstellungsgarantien
- Jeder Versuch, Fehler und Replay wird in das nur anfügbare Prüfprotokoll geschrieben.
- Ein Betreiber kann einen Dead-Letter untersuchen, die Ursache beheben, und ihn erneut abspielen.
- Replay kann nicht doppelt angewendet werden, daher ist Wiederherstellung sicher auszuführen.
Ansicht 07 · Bereitstellung & Eigentümerschaft
Wo es läuft, und wer es besitzt.
Die Ansicht Kontrolle etablierte die Grenze, innerhalb der das System läuft. Diese Ansicht beantwortet, wessen Grenze das ist: Ihre. Das System wird in eine Umgebung bereitgestellt, die Sie kontrollieren, und die Eigentümerschaft wird übertragen statt gemietet.
Einsatz und Eigentümerschaft
Textbeschreibung dieses Diagramms
Das System wird in einer Umgebung eingesetzt, die Sie kontrollieren — Ihr Cloud-Konto, auf Infrastruktur, die Sie besitzen oder der Sie zustimmen — keine von SageTensor gehostete Black Box.
Eigentum wird übertragen, nicht gemietet. Sie erhalten den Quellcode und die Infrastructure-as-Code, die Runbooks und Evaluationssätze, und die Append-only-Audit-Historie. SageTensor baut das System und übergibt es; es betreibt das System nur so lange, wie Sie es wählen, und Sie können es unabhängig betreiben, ändern und auditieren.
Wo es läuft
- In Ihrem Cloud-Konto, auf Infrastruktur, die Sie besitzen oder der Sie zustimmen — keine gehostete Blackbox.
- Innerhalb der Kontrollgrenze der Ansicht Kontrolle & Risiko, nach dem Prinzip der geringsten Berechtigung.
- Reproduzierbar, aus Infrastructure-as-Code, sodass eine Umgebung neu aufgebaut werden kann.
Was Sie erhalten
- Den Quellcode und die Infrastructure-as-Code für das gesamte System.
- Runbooks und die Evaluationssätze, damit Sie es betreiben und erneut testen können.
- Die nur anfügbare Prüfhistorie — es ist Ihr Datenbestand, nicht unserer.
Wie ein Engagement dies aufbaut und überträgt, ist Gegenstand von Delivery, und was Sie besitzen, ist in Unternehmenskontrolle festgelegt.
Was dies beweist und was nicht
Es zeigt
- Dass SageTensor den gesamten Betrieb — Intake, Workflow, Entscheidungsbefugnis, Kontrollen, Audit, Wiederherstellung und Eigentümerschaft — als ein System entwirft.
- Dass KI innerhalb eines deterministischen Workflows mit expliziter menschlicher Befugnis eingesetzt wird, nie unbeaufsichtigt handeln darf.
- Dass Kontrolle, Evaluation und Fehlerbehandlung von Anfang an mitgedacht werden, nicht nachträglich ergänzt.
Es zeigt nicht
- Keine konkrete Zahl zu Produktionsleistung, Kosten oder Genauigkeit.
- Keine Eignung für eine bestimmte Organisation ohne deren eigenes Mandat und eigene Evaluation.
- Kein Kundenergebnis — es wird kein realer Betrieb dargestellt.
Wie man es prüft
Lesen Sie es über sieben verbundene Ansichten — Executive, operativ, Architektur, Kontrolle und Risiko, Evaluation, Fehler und Wiederherstellung, Einsatz und Eigentümerschaft — jede als semantisches HTML verfügbar. Das Architekturprotokoll und die Bedrohungs-/Evaluations-/Abnahmespezifikation werden als ausgefüllte Artefakte veröffentlicht.
Beauftragung
Beginnen Sie mit dem, was sich ändern muss.
So gestaltet SageTensor einen ganzen Betrieb. Eine Mandatsdefinition beginnt dieselbe Arbeit für Ihren.
Alternativ können Sie eine Ausschreibung einreichen, oder zuerst eine NDA anfordern.