Welles Decision Architecture
Menschen und KI-Systeme können Empfehlungen geben, Entscheidungen vorbereiten und Aktionen auslösen. Welles Decision Architecture legt fest, auf welcher Grundlage daraus eine zulässige und tragfähige Verpflichtung werden darf.
Wir liefern die Entscheidungs- und Kontrollarchitektur. Wir bauen keine Agenten. Ihre IT oder ein Umsetzungspartner verbindet die Regeln mit den vorhandenen Systemen und weist ihre technische Durchsetzung nach.
DECIDE · GOVERN · CARRY
DECIDE
CEO Decision Architect
Die Unternehmenslage wird auf die konkrete Last, Ursachen und verschobenen Entscheidungen geprüft. Daraus entstehen eine Entscheidungsfrage, ernsthafte Optionen und wirtschaftliche Konsequenzen. Beobachtung, Hypothese und Schlussfolgerung bleiben unterscheidbar.
GOVERN
TOOD 3
Evidenz, Mandat, Verpflichtungen und kumulierte Wirkung werden vor der Ausführung geprüft. Die Regeln bestimmen, wann gehandelt werden darf und wann Nachweise, menschliche Freigabe, Eskalation oder Stop erforderlich sind. Technische Fähigkeit ist kein Mandat.
CARRY
SOA LUMEN
Wer übernimmt die Arbeit und die Folgen tatsächlich? SOA LUMEN prüft Last, Mandat, Entscheidungsrechte, Kompetenz, Ressourcen, Schnittstellen und verdrängte Arbeit. Eine formale Freigabe schafft noch keine verfügbare Kapazität.
Das Ergebnis ist eine prüfbare Entscheidung mit Grenzen und zugeordneter Verantwortung. Offene Voraussetzungen bleiben sichtbar; eine plausible Empfehlung ersetzt keine Freigabe.
Agent Decision Boundary
Was ist belegt, was angenommen, was offen oder veraltet?
Welche Rolle darf welche Wirkung bis zu welcher Grenze auslösen?
Welche Zusagen, Kosten oder Leistungen entstehen zusammen mit bestehenden Bindungen?
Wer entscheidet bei Ausnahmen, mit welchen Rechten und welcher tatsächlich verfügbaren Zeit?
Wann bleibt eine Aktion angehalten, wer klärt die Lücke und welche Bedingung erlaubt den Wiederanlauf?
Was wurde geprüft, freigegeben und ausgeführt? Welche Wirkung ist danach tatsächlich eingetreten?
Illustratives Beispiel · Einkauf
Ein Einkaufsagent löst mehrere einzeln zulässige Bestellungen aus. Zusammen binden sie mehr Budget, als sein Mandat erlaubt. Gleichzeitig soll eine Führungskraft alle Ausnahmen freigeben, obwohl ihre Kapazität bereits durch andere Aufgaben gebunden ist.
DECIDE klärt Beschaffungsbedarf und Alternativen. TOOD 3 prüft die neue Verpflichtung zusammen mit bestehenden Bindungen und den Freigaberechten. SOA LUMEN prüft, wer Ausnahmen tatsächlich bearbeiten kann und welche andere Arbeit dafür entfällt. Fehlt eine Voraussetzung, bleibt sie als offene Bedingung dokumentiert.
Das Beispiel erläutert den Prüfweg; es beschreibt keine nachgewiesene Kundenintegration.
Entwicklungsstand
Aktueller Stand
TOOD 3 liegt als Referenzarchitektur mit lokal geprüfter Implementierung vor. Dieser Stand bezieht sich auf den lokalen Prüfrahmen. Er belegt keine vollständige Integration in Ihre Systeme und keine Freigabe für deren produktiven Einsatz.
Nächster Nachweis im konkreten Einsatz
Mit der Unternehmens-IT sind Datenzugriff, Identitäten, Mandate und Schnittstellen zu verbinden. Tests müssen zeigen, dass Freigaben, Eskalation und Stop auch bei Fehlern und geänderten Voraussetzungen greifen. Danach werden Betrieb, Verantwortliche und Freigabeumfang ausdrücklich festgelegt.
Ein lokal bestandener Test ersetzt weder den Integrationsnachweis noch eine betriebliche Freigabe. Der Controlled Decision Pilot liefert Befunde und offene Bedingungen für die nächste Entscheidung; technische Integration ist gesondert zu beauftragen.
Mit einem konkreten Fall beginnen
Ein Review klärt die Entscheidungsgrenze. Ein Pilot prüft die Regeln an 10–20 Fällen. Umfang, interne Mitwirkung und Ergebnis stehen vor dem Start fest.
Angebote und Festpreise ansehen