Was kann die KI?
Fähigkeit ist allgemein und unabhängig vom konkreten Auftrag.
AA570 · GOVERNANCE & EXECUTION DOCTRINE
Kontrollierte Ausführung,
Kontrollierte Ausführung,
nachweisbar abgenommen.
AA570 legt fest, was KI in einer kontrollierten Umgebung tun darf — und wie Ergebnisse geprüft und freigegeben werden. Es ist keine Bibliothek und kein JSON-Schema, sondern eine Doktrin: Regeln, Grenzen und Nachweise für den gesamten Ablauf.
WARUM ES DAS GIBT
Kontrolle statt Vertrauen
Generische KI-Codierung arbeitet auf Zuruf: Ein Modell verändert Dateien, und erst danach wird geprüft, ob das Ergebnis stimmt. AA570 dreht diese Reihenfolge um — Ausführung ist eingerahmt, begrenzt und wird gegen Nachweise abgenommen.
Die Doktrin beschreibt nicht, wie man ein Werkzeug benutzt, sondern unter welchen Bedingungen eine KI überhaupt handeln darf. Sie gilt für jeden Durchlauf und endet nicht mit der technischen Fertigstellung.
- NO_SILENT_COMPROMISES
- Ability ≠ Authority
- Bounded Scope
- Verify before mutate
- Mutation accounting
- Evidence-driven acceptance
- UNKNOWN = NOT_PROVEN = FAIL_CLOSED
- Execution ≠ Acceptance
Prinzipien im Überblick — die folgenden Kapitel führen sie im Detail aus.
MERKMALE
Was AA570 bereitstellt
AA570 ist kein einzelnes Werkzeug, sondern ein Satz von Regeln, Formen und Nachweisen. Diese Merkmale bilden zusammen den kontrollierten Rahmen für KI-gestützte Arbeit.
-
Doctrine Sync
Synchronisiert den gültigen Governance-Kontext schreibgeschützt über MCP — statt sich auf alten Chat-Kontext oder manuelle Übergaben zu verlassen.
-
AA570F / AA570D
Zwei Arbeitsauftrags-Formen zur Auswahl: AA570F für mehrstufige, fraktal zerlegbare Vorhaben, AA570D für klar umrissene Einzelaufträge.
-
JSON_RESTRICTED + FRACTAL_LITE
Der Auftrag läuft in einem eingeschränkten, maschinenlesbaren Format. Fraktale Zerlegung leitet aus dem Wurzelziel konkrete, begrenzte Teilaufträge ab.
-
Explicit Authority + Bounded Scope
Autorität wird pro Auftrag ausdrücklich erteilt und begrenzt. Fähigkeit begründet keine Erlaubnis.
-
Verification & Acceptance + Phase Convergence
Ergebnisse werden gegen Nachweise geprüft; Phasen laufen mit begrenzten Korrekturzyklen auf einen konvergenten Stand zu.
-
Stop Conditions + FAIL_CLOSED
Definierte Bedingungen stoppen die Arbeit. Unbekanntes gilt als nicht bewiesen und wird fail-closed behandelt.
-
NO_SILENT_COMPROMISES
Anforderungen werden nicht stillschweigend abgeschwächt — Abweichungen müssen ausdrücklich benannt werden.
-
Execution ≠ Acceptance
Fertigstellung und Freigabe bleiben getrennte Schritte.
KONTROLLMODELL
Arbeitsaufträge sind das Kontrollmodell
Nicht der Prompt steuert die Arbeit, sondern der Arbeitsauftrag. Er macht Ziel, Grenzen, Authority, Vorgehensweise, Verifikation, Stop-Bedingungen und Abnahme ausdrücklich.
Ein Prompt beschreibt eine Absicht. Ein Arbeitsauftrag beschreibt, unter welchen Bedingungen diese Absicht umgesetzt werden darf — und woran das Ergebnis gemessen wird.
JSON ist dabei nur die Form. Der Arbeitsauftrag ist das Kontrollmodell: Er legt fest, was gilt, bevor irgendetwas ausgeführt wird. Nichts davon bleibt implizit oder wird stillschweigend angenommen.
-
Klares Ziel
Die KI weiß, worauf die Arbeit einzahlt — und worauf ausdrücklich nicht.
-
Klare Grenzen
Scope und Nicht-Scope sind benannt, statt stillschweigend vorausgesetzt.
-
Prüfbare Ergebnisse
Ergebnisse kommen mit Nachweisen, die unabhängig geprüft werden können.
-
Reproduzierbare Arbeit
Ein identischer Auftrag führt zu nachvollziehbaren, wiederholbaren Schritten.
Was darf sie in diesem Auftrag tatsächlich tun?
Autorität wird pro Auftrag ausdrücklich erteilt und begrenzt.
Ability ≠ Authority
„Mach bitte X"
Kurz, offen und mehrdeutig. Grenzen, Authority und Abnahme bleiben unbestimmt.
- Ziel
- Kontext
- Grenzen
- Authority
- Vorgehensweise
- Verifikation
- Stop-Bedingungen
- Abnahme
kontrollierbare Umsetzung
Je leistungsfähiger KI-Systeme werden, desto wichtiger wird die Qualität des Arbeitsauftrags.
AA570 treats the work order as the interface between human intent and machine execution.
KAPITEL 01 · WHY
Warum
Was AA570 von gewöhnlicher KI-Nutzung unterscheidet.
KI kann viel — aber Fähigkeit ist keine Berechtigung. Ohne Rahmen entsteht Arbeit, die schnell aussieht, aber nicht belegbar ist.
AA570 beantwortet die Frage, die vor jeder Ausführung stehen muss: Was genau darf hier geschehen, in welchem Umfang, und woran wird das Ergebnis gemessen?
- Kontrolliert statt automatisiert Die KI beschleunigt Analyse und Umsetzung — Entscheidungen bleiben beim Menschen.
- Abnahme als eigener Schritt Fertigstellung und Freigabe sind getrennt.
- Nachweis vor Fortschritt Ohne Evidenz wird nicht weitergemacht.
KAPITEL 02 · CONTROL
Kontrolle
Wer darf was — und in welchem Umfang.
Jeder Auftrag hat einen klar begrenzten Umfang. Was nicht im Auftrag steht, wird nicht getan. Rollen erhalten nur die Rechte, die sie für ihre Aufgabe brauchen.
Autorisierung ist immer menschlich und immer explizit. Die Doktrin unterscheidet strikt zwischen dem, wozu ein System fähig wäre, und dem, wozu es berechtigt ist.
- Ability ≠ Authority Können begründet keine Erlaubnis.
- Bounded Scope Begrenzter Umfang, definierte Grenzen.
- Least Privilege Nur die Rechte, die der Auftrag verlangt.
KAPITEL 03 · REALITY CHECK
Realitätscheck
Was tatsächlich belegt ist — und was nicht.
Ein häufiges Muster ist die Verwechslung von Annahme und Nachweis. AA570 behandelt Unbekanntes nicht als wahrscheinlich, sondern als ungeprüft.
Diese Haltung ist bewusst konservativ. Sie verhindert, dass sich ungeprüfte Behauptungen als Ergebnis ausgeben. Es werden keine Benchmark-, Durchsatz- oder Latenzzahlen behauptet, solange sie nicht belegt sind.
- UNKNOWN = NOT_PROVEN = FAIL_CLOSED Unbekannt gilt als nicht bewiesen und wird fail-closed behandelt.
- Abstraktion statt Interna Öffentlich sind Rollen und Strukturen — nicht interne Details.
- Keine erfundenen Zahlen Leistung wird nicht mit nicht belegten Werten beworben.
KAPITEL 04 · EXECUTION
Ausführung
Wie kontrolliert gehandelt wird.
Vor jeder Veränderung steht die Prüfung des aktuellen Zustands. Erst wenn der Ist-Zustand verstanden ist, wird ausgeführt — und jede Veränderung wird verbucht.
Ausführung geschieht innerhalb des beauftragten Umfangs. Abweichungen vom Auftrag sind kein Detail, sondern ein Abbruchgrund.
- Verify before mutate Erst prüfen, dann verändern.
- Mutation accounting Jede Änderung wird nachvollziehbar erfasst.
- Bindungen statt Annahmen Gearbeitet wird gegen den realen Stand, nicht gegen eine Erinnerung.
KAPITEL 05 · VERIFY
Verifikation
Wie Ergebnisse geprüft und abgenommen werden.
Verifikation stützt sich auf nachweisbare Ergebnisse. Ein abgeschlossener Auftrag ist ein Kandidat für die Abnahme — nicht die Abnahme selbst.
Ausführung und Abnahme sind getrennte Schritte, ausgeführt von getrennten Rollen. Wo Gleichwertigkeit behauptet wird, muss sie belegt werden.
- Evidence-driven acceptance Abnahme braucht belastbare Evidenz.
- Execution ≠ Acceptance Fertig bedeutet nicht freigegeben.
- Proven equivalence Gleichwertigkeit wird nachgewiesen, nicht angenommen.
KAPITEL 06 · BOUNDARIES
Grenzen
Wo bewusst gestoppt wird.
Grenzen sind keine Schwäche, sondern Teil des Designs. An definierten Punkten hält das System an und verlangt eine menschliche Entscheidung, statt weiterzulaufen.
Der Umgang mit Abweichungen ist explizit: Sie werden benannt. Stilles Aufweichen von Anforderungen ist ausgeschlossen.
- Fail-closed Im Zweifel wird gestoppt.
- NO_SILENT_COMPROMISES Anforderungen werden nicht stillschweigend abgeschwächt.
- Explizite Ausnahme Ausnahmen werden ausdrücklich benannt und begründet.
MCP
Synchronisierter Governance-Kontext
Der gültige Doktrin- und Autoritätsstand wird über eine schreibgeschützte MCP-Schnittstelle synchronisiert, statt aus altem Chat-Kontext übernommen zu werden.
ChatGPT und OpenWebUI können den aktuellen Governance-Kontext von AA570 über eine schreibgeschützte MCP-Schnittstelle synchronisieren — statt sich auf alten Chat-Kontext oder manuelle Übergaben zu verlassen.
Die Synchronisation identifiziert, liest und verifiziert den gültigen Doktrin- und Autoritätsstand, bevor daraus ein Arbeitsauftrag entsteht.
-
Kein Doctrine Drift zwischen Chats.
-
Kein manuelles Mitschleppen alter Regel-Kontexte.
-
Der aktuelle Doktrin- und Autoritätsstand ist identifizierbar.
-
Relevante Autoritätsdokumente sind bestimmbar.
-
Hash-basierte Frische- und Integritätsprüfungen erkennen Änderungen.
-
Unklarer Zustand schlägt fail-closed fehl, statt still veraltete Annahmen zu nutzen.
Synchronisation ist keine Ausführungsfreigabe.
Doctrine Sync identifiziert, liest und verifiziert Governance-Kontext. Die Synchronisation selbst erteilt keine Ausführungsautorität.
Bewusste Grenze der Veröffentlichung
Diese Seite beschreibt das Modell und seine Regeln. Interne Pfade, Kennungen, Zugänge, Endpunkte und Infrastruktur-Details bleiben bewusst nicht öffentlich.
Weiter im System
AA570 ist der Governance-Rahmen von 3.3C-R2. Das Zusammenspiel der Komponenten zeigt die Systemübersicht.