IRONSTICK← Startseite

IRONSTICK — Die Desktop-KI-Bridge

Eine lokale Bridge, vier Desktop-KIs gleichwertig — Claude Desktop / Claude Code, ChatGPT Desktop, Qwen Desktop und Kimi Desktop — plus der integrierte IRONSTICK-KI-Chat. Was die Bridge ist, wie sie lizenziert wird, wie sie zum In-App-Chat steht, wie man sie installiert, wie jeder Zugriff angezeigt wird, was man damit tun kann — und der vollständige Katalog der 175 Werkzeuge. Windows-Ausgabe.

1. Was die Bridge ist

Die Bridge verbindet Ihre eigene Desktop-KI — Claude Desktop (oder Claude Code), ChatGPT Desktop, Qwen Desktop oder Kimi Desktop — mit der laufenden IRONSTICK-Anwendung auf demselben Rechner. Die KI kann Ihr Fallmaterial dann über eigens gebaute Werkzeuge lesen — Chroniken, Dokument- Volltexte, E-Mails, Fristen, Stammdaten — und in voller Tiefe damit arbeiten: analysieren, gegenprüfen, entwerfen. Die Verbindung ist strikt lokal (127.0.0.1); kein IRONSTICK-Server ist beteiligt. Die Daten, die die KI liest, werden unter Ihrem eigenen Abo bei diesem Anbieter und dessen Bedingungen verarbeitet — die vollständige Darstellung steht in der DSGVO-Datenfluss-Erklärung.

• Setzt die jeweilige Desktop-Anwendung mit dem eigenen Konto voraus (Anthropic, OpenAI, Qwen oder Kimi).
• Funktioniert nur, solange IRONSTICK läuft — schließt man die App, schließt sich die Datenquelle.
• Dieser Kanal überträgt bewusst echte, nicht pseudonymisierte Daten — genau das macht das Entwerfen einreichungsfähiger Vorlagen möglich.
• Als geheim markierte Dokumente sind für die Bridge unsichtbar.
• Das chatübergreifende KI-Gedächtnis ist für lange Verfahren gebaut: Einträge an einem aktiven Fall verfallen nie, und jede Nutzung frischt ihre Lebensdauer auf — nur totes Material altert nach einem Jahr aus.
• Der Schreibzugriff ist bewusst schmal: Vorschläge landen im Datenkonsistenz- Monitor zu Ihrer Prüfung; Entwürfe werden in die Textverarbeitung übergeben; nichts wird direkt in Ihre Datensätze geschrieben.

1b. Warum die Bridge?

Weil das Arbeiten über ein Abo meist um ein Vielfaches günstiger ist als über die API. Eine Desktop-KI läuft auf dem Pauschal-Abo, das Sie beim Anbieter ohnehin haben; jeder Dialog, jeder Volltext-Lesevorgang, jede Entwurfsrunde ist davon gedeckt. Dieselbe Arbeit über den IRONSTICK-In-App-Chat läuft auf Ihrem API-Schlüssel und wird pro Token abgerechnet — bei langen Dialogen über große Akten summiert sich das schnell.

Wo die Bridge glänzt, ist der Preis: sie ist ein massiver Kostensenker für KI-Dialoge und das Mittel der Wahl, wann immer Dokumente oder größere Datenbestände über die KI gepflegt werden — ganze Akten lesen, Chroniken, Protokolle und Gedächtnis aktuell halten, Hunderte Beilagen durcharbeiten — Arbeit, die Token für Token unbezahlbar teuer wäre.

1c. Lizenzierung — vier Bridges oder das Bundle

Jeder Desktop-KI-Zugang ist ein eigenes lizenziertes Zusatzmodul:

• Die Verfügbarkeit steckt in Ihrem signierten Lizenzschlüssel: nur die lizenzierten Bridges entstehen überhaupt — eine nicht lizenzierte hat kein Front-End, keine Werkzeugoberfläche und erscheint nicht in der Konfiguration.
• Sie lizenzieren eine einzelne Bridge (nur die Desktop-KI, die Sie nutzen) oder das Bundle aller vier — später erweiterbar.
• Lizenzierte Bridges dürfen parallel laufen; ein Fall kann von mehreren Desktop-KIs zugleich bearbeitet werden.

1d. Der integrierte IRONSTICK-KI-Chat — dasselbe Modell, plus Gemini, ohne Extra-Lizenz

IRONSTICK hat auch einen eigenen KI-Chat integriert, und er läuft auf exakt derselben Arbeitsebene wie die Bridge — dieselben Werkzeuge, dieselben Tore, dieselbe Verankerung und dasselbe einreichungsfähige Entwerfen. Was die Bridge kann, kann der In-App-Chat auch. Über die vier Bridge-Anbieter hinaus bietet er zusätzlich Gemini von Google als Anbieter.

• Keine Extra-Lizenz. Der In-App-Chat ist in IRONSTICK integriert; er braucht kein weiteres Bridge-Modul.
• Er läuft über die API der Anbieter (Ihr eigener API-Schlüssel), pro Token abgerechnet. Da API-Tarife etwas höher sind als ein Pauschal-Abo, kann der In-App-Chat im täglichen Gebrauch teurer sein als die Nutzung der Bridge zusammen mit der Desktop-App des Anbieters — wo das Abo-Modell weitaus günstiger ist.
• Im Gegenzug ist der API-Weg über IRONSTICK stärker überwacht und steuerbar: vom Router pseudonymisiert, Zustimmungsdialog, Audit-Log und Größenkappen — an denselben Toren wie die Bridge.

2. Installation (jede der vier)

Der Ablauf ist für jede Desktop-KI gleich; nur Bezugsquelle und Einrichten-Schaltfläche unterscheiden sich.

1. Die Desktop-Anwendung installieren, mit dem eigenen Konto anmelden und einmal starten (siehe Anbieterzeile unten).
2. In IRONSTICK Konfiguration → KI-Konfiguration → KI mit lokalem MCP-Server (STDIO) öffnen.
3. „Konnektorzugriff durch lokale Desktop-KI erlauben" EIN schalten (der Hauptschalter des ganzen Kanals).
4. Optional „Navigation durch die Desktop-KI erlauben" EIN, wenn die KI die App auch steuern darf — Bildschirme, Fälle und Dokumente öffnen, Dateien exportieren. Lesen geht auch ohne.
5. Die passende „… Desktop einrichten"-Schaltfläche klicken. IRONSTICK rollt seine eigene Bridge-Instanz aus und trägt sie selbst in die Desktop-KI ein — nichts einzufügen, nichts zu tippen.
6. Eine neue Unterhaltung starten (oder in derselben Sektion „Desktop-KI neu starten" klicken). IRONSTICK erscheint dann unter den Konnektoren der KI, und die Werkzeuge unten stehen in jeder Unterhaltung bereit.

Der Konfigurations-Bildschirm trägt die Download-Links und die Links zu Nutzungsbedingungen und Datenschutzerklärung jedes Anbieters.

3. Wie Zugriffe in der Menüleiste angezeigt werden

• Erst Zustimmung. Wenn eine Desktop-KI im Programmlauf zum ersten Mal Daten berührt, zeigt IRONSTICK einen blockierenden Bestätigungsdialog. Ablehnen sperrt diesen Kanal 10 Minuten; Zustimmen öffnet ihn für den Rest des Programmlaufs.
• Ein KI-eigenes Logo erscheint in der Kopfleiste neben der CPU/RAM- Anzeige bei jedem einzelnen Werkzeugaufruf und bleibt 3 Sekunden nach dem letzten Aufruf hell — rasche Aufrufserien halten es durchgehend hell. Ist das Symbol dunkel, wird gerade nichts gelesen. Jede KI hat ihr eigenes Zeichen: der orange Claude-Stern, der grüne OpenAI-Knoten, das violette Qwen-Chatsymbol, das petrolfarbene Kimi-„K".



• Das Dropdown am KI-Symbol zeigt, was diese KI in der Sitzung gelesen hat: die Zeile „Arbeitsanweisung + Halluzinationsverbot" (grüner Haken solange gültig, rotes Kreuz nach Ablauf), dann je Fall die Marken Profil, Rechtsraum und Digest plus einen Balken „Dokumente gelesen r von n".
• Das Gehirnsymbol erscheint, sobald das geteilte KI-Gedächtnis Einträge hat, und pulsiert 3 Sekunden, wann immer ein KI-Kanal es liest oder schreibt. Ein Klick öffnet den Verwaltungsdialog; die KI selbst kann Gedächtnis nie löschen.
• Navigation durch die KI (Bildschirme/Fälle/Dokumente öffnen) geschieht nur, wenn ihr Schalter EIN ist — sonst werden Navigations-Werkzeuge verweigert.
• Parallelzugriff: arbeiten mehrere lizenzierte KIs gleichzeitig, zeigt die Kopfleiste ein pulsierendes Logo je aktiver KI nebeneinander; jeder Zugriff wird immer der KI zugeordnet, die ihn gemacht hat.

4. Was Sie damit tun — Beispiele

Sprechen Sie mit der Desktop-KI (oder dem In-App-Chat) in normaler Sprache; sie wählt die passenden Werkzeuge selbst. Typische Anfragen:

5. Datennotiz

6. Technische Referenz

Es folgen die Übersicht der Tore, der vollständige Katalog der 175 Werkzeuge, die Abschnitte zu Sorgfaltswächtern und Prüflauf sowie die technische Beschreibung. Die Werkzeugnamen sind englische Bezeichner — genau so, wie die KI sie sieht.

4. Die sechzehn deterministischen Halluzinations- & Sicherheits-Tore

IRONSTICK versucht nicht, die verbundene KI mit Prompts zu erziehen — es erzwingt Korrektheit strukturell. Sechzehn deterministische Tore (reine Logik, nirgends eine KI) stehen zwischen dem Modell und Ihren Datensätzen. Im gesamten Werkzeugkatalog unten tragen torgesicherte Werkzeuge eine TOR-Marke.

Kontext & Navigation

Den richtigen Datensatz finden

Einen Fall lesen

Dokumente & Passagensuche

Richter & Gerichtsentscheidungen

Fünf deterministische Werkzeuge (nirgends eine KI) für eine Frage: wie entscheidet ein einzelner Richter oder Staatsanwalt — was greift er aus den Eingaben auf, was übergeht er, wie berechenbar ist er? Die Werkzeuge finden und messen; die Entscheidungen zu lesen und zu beurteilen bleibt Arbeit der KI, an den Volltexten. Als Entscheidungen zählen nur eingehende Dokumente eines Gerichts oder einer Staatsanwaltschaft.

OCR-Rescan-Heilung — Human-in-the-Loop-Micro-Sourcing

Stellt sich heraus, dass ein gespeicherter Volltext durch einen alten OCR-Lauf abgeschnitten oder ruiniert ist, lebt die KI nicht einfach damit — sie heilt die Datenbank, mit Ihnen als letzter Instanz. Sie fordert einen frischen Scan an; Sie wählen die Seiten in IRONSTICK (dieselbe Seitenauswahl wie bei der Dokumentenerfassung); der Rescan wird deterministisch normalisiert (Wasserzeichen entfernt, OCR-Muster behoben, Leerraum vereinheitlicht) und im Zwischenspeicher NEBEN den aktuellen Datenbanktext gelegt. Die KI vergleicht dann beide Fassungen Passage für Passage, behält die jeweils richtige, behebt nur mechanische OCR-Schäden — nie umformulierend; Zahlen, Namen und Beträge bleiben unangetastet — und gibt die geheilte Fassung zurück. IRONSTICK zeigt sie Ihnen vollständig, und erst IHR Klick speichert sie als neuen Volltext.

Der Schritt darüber hinaus: der Anwalt als Präzisionsinstrument. Die KI nutzt IRONSTICK nicht nur als Datenquelle — wo die automatische Verarbeitung an physische Grenzen stößt, zieht sie Sie bewusst als visuelles Präzisionswerkzeug hinzu:

• Volle Leistungsfähigkeit auch bei riesigen Dateien. Wo ein PDF jeden KI-Kontext sprengt (die Bridge setzt harte Grenzen durch: 10 MB, 90 Seiten), endet der Vorgang nicht mit einem nutzlosen „Datei zu groß“ — die KI nennt stattdessen die genaue Stelle: „Seite 12, oben“.
• Gezielter Kleinstaufwand statt Aktenarchäologie. Sie durchkämmen nie eine 200-seitige Akte. Sie klicken auf die Büroklammer in dem Eintrag, den IRONSTICK bereits für Sie geöffnet hat, springen zur genannten Seite und tippen genau die drei unleserlichen Wörter oder Zahlen ab.
• Direkte Rückführung in den Volltext. Ihre Abschrift wird wörtlich in die geheilte Fassung übernommen, durchläuft denselben Annahmedialog, und die Analyse geht nahtlos weiter.

Herkömmliche Systeme kennen genau zwei Zustände: „Erfolg“ (was immer die OCR hervorgebracht hat, richtig oder falsch) und „Fehler — bitte verarbeiten Sie das Dokument manuell“. Hier wird der Anwalt zum Micro-Tasker für genau die 0,1 % eines Scans, die die KI nicht mit Sicherheit auflösen kann — eine Symbiose aus KI-Geschwindigkeit und menschlichem Sehvermögen.

E-Mail, Kalender & Fristen

Personen, Institutionen & Arbeitsaufzeichnungen

Arbeitsregeln, Formate & Gedächtnis

Vorschläge (prüfpflichtig — schreiben nie direkt)

Zwischenspeicher — große Inhalte laufen nie durch die KI

Ein lokaler Arbeitsbereich. Jeder Werkzeugaufruf darf to_scratch mitführen: das vollständige Ergebnis wird dann in eine Zwischenspeicher-Datei geschrieben, und die KI erhält nur den Pfad und die Größe — keine Vorschau; und jedes Ergebnis oberhalb der Konnektor-Grenze (10.000 Zeichen; 20.000 bei Claude Desktop und ChatGPT Desktop) geht automatisch auf dieselbe Weise dorthin — Toolset-Öffner eingeschlossen. Große Inhalte fließen in KEINER Richtung durch die Ausgabe der KI (schneller, günstiger, keine Abschreibfehler). Zwischenspeicher-Pfade sind direkt als source_path für deliver_file und update_ki_instruction verwendbar. Der Speicher übersteht Neustarts: die eigenen Notizen der KI, ihr Zustandsregister und die Buchführung der Lese-Deckung bleiben erhalten; Werkzeug-Dumps früherer Tage werden bei jedem Start bereinigt, unberührte Dateien nach 180 Tagen.

Der Zwischenspeicher ist ein Tresor. Seit September 2026 liegt jede Datei darin AES-256-verschlüsselt, mit derselben Schlüsselableitung wie die Falldatenbank und der Dokumentenspeicher — nichts, was die KI schreibt, liegt im Klartext auf der Festplatte. Lesen und Schreiben laufen nur durch das Tor von IRONSTICK; eine Klartextdatei, die auf irgendeinem anderen Weg in den Speicher gelegt wird (ein Dateisystem-Werkzeug, eine manuelle Kopie), wird verweigert, entfernt und der KI als Regelverstoß gemeldet. Dateien verlassen den Speicher nur über den Exportdialog von IRONSTICK, nie in einen Download-Ordner. Zusammen mit der verschlüsselten Datenbank, dem Dokumentenspeicher und der Konfiguration schließt das die letzte Lücke: keine Falldaten liegen unverschlüsselt auf der Festplatte des Benutzers — nicht einmal die Arbeitsdateien der KI.

Kein Werkzeug kürzt sein eigenes Ergebnis. evidence_readfull, read_full_case, read_email_body, open_url (ganze Gesetze und Urteile), read_tagesprotokolle, read_person und read_chronik liefern ihren Inhalt immer VOLLSTÄNDIG. Eine zentrale Regel entscheidet, wo er ankommt: unterhalb der Konnektor-Grenze in der Antwort, oberhalb als Ganzes in der Zwischenspeicher-Datei. Die KI muss nie im Voraus raten, wie groß ein Ergebnis sein wird.

Frische-Wächter: IRONSTICK überwacht jede Zwischenspeicher-Datei. In dem Moment, in dem sich die zugrunde liegenden Daten ändern — ein neues Dokument oder ein neuer Chronikeintrag im gedumpten Fall, ein Schreibvorgang in Kalender oder Protokoll — oder eine Datei schlicht veraltet, wird ihr Inhalt durch einen Ungültigkeitshinweis ersetzt, der der KI genau sagt, wie sie ihn neu abruft. Die KI kann nie aus stillschweigend veralteten Dumps arbeiten.

Web, Register & Validierung

Peer-Review — ein Stück an eine ANDERE Desktop-KI geben (Claude ⇄ ChatGPT ⇄ Qwen ⇄ Kimi)

Übergabe & Auslieferung

7. Fleiß-Wächter — die Bridge überwacht die Arbeitsmoral der KI

Vier deterministische Fleiß-Wächter beobachten, wie sorgfältig die verbundene KI tatsächlich arbeitet. Sie sind reine Buchführung und Zeichenkettenlogik — nirgends ist eine KI beteiligt —, sie können also nicht halluzinieren, kosten praktisch nichts und lassen sich nichts ausreden:

• Lese-Deckungs-Wächter. Zieht die KI einen Gesamtfall-Dump, die Vorbereitungsdateien eines Falls oder einen Volltext oberhalb der Konnektor-Grenze, hält die Bridge Zeile für Zeile fest, welche Bereiche sie wirklich gelesen hat — und führt diese Buchführung über Neustarts hinweg. Solange Lücken bleiben, trägt jede Werkzeugantwort — Suchen, grep, alles — die exakten ungelesenen Zeilenbereiche mit einer Prozentangabe. Ein behauptetes „ich habe alles gelesen“ ist schlicht unmöglich; nur ein vollständiger Lesevorgang verdient die einmalige Bestätigung „COMPLETE — alle Zeilen gelesen“, ein mathematisch beweisbares Ende der Lesepflicht — und stempelt den Lesevorgang ins Vorbereitungsbuch.
• Keine Vorschau. Jedes Ergebnis oberhalb der Konnektor-Grenze (10.000 Zeichen; 20.000 bei Claude Desktop und ChatGPT Desktop) wird als Ganzes in den Zwischenspeicher geschrieben; die KI erhält nur einen Hinweis, der die Datei, ihre Größe und die zwei Fortsetzungsbefehle nennt. Nichts wird zweimal gezeigt, und die KI liest große Inhalte dort, wo sie liegen. Das gilt für jedes Werkzeug — Toolset-Öffner eingeschlossen; nur der Instruktionsleser und die Zwischenspeicher-Werkzeuge selbst antworten direkt. Und kein Werkzeug kürzt sein eigenes Ergebnis: unterhalb der Grenze kommt es vollständig in der Antwort an, oberhalb vollständig im Zwischenspeicher.
• Wächter der Neuauslieferung. Korrigiert die KI eine Arbeitsdatei weiter, nachdem sie Ihnen bereits ausgeliefert wurde, wird jede weitere Bearbeitung mit der Erinnerung beantwortet, dass Sie in diesem Moment die veraltete Fassung in Händen halten und dass die korrigierte Datei erneut ausgeliefert werden muss — kein stilles „im Entwurfsordner behoben“ mehr.
• Wächter nicht ausgelieferter Entwürfe. Schreibt die KI ihr Tagesprotokoll — das Signal „ich schließe ab“ —, führt die Bridge namentlich jeden in der Sitzung geschriebenen versionierten Entwurf auf, der überhaupt nie ausgeliefert wurde. Fertige Arbeit kann nicht still in der Arbeitsablage der KI hängen bleiben.
• E-Mail-Format-Wächter. Jeder Zugriff auf E-Mail-Inhalte trägt automatisch den verbindlichen Verweis auf das Mail-Format-Werkzeug (Kopierfeld Betreff, Kopierfeld Text, Pflichtinhalt, Sprachregeln) — die KI wird an den einen richtigen Auslieferungsweg erinnert, bevor sie einen improvisieren kann.
• Kopierfeld-Wächter. Jedes Mal, wenn die KI eine Text-Arbeitsdatei schreibt oder bearbeitet, trägt die Antwort die Erinnerung, dass Dokumente den Benutzer nur über das Auslieferungswerkzeug erreichen — einen fertigen Brief als Text oder Kopierfeld in den Chat einzufügen umgeht Formatierung, Prüfung und Auslieferungs-Verfolgung und ist ein sichtbarer Regelverstoß. Das eine legitime Kopierfeld-Artefakt bleibt die E-Mail, genau nach dem Mail-Format-Werkzeug.
• Fall-Anker. Jede Werkzeugantwort, die einen Fall berührt, trägt die registrierte Nummer, den Mandanten und den Gegenstand des Falls (Tor 10) — Kontext, der aus der Erinnerung an einen anderen Fall erfunden wird, widerlegt sich im selben Fenster selbst.
• Steuerung der Modellklasse. Die Instruktionen sagen der KI, welche Modellklasse eine Aufgabe braucht: vor den Schriftsatz-Werkzeugen (Ausgabeformat, Prüfung, Auslieferung) bittet sie Sie in einem Satz, den Desktop-Client auf das Spitzenmodell umzuschalten, und nach der Auslieferung teilt sie Ihnen mit, dass ein günstigeres Modell wieder genügt. Zeigen die Vorschlagszähler Pflege des Parteiennetzes (zwei Stammdatenvorschläge und ein Beziehungs- oder Fallverknüpfungsvorschlag), hängt die Bridge — einmal je Sitzung — den Hinweis an, dass diese vollständig torgesicherte Arbeit kein Spitzenmodell braucht. Sie entscheiden; die KI arbeitet weiter.

Seit derselben Version läuft die Werkzeugausführung zudem in einem isolierten Worker-Thread innerhalb der Anwendung — selbst mehrsekündige KI-Zugriffe auf große Fallakten blockieren die Benutzeroberfläche von IRONSTICK nie mehr.

8. Der Schriftsatz-Compiler — Auslieferung nur gegen Nachweis

Schriftsätze und Briefe entstehen im Dialog mit der Desktop-KI an der lebenden Akte — dieselbe Arbeitsebene und dieselben Tore wie der eigene Chat von IRONSTICK. Was das System verlässt, ist eine einreichungsfähige Vorlage, nie eine fertige Gerichtseingabe: Sie prüfen, korrigieren und unterschreiben. Zwei Tore stehen vor jeder Übergabe: die deterministische Prüfung unten und — wenn Sie es in der Konfiguration für das aktive API-Modell einschalten — das Red/Blue Team: ein zweites Modell liest den Entwurf als gegnerischer Anwalt; gewichtige Befunde schicken ihn zur Überarbeitung zurück, höchstens zwei Runden, jeder Punkt wird in der Sache analysiert und nie blind übernommen. Hält die KI die Befunde für unbegründet, reicht sie die unveränderte Datei mit einer schriftlichen Antwort auf jeden Befund erneut ein — der Prüfer wird auf eine unveränderte Datei kein zweites Mal angesetzt, und der Prüferbericht erreicht Sie zusammen mit diesen Antworten. Die Übergabe selbst läuft über den Exportdialog von IRONSTICK, von wo der Entwurf mit einem Klick in die Textverarbeitung geht.

Ein förmlicher Schriftsatz kann das System nicht auf Treu und Glauben verlassen. verify_pleading, ein deterministischer Scanner (nirgends ist eine KI beteiligt), prüft den fertigen Entwurf gegen Ihre lebenden Datensätze und die geprüfte Gesetzes-Bibliothek über acht Behauptungsklassen:

• Beweismittelverweise — IS-Stempel und #-Nummern, in der Beilagenliste UND im Fließtext: Existenz, Zugehörigkeit, Stempelintegrität und dokumentgebundene Zitat-Herkunft: jedes zitierte oder beigefügte Stück muss für DIESES Dokument als gelesen gelten — vollständig abgerufen oder seine Zwischenspeicher-Datei zu 100 % gelesen; ein Lesevorgang zählt 2 Stunden, jede Auslieferung desselben Dokuments verlängert ihn, das Prüfen eines anderen Dokuments setzt die Beilagen-Lesevorgänge zurück. Wer aus Such-Ausschnitten oder aus dem Gedächtnis zitiert, fällt durch die Prüfung. Eine Beilagenzeile darf einen Seitenbereich angeben („S. 12–15“); die Lesepflicht bleibt das ganze Dokument.
• Gesetzeszitate — der zitierte Artikel muss im geprüften Bibliothekstext existieren (tolerant gegenüber Tausenderpunkten, exakt an Wortgrenzen) UND eine Lese-Herkunft tragen: die KI muss diesen Artikel in diesem Programmlauf tatsächlich aus der Bibliothek gezogen haben — Presseartikel, Web-Zusammenfassungen und Modellgedächtnis begründen nie eine Norm und fallen durch die Prüfung. Zitierte Unterverweise (Absatz/Punkt) werden ebenfalls auf Existenz geprüft. Eine Quelle, die in der Bibliothek fehlt, rutscht nicht durch: die KI muss sie anfordern, und die Anforderung landet in Ihrem Zustimmungsdialog — angehakte Quellen werden abgerufen, geprüft und gespeichert; nicht angehakte werden abgelehnt, und jedes spätere Zitat daraus trägt einen sichtbaren Vermerk „vom Benutzer abgelehnt“.
• Wörtliche Zitate — jede zitierte Passage muss vollständig in den Volltexten des Falls oder in der Gesetzes-Bibliothek gefunden werden (OCR-tolerant). Ein Zitat, das in keiner Quelle gefunden wird, ist CONTRADICTED und sperrt die Auslieferung. Die Anführungszeichen wegzunehmen oder die Passage leicht umzuformulieren hilft nicht: das gesperrte Zitat wird für das Dokument gemerkt und bleibt gesperrt. Ein ganz gestrichenes Zitat ist zulässig — und die Auslieferung sagt Ihnen ausdrücklich, welche Zitate entfernt wurden, weil keine Quelle sie enthält.
• Dosar-Nummern gegen Ihre Fälle und Datensätze.
• Beträge mit NULL Toleranz — die Zahl muss der aufgezeichneten Form exakt entsprechen; „14.500“, wo das Register „14.500,00“ sagt, sperrt die Auslieferung bis zur Korrektur.
• Partei-Stammdaten — jeder verwendete Name muss der registrierten Schreibweise Buchstabe für Buchstabe entsprechen, Diakritika eingeschlossen.
• CNP und IBAN — Prüfsummenvalidierung (eine ungültige Prüfziffer ist immer eine Halluzination) plus Abgleich mit Register/Datensätzen.
• Genannte Parteien — jede im Dokument genannte Person oder Firma muss gelesen (Profil) UND ihre Verbindungen müssen geprüft worden sein (who_is_connected_with); die Verweigerung nennt die zwei Aufrufe und empfiehlt obendrein den Cliquen-Test (read_cliques).

Jeder Befund ist VERIFIED, UNVERIFIED oder CONTRADICTED. Die Auslieferung eines förmlichen Dokuments wird verweigert ohne frisches OK-Testat für genau diesen Dateistand — jede Bearbeitung macht das Testat ungültig. Nach fünf gescheiterten Prüfläufen bricht die Schleife hart ab, weist die KI an, anzuhalten und zu berichten, und benachrichtigt Sie direkt in der Anwendung. Und Auslieferungen laufen ausschließlich über die eigene Arbeitsablage der Anwendung, damit Testat, Versionierung und Verfolgung der Neuauslieferung an jeder Datei haften bleiben — Inline-Auslieferung und fremde Pfade werden verweigert.

Anhang — Vollständige technische Beschreibung der Bridge

Stand: 175 Mitglieds-Werkzeuge · 20 Toolsets · MCP-Protokollrevision 2024-11-05. Dieses Dokument beschreibt die Bridge erschöpfend — Architektur, jede Funktionsschicht, jedes Tor, jede Grenze und jede Umleitung — ausschließlich in Prosa.

1. Zweck und Einordnung

Die Bridge verbindet kommerzielle Desktop-KI-Anwendungen (Claude Desktop, ChatGPT Desktop, Qwen Desktop, Kimi Desktop) mit einer laufenden IRONSTICK-Anwendung zur juristischen Fallverwaltung auf demselben Rechner. Die Desktop-KI erhält über das Model Context Protocol (MCP) eine kontrollierte, selbstbeschreibende Werkzeugoberfläche; jeder Aufruf wird innerhalb der IRONSTICK-Anwendung gegen die Live-Datenbank ausgeführt, und jedes Ergebnis wird von der Bridge nachbearbeitet, bevor es das Modell erreicht. Die Entwurfsziele sind: minimale dauerhafte Kontextlast für das Modell, strukturelle Durchsetzung von Arbeitsregeln, die bloßer Instruktionstext nicht garantieren kann, Schutz ungespeicherter Arbeit des Benutzers, Schutz der Daten vor übergroßen oder fehlgeleiteten Anfragen und das vollständige Fehlen lesbaren Konfigurationsmaterials im installierten Produkt.

2. Prozesstopologie

Die Bridge besteht aus zwei zusammenarbeitenden Prozessen.

Die IRONSTICK-Anwendung betreibt einen HTTP-Server, der ausschließlich an die Loopback-Schnittstelle gebunden ist. Sein Port und ein 48-stelliges hexadezimales Zugriffstoken sind im Konfigurationsspeicher der Anwendung festgelegt; jede Anfrage muss das Token vorweisen. Dieser Server besitzt das Werkzeugregister, führt alle Werkzeugaufrufe aus, wendet alle Tore und Nachbearbeiter an und ist die einzige maßgebliche Stelle dafür, was ein verbundenes Modell sehen und tun darf.

Vor jeder Desktop-KI steht eine kleine native ausführbare Datei, die aus Dart vorab (ahead-of-time) kompiliert ist. Sie spricht JSON-RPC über stdio zur Desktop-KI hin (Standard-MCP-Transport) und reicht die Arbeit an den HTTP-Server der Anwendung weiter. Jede Desktop-KI hat ihr eigenes Installationsverzeichnis mit einer Kopie dieser ausführbaren Datei und einer privaten Konfigurationsdatei, die enthält: den Loopback-Port, das Zugriffstoken, eine Zeichenkette zur Aufruferidentität (zum Beispiel claudedesktop, chatgptdesktop, qwendesktop), den Pfad der Instruktionsdatei, die beim Sitzungsstart ausgeliefert wird, und den Pfad des Auslieferungsskripts. Die Aufruferidentität reist als internes Argument mit jedem Werkzeugaufruf mit und steuert alle später beschriebenen Verhaltensweisen je KI. Das Front-End sendet außerdem etwa alle drei Sekunden einen Heartbeat an die Anwendung, solange eine Desktop-KI verbunden ist; die Anwendung zeigt dies als Präsenzanzeige „Bridge verbunden“ mit einer Lebensdauer von fünfzehn Sekunden, sodass der Benutzer immer sieht, ob gerade eine externe KI angeschlossen ist.

Beim MCP-Initialize-Handshake gibt das Front-End seine Serveridentität und, eingebettet in das Initialize-Ergebnis, den vollständigen Instruktionstext für den Sitzungsstart zurück. Front-Ends ab Version 2.6.6 suchen nach einer Begleitdatei des konfigurierten Instruktionspfads, deren Name ein Kern-Suffix trägt, und bevorzugen sie; das liefert eine verdichtete Kerninstruktion von rund fünfzehneinhalbtausend Zeichen statt des vollständigen Regelwerks von rund sechsundfünfzigtausend und senkt die dauerhafte Instruktionslast auf etwa ein Viertel. Das vollständige Regelwerk bleibt dem Modell jederzeit über ein eigenes Werkzeug verfügbar (siehe Abschnitt 5).

3. Sicherheit, Lizenzierung und Zustimmung

Der gesamte Verkehr läuft nur über Loopback und ist tokenauthentifiziert. Die Webzugriffs-Werkzeuge setzen eine serverseitige Anfragefilterung durch: nur öffentliche http- und https-Ziele sind zulässig; localhost, Loopback-Bereiche, private Netze und Link-Local-Adressen werden abgewiesen, sodass ein Modell nie dazu gebracht werden kann, über die Bridge den Rechner oder das LAN abzutasten.

Die Bridge und die Desktop-Integrationen je Anbieter sind getrennt lizenzierte Zusatzmodule. Ihre Verfügbarkeit ist als Bits in einem signierten Lizenzschlüssel kodiert; Front-End und Werkzeugoberfläche eines nicht lizenzierten Moduls entstehen schlicht gar nicht erst.

Für die Verbindung mit Claude Desktop schützt ein Zustimmungs-Tor den ersten Datenzugriff je Programmlauf: der erste Werkzeugaufruf nach dem Programmstart öffnet ein Warnmodal über dem aktuellen Bildschirm. Stimmt der Benutzer zu, ist der Zugriff für den Rest des Laufs frei; lehnt der Benutzer ab, ist der Zugriff zehn Minuten gesperrt, und jeder gesperrte Aufruf gibt der Desktop-KI eine erklärende Meldung zurück, die sie bittet, es später erneut zu versuchen; nach den zehn Minuten löst der nächste Zugriff die Warnung erneut aus. Der Zustand wird nur im Arbeitsspeicher gehalten und nie gespeichert.

Unabhängig von der Zustimmung bewacht ein Instruktions-Riegel jede Desktop-Verbindung: kein Werkzeug — Toolset-Öffner, das Mitglieder-Ausführungswerkzeug, alles — wird ausgeführt, bis der Aufrufer die Instruktionen gelesen und das Halluzinationsverbot (Regel 5) über das Bestätigungswerkzeug wörtlich zurückgegeben hat; nur der Instruktionsleser, das Bestätigungswerkzeug und das Systemsprache-Werkzeug bleiben offen. Die Bestätigung wird je Desktop-KI geführt und verfällt sechzig Minuten nach ihrer Abgabe, nach zwei Stunden ohne Aufruf, um Mitternacht und bei jedem neuen Verbindungs-Handshake — nach einem Verfall muss der Aufrufer neu lesen und eine zufällig gewählte Regel zurückgeben statt derjenigen, die er auswendig kennt. Auf der Claude-Verbindung ist jeder Chat ein eigener Aufrufer (auseinandergehalten über die strukturierten Werkzeug-Ereignisse aus Claudes lokalem Sitzungsprotokoll, nie über den Gesprächstext), ein Chat, dessen Kontext verdichtet wurde, wird sofort und ohne Strafe gesperrt, bis er neu gelesen hat, und einem Chat, der den Datenordner mit seinen eigenen Datei-Werkzeugen statt über den Konnektor anfasst, wird das als Regelverstoß vermerkt; eine Verweigerung nennt die zwei Aufrufe, die den Riegel öffnen, und das Aufklappmenü am Symbol der KI in der Anwendung zeigt den Zustand als grünen Haken oder rotes Kreuz.

Jede datenlesende und datenschreibende Funktion wird gegen die aus der Lizenz abgeleitete Eigentümeridentität eigentümervalidiert. Als geheim markierte Beweismittel-Datensätze sind ausnahmslos von jeder Lese-, Such-, Dump- und Stempelfunktion ausgeschlossen; als gelöscht markierte Datensätze sind ebenso unsichtbar.

4. Instruktionssystem

Die Anleitung des Modells kommt in drei Schichten mit streng zunehmender Spezifität und streng abnehmender Verweildauer.

Die Kerninstruktion wird einmal ausgeliefert, innerhalb des Initialize-Ergebnisses. Sie enthält das Mandat (faktenbasierte juristische Arbeit auf Senior-Associate-Niveau), die universellen Regeln (die Dialogsprache ist die IRONSTICK-Systemsprache; der Rechtsraum erzeugter Dokumente kommt aus dem Fall, nie aus dem Dialog; Datumsdisziplin; kein Zitieren aus Such-Ausschnitten — jede Seite, auf die sich die KI stützt, muss über open_url geöffnet und gelesen werden, gleich welche Suche sie gefunden hat; Zitier- und Verweisdisziplin; die Wiederholungsgrenze von drei Versuchen je fehlschlagendem Werkzeugaufruf; Auslieferungsdisziplin) und die Beschreibung des Toolset-Mechanismus selbst, einschließlich der Erklärung des in Abschnitt 6 beschriebenen Heimat-Toolset-Felds.

Die Arbeitsregeln je Bereich sind nicht dauerhaft präsent: sie werden dem Modell wörtlich und aktuell jedes Mal übergeben, wenn es das entsprechende Toolset öffnet, als Teil der Öffnungs-Nutzlast.

Das vollständige Regelwerk — Kern plus alle Toolset-Regeln plus die Anhänge (darunter das Dateiformat des Tagesprotokolls) — kann jederzeit über das Instruktions-Lesewerkzeug neu gelesen werden; das Front-End liest die Datei live, sodass Instruktionsänderungen eine laufende Sitzung ohne Neuverbindung erreichen.

Drei dieser Regeln werden zusätzlich strukturell statt textlich durchgesetzt, durch die in den Abschnitten 3 und 7 beschriebenen Tore: der Instruktions-Riegel, die Datumsdisziplin und die Disziplin der Gesetzesquellen. Das Lesen der Instruktionen selbst ist die letzte Regel des universellen Blocks: der Weg, den Konnektor zu entriegeln, wird erst nach allen vorangehenden Regeln genannt, sodass ein Modell, das ihn erreicht, sie gelesen hat.

5. Die Werkzeugoberfläche und die Toolset-Schicht

Eine flache Liste von 175 Werkzeugen verschlechtert die Werkzeugauswahl heutiger Desktop-Modelle messbar. Die Bridge legt deshalb eine reduzierte Oberfläche von achtundzwanzig Einträgen offen: sechs Kernwerkzeuge (aktuelles Datum und Uhrzeit; aktueller GUI-Kontext; Systemsprache; Rechtsraum des Falls; erneutes Lesen der Instruktionen; Bestätigung der Instruktionen), das vom Front-End eingefügte Auslieferungswerkzeug, zwanzig Toolset-Öffner, das Mitglieder-Ausführungswerkzeug und das Gesamtinventar-Werkzeug. Alles andere existiert nur als Mitglied innerhalb von Toolsets.

Das Öffnen eines Toolsets ist ein gewöhnlicher Werkzeugaufruf ohne Argumente. Die Antwort liefert in einem Zug: erstens, wo das Toolset einen hat, einen deterministisch vorerzeugten Kontextblock, berechnet im Moment des Öffnens (acht Toolsets haben solche Erzeuger — das Sitzungsstart-Protokoll selbst; das aktuelle Inventar der Zwischenspeicher-Dateien; die zehn jüngsten Gedächtniseinträge als Vorschau; die ersten dreißig Gesetze der Gesetzes-Bibliothek; die Liste der heißen Fälle; die heute registrierten Dokumente und eingegangenen E-Mails; das heutige Tagesprotokoll; den aktuellen Schnappschuss der Fristen und Termine); zweitens die wörtlichen Arbeitsregeln des Bereichs; drittens die vollständigen Definitionen der Mitglieds-Werkzeuge mit ihren vollen Parameterschemata; viertens eine Rückfallzeile, die auf das Gesamtinventar verweist. Ein Fehler in einem Vorerzeuger verhindert das Öffnen nie.

Mitglieder werden über das Mitglieder-Ausführungswerkzeug ausgeführt, das den exakten Mitgliedsnamen und ein Argumentobjekt entgegennimmt. Vor der Ausführung läuft eine leichtgewichtige Schemavalidierung: Pflichtfelder müssen vorhanden und nicht leer sein, und Ganzzahl-, Zahl- und Boolesche Parameter müssen sich als solche lesen lassen; ein Verstoß gibt das erwartete Schema zurück, statt auszuführen. Ein unbekannter Mitgliedsname gibt den nach Editierdistanz nächstliegenden vorhandenen Namen als Vorschlag zurück. Die Instruktionsschicht begrenzt Korrekturversuche auf drei je fehlschlagendem Aufruf, danach muss das Modell anhalten und den genauen Fehler melden.

Toolsets sind nicht modal; alle Öffner bleiben jederzeit aufrufbar, ein Werkzeug darf bewusst Mitglied mehrerer Toolsets sein, und Öffnungs-Nutzlasten werden nie in den Zwischenspeicher umgeleitet (Schemata in einer Datei wären nutzlos). Funktionsschalter entfernen ganze Gruppen: ist die GUI-Navigation vom Benutzer nicht aktiviert, fehlen der Öffner des Navigations-Toolsets und alle seine Mitglieder in jeder Liste und jeder Antwort. Das Gesamtinventar-Werkzeug führt jedes Mitglied mit einem einzeiligen Zweck und seinem besitzenden Toolset auf und existiert nur als Notausgang; die Toolset-Beschreibungen sind der primäre Wegweiser. Insgesamt tragen die zwanzig Toolsets 280 Mitgliedseinträge über die 175 verschiedenen Werkzeuge.

Die gemessenen Kontextkosten dieser Anordnung: die Anfangskonfiguration (Kerninstruktion plus reduzierte Werkzeugliste) liegt bei rund zehntausend Token; ein einzelnes Toolset-Öffnen fügt je nach Toolset zwischen rund neunhundert und siebeneinhalbtausend Token hinzu, vor seinem variablen vorerzeugten Inhalt.

6. Format der Werkzeugdefinition und seine Produktionskette

Jede Werkzeugdefinition besteht aus vier Teilen. Die Beschreibung trägt den Zweck des Werkzeugs, seine Verhaltensgebote und seine Querverweise — und sonst nichts. Das Eingabeschema trägt jeden Parameter mit eigener Beschreibung, einschließlich Vorgabewerten, Formaten, Hinweisen zum gegenseitigen Ausschluss und Geboten je Parameter; Anweisungen zur Parameterverwendung stehen ausschließlich hier. Das Ausgabefeld beschreibt vor jedem Aufruf genau, was der Aufruf zurückgibt, einschließlich Reihenfolgen, Markierungen und Fehlerformen, sodass das Modell die Eignung ohne Probeaufrufe beurteilen kann. Das Heimat-Toolset-Feld nennt das Toolset, zu dem das Werkzeug in erster Linie gehört, mit einem reservierten Wert, der Kernwerkzeuge kennzeichnet, die immer in der obersten Liste stehen; ein Mitglied, das in einem fremden Toolset angetroffen wird, zeigt damit an, wo weitere Werkzeuge seiner Familie liegen, und jedes Toolset-Öffnen trägt eine erklärende Zeile, die feststellt, dass das Modell nie in das geöffnete Toolset eingesperrt ist.

Aller modellseitige Text ist ausnahmslos englisch. Die Produktionskette läuft von einem einzigen kanonischen Quelldokument über Generatoren in das einkompilierte Overlay und in den Cluster-Bauplan, der die Toolset-Topologie dokumentiert; der Generator bricht hart ab, wenn irgendein Beschreibungs- oder Ausgabetext — in beliebiger Schematiefe — auf einen Detektor für deutsche Sprache anspricht, und ein Drift-Wächter bricht die Synchronisation ab, wenn eine Heimat-Toolset-Angabe auf ein Toolset zeigt, das das Werkzeug tatsächlich nicht als Mitglied führt. Erklärte numerische Grenzen in Werkzeugschemata werden durch eine gemeinsame Begrenzungsfunktion in den ausführenden Funktionen durchgesetzt, sodass ein genanntes Maximum ein echtes Maximum ist.

7. Universelle Laufzeitmechanismen

Die folgenden Mechanismen gelten über die gesamte Werkzeugoberfläche und sind zentral umgesetzt, nicht je Werkzeug.

Zwischenspeicher-Umleitung auf Wunsch: jedes Werkzeug akzeptiert einen zusätzlichen Parameter, der eine Zwischenspeicher-Datei benennt; ist er gesetzt, wird das vollständige Ergebnis in diese Datei geschrieben, und das Modell erhält nur den Pfad und die Größe — keine Vorschau. Große Inhalte fließen dadurch in keiner Richtung durch den Tokenstrom des Modells, und der Pfad ist überall direkt verwendbar, wo ein Quellpfad akzeptiert wird.

Überlaufschutz: jedes Ergebnis, das die Konnektor-Grenze überschreitet — zehntausend Zeichen, eine zentrale Konstante, verdoppelt auf zwanzigtausend für Claude Desktop und ChatGPT Desktop —, wird automatisch in eine erzeugte Zwischenspeicher-Datei geschrieben. Das Modell erhält nur einen Hinweis mit der Gesamtgröße und der Zeilenzahl, dem Dateinamen, der ausdrücklichen Zusicherung, dass nichts verloren ist, den zwei Fortsetzungsbefehlen (bereichsweises Lesen; Mustersuche in der Datei) und dem ausdrücklichen Verbot, den Aufruf erneut anzufordern — keine Vorschau, sodass große Inhalte dort gelesen werden, wo sie liegen, und das Modell sich daran gewöhnt, aus dem Zwischenspeicher zu arbeiten. Die eine Ausnahme ist der Instruktionsleser, dessen Paket immer vollständig ankommt; Toolset-Öffner werden wie jedes andere Ergebnis umgeleitet. Kein Werkzeug kürzt sein eigenes Ergebnis — die Konnektor-Grenze ist die einzige Stelle, an der über Größe entschieden wird. Ergebnisse über zehn Megabyte werden nicht umgeleitet, sondern mit einer Eingrenzungsanweisung beantwortet, die die anwendbaren Filter nennt, da dort selbst der Zwischenspeicher die Dateigröße begrenzt. Von der Umleitung ausgenommen sind die Zwischenspeicher-Lesewerkzeuge selbst (intern begrenzt; sie umzuleiten würde eine Rekursion erzeugen) und Aufrufe, die die Zwischenspeicher-Umleitung bereits angefordert haben.

Datums-Tor: jedes Werkzeug, das in IRONSTICK schreibt, wird externen Aufrufern verweigert, solange dieser Aufrufer nicht innerhalb der letzten dreißig Minuten das aktuelle Datum samt Uhrzeit abgerufen hat. Die Verweigerung nennt die Abhilfe — die Zeit abrufen, dann den identischen Aufruf wiederholen. Das Fenster wird je Anbieter geführt und ist bewusst kurz, damit ein frisches Gespräch keinen alten Abruf erben kann und Mitternachtswechsel erfasst werden. In-App-Aufrufer sind nicht betroffen. Das gibt es, weil externe Modelle Datensätze sonst mit dem „Heute“ ihrer Trainingszeit stempeln.

Gesetzes-Tor: der Webzugriff für Gesetze und Normen wird strukturell verweigert, bis die interne Gesetzes-Bibliothek befragt wurde; die Verweigerung verweist auf das Bibliotheksverfahren. Jede Gesetzesquelle, die dennoch aus dem Web abgerufen wird, muss über das Registrierungswerkzeug in die Bibliothek gemeldet werden — die Instruktionsschicht stuft das Unterlassen als Pflichtverletzung ein, und Ergebnisse, die Rechtsquellen berühren, tragen zur Prüfbarkeit eine Markierung.

Harte Navigationssperre: acht Bildschirme sind als geschützt erklärt — die vier Erfassungsformulare (Dokumentenerfassung, fallgebundene Dokumentenerfassung, Erfassung der Fallchronik, Mandantenerfassung), das Formular zur Fallanlage, das Formular zur Zuordnung von Institutionen/Personen und der Texteditor. Solange das Hauptfenster des Benutzers einen davon zeigt, wird jede GUI-Navigations- und Exportfunktion auf Handler-Ebene verweigert — der Wrapper fängt direkte Aufrufe und die Mitgliederausführung gleichermaßen ab — mit einer Meldung, die den geschützten Bildschirm nennt, die Navigation verbietet und das Modell anweist, mit den vorhandenen Daten zu antworten und das Öffnen erst anzubieten, nachdem der Benutzer fertig ist und gespeichert hat. Ein Modell kann daher nie ungespeicherte Arbeit des Benutzers durch einen Bildschirmwechsel zerstören. Das Werkzeug zum Öffnen von Webseiten ist von diesem Wrapper ausdrücklich ausgenommen, da es zwar das Namenspräfix teilt, die Anwendung aber nicht navigiert.

Navigationsangebot: die Ergebnisse der rund vierzig Werkzeuge, deren Ausgabe ein in der GUI öffenbares Objekt beschreibt — einen Fall, eine Person, eine Institution, einen Mandanten, ein bestimmtes Beweismittel, eine E-Mail, Kalendereinträge oder Fristen —, erhalten eine angehängte Zeile, die vorschlägt, dass das Modell dem Benutzer anbietet, das Objekt direkt in IRONSTICK zu öffnen, und den genauen Navigationsaufruf nennt. Enthalten die aufrufenden Argumente die Objektkennung, ist der Vorschlag konkret; bei Such- und Listenergebnissen verweist er auf die Kennung eines Treffers. Die Zeile verlangt ausdrücklich das Einverständnis des Benutzers vor dem Navigieren, es sei denn, die Anfrage des Benutzers war bereits ein Zeigen-/Öffnen-Befehl. Das Angebot wird erst nach der Überlaufbehandlung angehängt und nur, wenn das Ergebnis kein Fehler ist, die Navigation aktiviert ist und die harte Navigationssperre nicht greift — die Sperre gewinnt immer gegen den Vorschlag.

Weitergabe des Aufrufers: die Aufruferidentität begleitet jede Ausführung und steuert den Zustand je KI — das einmal tägliche Arbeitsbriefing wird je Desktop-KI verfolgt, Listen der Peer-Review-Aufgaben schließen die eigenen Aufgaben des Aufrufers aus, und das Aufrufprotokoll ordnet jede Zeile zu.

Aufrufprotokoll: ein schaltbares Diagnoseprotokoll zeichnet eine Zeile je Werkzeugaufruf über alle verbundenen KIs auf — Zeitstempel, Aufrufer, den wirksamen Werkzeugnamen (bei der Mitgliederausführung das innere Mitglied, nicht den Wrapper), die Argumente, auf dreihundert Zeichen begrenzt, die Ergebnisgröße, gemessen vor jeder Überlaufumleitung, die Ausführungsdauer und ein Fehlerkennzeichen. Der Schalter liegt im Konfigurationsspeicher der Anwendung und wird mit einem Zehn-Sekunden-Cache neu gelesen, sodass die Protokollierung ohne Neustart umgeschaltet werden kann. Es dient der Pfadanalyse und der Toolset-Optimierung und soll danach wieder ausgeschaltet werden.

Diakritika- und Schrift-Faltung: jede Stichwortsuche, Mustersuche und jeder Vergleich in der gesamten Bridge faltet Groß-/Kleinschreibung und Diakritika für alle elf Systemsprachen, einschließlich des türkischen i mit und ohne Punkt (vor der Kleinschreibung ersetzt, da es sonst die Länge ändert), kyrillischer Buchstabenvarianten und lateinischer Ligaturen; die Faltung ist positionsstabil, wo Positionen gemeldet werden.

Ergebniskonventionen: Fehlschläge werden als Text zurückgegeben, der mit einem Fehlerpräfix beginnt, und im MCP-Ergebnis als Fehler gekennzeichnet; das Modell ist angewiesen, höchstens dreimal zu korrigieren und es erneut zu versuchen, dann anzuhalten und zu berichten. Strukturierte, selbstbeschreibende Markierungen, die in Ergebnisse eingebettet sind (für Gedächtnisoperationen, Tore und Ähnliches), sind stabil und in den jeweiligen Ausgabefeldern dokumentiert.

Lese-Deckungs-Wächter: zieht ein Modell einen Gesamtfall-Dump oder die Zwischenspeicher-Lieferung des Gesamtfall-Lesers, hält die Bridge zeilengenau fest, welche Bereiche der Dump-Datei tatsächlich gelesen wurden. Solange ungelesene Bereiche bleiben, trägt jede erfolgreiche Werkzeugantwort — Suchen, Mustertreffer, alles — die exakten ungelesenen Zeilenbereiche zusammen mit einem Leseanteil in Prozent; ein behaupteter vollständiger Lesevorgang ist daher unmöglich. Sobald die Datei vollständig gelesen ist, hört das Mahnen auf, und der nächste bereichsweise Lesevorgang bestätigt einmalig, dass alle Zeilen gelesen wurden, was dem Modell ein beweisbares Ende seiner Lesepflicht gibt. Verfolgt werden die Gesamtfall-Dumps, die Kopf- und Digest-Dateien des Fallvorbereitungs-Werkzeugs und jeder Dokument-Volltext, der in den Zwischenspeicher umgeleitet wurde; Teillesungen anderer umgeleiteter Ergebnisse bleiben legitim und still. Der Deckungszustand wird neben dem Speicher abgelegt und übersteht Neustarts der Anwendung, und eine vollständig gelesene Datei wird ins Vorbereitungsbuch gestempelt — der Lesevorgang bleibt gültig, selbst nachdem die Bereinigung beim Start die Datei entfernt hat.

Wächter der Neuauslieferung: nach einer erfolgreichen Dateiauslieferung, deren Quelle im Zwischenspeicher liegt, hält eine Markierungsdatei neben dem Speicher den ausgelieferten Namen und die Zeit fest (Auslieferungen, die als Inline-Inhalt übergeben wurden, werden ebenfalls unter ihrem Auslieferungsnamen festgehalten). Jede spätere Bearbeitung, jedes Schreiben oder Normalisieren einer dort verzeichneten Datei wird mit der Erinnerung beantwortet, dass der Benutzer die veraltete ausgelieferte Fassung in Händen hält und dass die korrigierte Datei unter einer neuen Versionsnummer erneut ausgeliefert werden muss. Die Auslieferungsantwort selbst ruft zusätzlich den aktuellen Zustand der Lese-Deckung über einen internen Endpunkt, der kein Werkzeug ist, von der Anwendung ab und rügt eine Auslieferung, die trotz ungelesener Bereiche erfolgt ist.

Wächter nicht ausgelieferter Entwürfe: das Anhängen ans Tagesprotokoll — das Abschluss-Signal des Modells — führt namentlich jede versionierte Arbeitsdatei auf, die das Modell in der Sitzung geschrieben und nie ausgeliefert hat, mit der Anweisung, das fertige Artefakt jetzt auszuliefern; Arbeit, die nur im Zwischenspeicher existiert, erreicht den Benutzer nie.

E-Mail-Format-Wächter: jede Antwort der Werkzeuge zum Lesen und Abrufen von E-Mails trägt den festen Verweis, dass die verbindliche Instruktion für das Formatieren und Ausliefern von E-Mails — Kopierfeld Betreff, Kopierfeld Text, Empfängerabschnitt, Pflichtinhalt, Sprachregeln — vom Werkzeug der Mail-Format-Spezifikation kommt, vor dem Aufbau jeder E-Mail abzurufen und buchstabengetreu zu befolgen ist.

Ausführung im Worker-Isolate: der rechnerische Kern der Daten- und Analysewerkzeuge läuft in einem eigenen Worker-Isolate innerhalb der Anwendung, mit eigenem Register und eigenen Datenbankverbindungen; das Oberflächen-Isolate der Anwendung leitet nur weiter, wendet Tore an und bearbeitet nach. Selbst mehrsekündige Zugriffe auf große Fallakten blockieren daher nie die Benutzeroberfläche der Anwendung; stirbt der Worker, fällt die Ausführung nahtlos auf das Oberflächen-Isolate zurück, und der Worker wird bei nächster Gelegenheit neu gestartet. Werkzeuge, die ihrer Natur nach das Oberflächen-Isolate brauchen — Navigation, Bestätigungsdialoge, der eingebettete Browser, der Mailabruf und die prüfpflichtigen Schreiber —, sind konstruktionsbedingt vom Worker-Routing ausgenommen.

8. Interaktions-Tore

Drei Werkzeuge beantworten ihren ersten Aufruf bewusst mit einer Frage statt mit einem Ergebnis; bei allen ist die wörtliche Antwort „unknown“ immer gültig und wird nie bestraft.

Das Auslieferungs-Tor: das Dateiauslieferungs-Werkzeug liefert, ohne die Förmlichkeitserklärung aufgerufen, nichts aus und fragt, ob die Auslieferung eine der vier förmlichen Artefaktarten ist — juristischer Schriftsatz, Gerichts-E-Mail, Chronikeintrag, Tagesprotokoll — oder keine davon. Die Antwort „no“ liefert sofort aus — aber die Behauptung wird inhaltlich geprüft: ein deterministischer Detektor untersucht die Datei, und Inhalt, der wie ein Brief oder Schriftsatz geformt ist (Anrede- und Schlussformeln in sechs Sprachen, ein Adressatenblock, juristische Merkmale, ein Identitätsblock), weist die Behauptung der Formlosigkeit zurück und protokolliert den Versuch; für solchen Inhalt gibt es keinen formlosen Weg. Die Antwort mit einer förmlichen Art gibt, weiterhin ohne auszuliefern, die verbindliche Formatierungsinstruktion für genau diese Art zurück, eingebettet in die Tor-Antwort; erst der wiederholte Aufruf mit dem Bestätigungskennzeichen, dass die Datei gegen diese Instruktion geprüft wurde, liefert tatsächlich aus. Ein Wächter der Versionsreihe verweigert zusätzlich die erste Auslieferung unter einem neuen Dateistamm, solange im Auslieferungsordner bereits eine versionierte Reihe mit derselben Fallnummer existiert — ein Dokument umzubenennen, um seinen Versionszähler zurückzusetzen, ist strukturell unmöglich; ein wirklich anderes Dokument verlangt eine bewusste, protokollierte Erklärung. Dieses Tor ist in der ausführbaren Datei des Front-Ends selbst umgesetzt, die die aktuelle Formatierungsinstruktion live von der Anwendung abruft. Dokumente und Briefe erreichen den Benutzer nie als Chattext oder Kopierfelder — jeder Schreibzugriff auf eine Text-Arbeitsdatei trägt diese Erinnerung, und das eine legitime Kopierfeld-Artefakt bleibt die E-Mail nach ihrem Format-Werkzeug.

Das Such-Tor: die zentrale Beweismittelsuche sucht bei ihrem ersten Aufruf nichts und fragt drei Dinge — welche Art von Stück gesucht wird (eingehendes Dokument, ausgehendes Dokument, Beweismittel mit angehängtem Dokument, Aussage/Transkript, Chroniknotiz oder unbekannt), den Umfang, wo eine Mandantenkennung vorliegt (nur dieser Fall, alle Fälle des Mandanten oder unbekannt — mit der Fallliste des Mandanten in der Frage), und die gewünschte Antwortform. Die Antwortformen sind: eine saubere Kennungsliste (die empfohlene Vorgabe; Treffer werden dann einzeln über den Beweismittel-Leser geöffnet), kompakte Treffer mit Trefferkontext oder das vollständige Ergebnis, geschrieben in eine einzige Zwischenspeicher-Datei.

Das Gesamtfall-Tor: der Gesamtfall-Leser lädt bei seinem ersten Aufruf nichts und meldet, wie groß der Fall tatsächlich ist — die Zahl der Beweismittel und das ungefähre aufsummierte Inhaltsvolumen über Titel, Beschreibungen, Dokument-Volltexte und Transkripte —, und bittet dann das Modell, zwischen gezielten Suchwerkzeugen und einem wiederholten Aufruf mit dem Argument für die Zwischenspeicher-Lieferung zu entscheiden, der den vollständigen, OCR-normalisierten Fallinhalt in den Zwischenspeicher schreibt und nur das Datei-Handle zurückgibt.

Das Prüf-Tor: für förmliche Schriftsätze verlangt das Auslieferungswerkzeug zusätzlich ein frisches Testat des deterministischen Schriftsatz-Prüfers. Dieser Prüfer scannt die fertige Zwischenspeicher-Datei über acht Behauptungsklassen — Beweismittelverweise in der Beilagenliste und im Fließtext (Stempel und Nummern, einschließlich dokumentgebundener Zitat-Herkunft: jedes zitierte oder beigefügte Stück muss für dieses Dokument als gelesen gelten — vollständig abgerufen oder seine Zwischenspeicher-Datei vollständig gelesen; ein Lesevorgang zählt zwei Stunden, jede Auslieferung desselben Dokuments verlängert dessen zitierte Stücke um zwei Stunden, und das Prüfen oder Ausliefern eines anderen Dokumentstamms setzt die Beilagen-Lesevorgänge zurück; eine Beilagenzeile darf einen Seitenbereich angeben, die Lesepflicht bleibt das ganze Dokument), Gesetzeszitate gegen die geprüfte Bibliothek (ein Artikel, der im geprüften Gesetzestext fehlt, ist ein widersprochener Befund; das Zitat verlangt zusätzlich eine Lese-Herkunft — jeder Lesevorgang in der Bibliothek wird je Programmlauf mit den tatsächlich zurückgegebenen Artikelnummern festgehalten, und ein zitierter Artikel ohne solchen Lesenachweis ist ein widersprochener Befund, sodass Presseartikel, Web-Zusammenfassungen und Modellgedächtnis nie eine Norm begründen können; zitierte Unterverweise wie Absatz und Punkt werden im Textbereich des Artikels auf Existenz geprüft; eine Quelle, die in der Bibliothek fehlt, sperrt, bis sie aufgenommen oder abgelehnt ist), wörtliche Zitate — jedes muss vollständig in den Volltexten des Falls oder in der Gesetzes-Bibliothek gefunden werden; ein Zitat, das in keiner Quelle gefunden wird, ist widersprochen und sperrt die Auslieferung, ein Zitat, dessen Anführungszeichen lediglich entfernt oder dessen Wortlaut leicht geändert wurde, bleibt gesperrt, und ganz gestrichene Zitate werden dem Benutzer bei der Auslieferung gemeldet —, dosar-Nummern, Beträge unter einer Nulltoleranz-Regel (die exakt aufgezeichnete Form), Partei-Stammdaten Buchstabe für Buchstabe einschließlich Diakritika, Personen-/Bankkennungen über die Prüfsummen-Validatoren und genannte Parteien — jede im Dokument genannte Person oder Firma aus dem Entitätenregister muss für dieses Dokument gelesen (Profil) und auf Verbindungen geprüft worden sein, wobei die Verweigerung beide Aufrufe nennt und den Cliquen-Test empfiehlt. Befunde werden als verifiziert, unverifiziert oder widersprochen eingestuft; jeder widersprochene Befund oder jedes ungeklärte fehlende Gesetz ergibt ein sperrendes Urteil. Das Testat bindet an den exakten Dateistand — jede Bearbeitung macht es ungültig —, und nach fünf gescheiterten Prüfläufen bricht die Schleife hart ab, weist das Modell an, anzuhalten und zu berichten, und benachrichtigt den Benutzer direkt in der Anwendung.

Das Zustimmungs-Tor für Gesetzesquellen: eine vom Modell gemeldete Gesetzesquelle wird nicht mehr stillschweigend aufgenommen. Anforderungen sammeln sich in einem einzigen Zustimmungsdialog in der Anwendung — Quelle, Rechtsraum, anfordernde KI —, wo angehakte Einträge abgerufen, geprüft und gespeichert werden (mit sofortigem Anstoß des Workers) und nicht angehakte Einträge abgelehnt werden; eine abgelehnte Quelle macht spätere Zitate daraus zu sichtbaren Vermerken „auf Entscheidung des Benutzers unverifiziert“ statt zu stillen Sperren. Der Datenmonitor führt Gesetze danach nur noch für den periodischen Prüfzyklus.

Die Regel der Auslieferung nur aus der Ablage: das Auslieferungswerkzeug akzeptiert ausschließlich einen Quellpfad innerhalb der Arbeitsablage der Anwendung; Inline-Inhalt und Pfade außerhalb der Ablage werden für jeden Dateityp verweigert. Das hält das Prüf-Testat, die Verfolgung der Neuauslieferung, die Versionierung und die Lese-Deckung ausnahmslos an jedem ausgelieferten Artefakt.

9. Sitzungsstart und Rahmung

Das Öffnen des Sitzungsstart-Toolsets führt das gesamte Startprotokoll in einem Zug aus und schreibt es in eine feste, benannte Zwischenspeicher-Datei; die direkte Antwort gibt nur den Datumsanker, die Systemsprache und den aktuellen GUI-Kontext zurück, und das Modell liest den Rest — fällige Gedächtniseinträge, das Tagesbriefing, Fristen, Termine, offene Peer-Aufgaben und das Verzeichnis der letzten zehn Tagesprotokolle — mit einem einzigen Zwischenspeicher-Lesevorgang. Die Mitglieder dieses Toolsets führen einzelne Teile auf Wunsch erneut aus.

Das Datum-und-Uhrzeit-Werkzeug antwortet mit einer Zeile (Datum, Uhrzeit, Zeitzone, Wochentag, wo möglich NTP-synchronisiert, sonst Systemuhr) und trägt das ständige Gebot, dass jeder Dialogschritt mit dem aktuellen Datum beginnt und dass Daten nie geraten werden. Das GUI-Kontext-Werkzeug meldet, welcher Bildschirm des Hauptfensters der Anwendung geöffnet ist, mit Breadcrumb und dem geöffneten Mandanten und Fall. Das Systemsprache-Werkzeug gibt die Sprachkennung zurück, die Dialog und fallübergreifende Listen bestimmt; das Rechtsraum-Werkzeug gibt je Fall den Rechtsraum zurück, der erzeugte Dokumente und Terminologie bestimmt, ist vor jeder Dokumentarbeit Pflicht und weist an, den Benutzer zu fragen, wenn er nicht gesetzt ist. Das Morgenbriefing-Werkzeug gibt das strukturierte Briefing von heute mit Kennungen und Markierungen zurück, sodass das Modell auf jeden Punkt hin handeln kann; das Arbeitsbriefing-Werkzeug verfolgt je Desktop-KI, ob diese KI heute bereits gebrieft wurde, und gibt die letzten Tagesprotokolle nur beim ersten Kontakt des Tages zurück.

10. Der Zwischenspeicher

Der Zwischenspeicher ist der Arbeitsordner des Modells für alles Große. Er bietet Schreiben mit Anhängefähigkeit für den stückweisen Aufbau; zeilennummeriertes bereichsweises Lesen, dessen Nummern direkt auf die zeilenbasierten Editoren abbilden; exakte Textersetzung mit Eindeutigkeitserfordernis, einen gegenüber Leerraum und typografischen Anführungszeichen toleranten Wiederholungsversuch, der weiterhin Eindeutigkeit verlangt, und einen angewiesenen Rückfall auf Auffinden-und-Kopieren bei jeder anderen Abweichung; Einfügen nach Zeilennummer oder nach einer Marke; Löschen eines Zeilenbereichs; atomares Ersetzen eines Zeilenbereichs als sichere Umstrukturierungsoperation; gegenüber Groß-/Kleinschreibung und Diakritika unempfindliche Mustersuche über eine oder alle Dateien mit einer Kappung bei fünfzig Treffern und optionalen Kontextzeilen; eine Markdown-Gliederung, die Überschriften auf Zeilenbereiche abbildet, ohne die Datei zu lesen; eine Verzeichnisliste; Kopieren; einen Zeilen-Diff zwischen zwei Dateien, der gemeinsame Zeilen ausblendet; eine auslieferungsorientierte Normalisierung, die strukturelles Markdown auf die Schriftsatzkonventionen einebnet, Verweise schützt, kurze Beweismittelverweise auf sieben Stellen auffüllt und Zeilenenden normalisiert; die Vereinheitlichung des Leerraums; die Bereinigung von Zeilenenden und unsichtbaren Zeichen; destruktive vereinheitlichte Projektionen (ein kleingeschriebenes Vergleichsskelett oder nur die Diakritika-Faltung) immer in eine getrennte Zieldatei; Wort-, Buchstaben- und Zeilenzähler; und das Löschen.

Ein leichtgewichtiges Zustandsregister merkt sich Schlüssel-Wert-Notizen für die laufende Sitzung — vor allem, welche Datei der aktuelle Hauptentwurf ist — mit der Semantik Abrufen, Setzen und Löschen, und übersteht Neustarts der Anwendung.

Lebenszyklus: der Speicher ist langlebig und übersteht Neustarts; die eigenen Notizen des Modells, das Zustandsregister, die Dateimetadaten und die Buchführung der Lese-Deckung bleiben erhalten, während Werkzeug-Dumps früherer Tage bei jedem Start bereinigt werden und Dateien, die einhundertachtzig Tage unberührt sind, bereinigt werden. Jeder Zugriff über irgendein Zwischenspeicher-Werkzeug — auch ein bloßes Lesen — setzt die Löschuhr dieser Datei zurück; ein bloßes Erscheinen in der Verzeichnisliste tut das nicht. Die Instruktionsschicht verpflichtet das Modell, seine Aufgabendateien zu löschen, wenn eine Aufgabe endet, und dauerhafte Erkenntnisse stattdessen ins Gedächtnissystem zu übertragen.

11. Das Gedächtnissystem

Das dauerhafte KI-Gedächtnis ist ein chatübergreifendes Notizbuch, das alle verbundenen KIs und der In-App-Assistent teilen. Ein Eintrag fasst höchstens eintausend Zeichen — die Toolset- und Werkzeugbeschreibungen verlangen die Verdichtung auf das absolut Wesentliche und das Aufteilen größeren Materials — und ist mindestens mit einem Mandanten oder einem Fall verknüpft (bei einer Fallverknüpfung wird der Mandant automatisch abgeleitet und korrigiert) sowie optional mit einem Beweismittel, einer E-Mail, einer Entität oder einer Institution, alles validiert. Einträge müssen unabhängig von der Dialogsprache in der IRONSTICK-Systemsprache geschrieben werden, und dem Modell ist es verboten, seine eigenen privaten Gedächtnisdateien für Fallwissen zu verwenden, da diese weder die Peer-KI noch den Benutzer erreichen. Ein optionales Fälligkeitsdatum macht einen Eintrag fristähnlich: fällige und überfällige Einträge erscheinen zuerst im Sitzungsstart-Protokoll und in den Fristenansichten der Anwendung.

Die Suche ist nach jeder der verknüpften Kennungen und nach dem Fälligkeitsdatum filterbar (alles, genau heute oder ein Fenster von zehn Tagen um ein gegebenes Datum), liefert die neuesten zuerst mit einer Vorgabe von zwanzig und einem Maximum von fünfzig Treffern und kennzeichnet vom Benutzer verfasste Notizbucheinträge als für die KI strikt schreibgeschützt. Das Aktualisieren ersetzt Text und/oder verschiebt, setzt oder löscht das Fälligkeitsdatum; alles nicht Übergebene bleibt unverändert. Eine Aktualisierung, deren Text die Grenze überschreitet, wird mit einer Kapazitätsangabe abgewiesen, die die eingereichte Länge, die Grenze, die aktuelle Belegung des Eintrags und den freien Rest nennt; jede erfolgreiche Textaktualisierung meldet ebenso Belegung und Rest; in beiden Fällen hängt die Antwort, sobald weniger als dreihundert Zeichen frei bleiben, die ständige Empfehlung an, entweder den ganzen Eintrag zu überarbeiten oder einen zusätzlichen Eintrag anzulegen und im alten einen Querverweis zu hinterlassen. Das Löschen ist unumkehrbar und verweigert Notizbucheinträge des Benutzers und Aufgabeneinträge. Die Pflege ist für lang laufende Verfahren gebaut: mit einem Fall verknüpfte Einträge sind von der Ein-Jahres-Bereinigung ausgenommen, solange dieser Fall aktiv ist — sie fallen erst, wenn der Fall inaktiv gesetzt oder archiviert wird (was seine Einträge sofort bereinigt) oder wenn der Mandant gelöscht wird; die Ein-Jahres-Bereinigung gilt nur für Einträge ohne Fall. Zudem frischt jeder Eintrag, den eine Gedächtnissuche zurückgibt, und jede Aktualisierung eines Eintrags dessen Lebensdauer auf, und die Bereinigung misst das Alter am jüngsten Zeitpunkt von Anlage und letztem Zugriff — ein Eintrag, der tatsächlich genutzt wird, verfällt nie; nur totes Material altert aus. Notizbucheinträge des Benutzers verfallen nie automatisch.

Stammdaten, Personen, Beziehungen und Dokumente gehören nicht ins Gedächtnis: die Beschreibungen leiten sie zu den Vorschlagswerkzeugen und zur Dokumentenerfassung.

12. Fristen, Termine und der Kalender

Die Fristenwerkzeuge liefern die aktiven Fristen entweder kompakt (Titel, Fälligkeitsdatum, verbleibende Tage, Fall, wobei als geheim markierte Einträge ausgeschlossen sind) oder mit Beschreibungen je Eintrag und ausdrücklichen Kennzeichnungen für überfällig und dringend (dringend heißt zehn Tage oder weniger), sowie eine Vortragsform, nach Dringlichkeit geordnet, mit Zeitraumfiltern (alle nach Kritikalität gruppiert, nur kritische, bald fällig, heute, diese Woche, nächste Woche oder ein bestimmtes Datum). Das Terminwerkzeug trägt einen Tag oder Zeitraum vor, Gerichtstermine zuerst — aus dem Portal importierte Gerichtstermine, dann Gerichtstermine aus dem Kalender, dann die übrigen Kalendereinträge. Der Kalenderleser führt Einträge global oder je Fall mit optionalem Datumsbereich auf.

Das Kalender-Erfassungswerkzeug schreibt nie: es öffnet das Kalenderformular der Anwendung, vorausgefüllt mit Titel, Datum, Zeiten, Beschreibung und optionaler Fallverknüpfung, und der Benutzer vervollständigt und speichert. Seine Beschreibung schreibt vor jedem Aufruf eine verpflichtende Dublettenprüfung vor: zuerst den Kalender desselben Tages lesen, nur nach Datum vergleichen und dabei Zeiten ignorieren, bei jedem ähnlichen Eintrag diesen dem Benutzer zeigen und fragen, ob es dasselbe Ereignis ist, und das Werkzeug erst aufrufen, nachdem der Benutzer einen neuen Eintrag bestätigt hat.

13. Das Tagesjournal

Das Journalsystem schreibt und liest das fallübergreifende Tagesprotokoll. Das Anhängen zielt auf einen Tag (Vorgabe heute, wobei das Datum über das Zeitwerkzeug abgerufen wird), hängt an einen bestehenden Tag immer mit einem Trenner an und überschreibt nie, verknüpft betroffene Fälle über eine Fallliste und erwartet den Inhalt als sauberes Markdown im Protokollstil, der im Anhang der Instruktion festgelegt ist. Ein Notizwerkzeug fügt eine einzelne Ereigniszeile mit optionalem Fallbezug ins heutige Protokoll ein. Das Formatwerkzeug gibt das verbindliche Dateiformat des Protokolls zurück. Das Lesen funktioniert nach Datum, Bereich oder neueste zuerst, mit Volltextoption und Eingrenzung auf einen Fall; das Suchen ist eine diakritika-unempfindliche Stichwortsuche über Titel und Volltexte mit Datum, Titel und Kontextauszug je Treffer. Beide Listenformen haben eine Vorgabe von zehn und eine Kappung bei dreißig Einträgen. Das Öffnen des Toolsets liefert bereits das heutige Protokoll vollständig mit einem Hinweis, wie viele weitere Protokolle in den letzten zwei Wochen existieren.

14. Fallzugriff

Die Fallauflösung funktioniert nach Fallnummer, nach dem Namen einer beteiligten Partei (diakritika-tolerant, über Gegner, Kläger, Titel und Mandant — Pflicht, wann immer der Benutzer eine Partei ohne Nummer nennt, da viele Fälle gar keine Nummer tragen) und über die Fallliste des Mandanten. Verwandte Verfahren kommen aus der Fallhierarchie als Eltern-, Kind- und Gleiche-Gruppe-Einträge.

Das Schnellübersichts-Werkzeug gibt in einem Aufruf jedes Feld des Fall-Reiters, jedes Feld des Mandanten-Reiters, eine optional verknüpfte Portalakte und die letzten fünfzehn Beweismittelkennungen mit Eingangsdatum zurück — gedacht als Orientierung vor jedem Volltextzugriff. Der Chronikleser gibt die Chronik eines Falls zurück, neueste zuerst, kompakt und ohne Volltexte, mit Datumsfiltern und einer Grenze von bis zu fünfzig Einträgen, und ist die vorgesehene schnelle Antwort auf „was ist zuletzt passiert“ — er zählt nichts für die Fallvorbereitung.

Die Fallvorbereitung ist ein Werkzeug und ein Tor. Das Vorbereitungswerkzeug liefert in einem Aufruf den Kopf (Profil und Rechtsraum) und den Digest jedes Dokuments — Kennung, Datum, Typ, Titel, die Zusammenfassung vom Erfassungszeitpunkt, Querverweise und Volltextgröße —, der die Chronik ist; eine zweite Auflistung derselben Zeilen wurde als reine Token-Verschwendung gestrichen. Die Antwort beginnt immer mit einem Hinweis, wo Kopf und Digest liegen (inline, wenn die ganze Antwort unter der Konnektor-Grenze bleibt, sonst als zwei Zwischenspeicher-Dateien, die vollständig gelesen werden müssen), und nennt die fünf neuesten Dokumente, die vollständig zu lesen sind. Das Vorbereitungs-Tor verweigert externen Aufrufern dann zwei Stufen von Fallausgaben: eine Notiz oder einen Eintrag zu einem Fall (Journal, Tagesnotiz, Chronikeintrag, Fallnotiz), bis Profil, Rechtsraum, Digest und die fünf neuesten Chronikeinträge (Notizen ohne PDF oder Transkript; Bilder erlaubt) vollständig gelesen sind — sodass eine laufende Reihe von Chronikeinträgen die letzten beachtet, ohne dass für eine bloße Notiz schwere Dokumente gelesen werden müssen; ein Urteil über den Fall (Schriftsatz-Prüfung, Übergabe, Export) zusätzlich, bis jedes zitierte oder beigefügte Dokument vollständig gelesen ist. Lesevorgänge werden je Desktop-KI in einem gespeicherten Buch gebucht, gültig drei Tage oder bis zum nächsten eingehenden Dokument des Falls; ausgehende Dokumente und Beweismittel-Datensätze machen einen Lesevorgang nie ungültig. Dasselbe Buch speist das Aufklappmenü am Symbol der KI. Eine dritte, niedrigere Stufe bewacht den Fallinhalt selbst: jedes Fallinhalts-Werkzeug — Chronik, Zeitleiste, Stichwort-, Passagen- und Zeitraumsuchen, Volltexte, Widersprüche, Aussagen, Pflichten, Fristen, Kalender, Korrespondenz, Verwendung, eingereichte Beilagen, Briefketten, Beilagenlisten, Stempel, Medien, Institutionen, Tags, Bewertung und Instruktionsnotizen — wird für einen Fall verweigert, dessen Digest der Aufrufer nicht gelesen hat, wobei die Verweigerung das Vorbereitungswerkzeug nennt; der dritte verweigerte Versuch am selben Fall wird als Regelverstoß gebucht. Die Vorbereitungszähler werden bei jedem Lesen der Instruktionen und bei jedem Sitzungsstart zurückgesetzt.

Das vollständige Lesen eines Falls ist torgeschützt, wie in Abschnitt 8 beschrieben. Der Zwischenspeicher-Dump ist der schnellste vollständige Weg: er stellt den gesamten Falltext innerhalb der Anwendung zusammen, ungekürzt, normalisiert OCR-Anomalien (wiederholte Leerzeichen, gemischte Zeilenenden, geschützte Leerzeichen, weiche Trennstriche, Zeichen ohne Breite), schreibt ihn direkt in den Zwischenspeicher und gibt nur das Handle mit Statistik zurück; sehr große Fälle werden in nummerierte Teildateien aufgeteilt. Umfangsfilter beschränken den Dump auf die eingehende, die ausgehende oder beide Richtungen, und eine Liste von Beweismittelkennungen dumpt genau diese Datensätze — der vorgesehene Weg, ein sehr großes Dokument vollständig zu lesen, wobei der Fall aus dem Beweismittel abgeleitet wird.

Der Beweismittel-Leser ist die verpflichtende Grundlage für jede inhaltliche Aussage: er lädt einen Datensatz mit seinem extrahierten Dokument-Volltext (vollständig und ungekürzt; oberhalb der Konnektor-Grenze kommt er als Ganzes im Zwischenspeicher an) und, wo vorhanden, dem Chat- oder Transkript-Volltext (der Messenger-Chats sowie Telefon-, Verhandlungs-, Vernehmungs- und Gerichtsprotokolle abdeckt), dazu die qualifizierte Zusammenfassung, Beschreibung und Metadaten, die ausdrücklich nicht als Ersatz für den Volltext gelten. Erscheint keiner der beiden Volltextabschnitte, existiert kein extrahierter Text, und das Modell darf keine inhaltlichen Behauptungen über den Datensatz aufstellen. Eine Kommaliste von bis zu zwölf Kennungen liest mehrere Datensätze in einem Aufruf. Ein Medieninventar-Werkzeug meldet Existenz, Typ, Datum und Größe von Bild-, Audio- und Videoanhängen eines Datensatzes oder Falls und stellt ausdrücklich fest, dass Medieninhalt nicht als Text lesbar ist und das Werkzeug existiert, damit ein Datensatz, der nur Medien enthält, nicht fälschlich als leer eingestuft wird.

Tags erscheinen als frei formulierte Haftnotizen des Benutzers an Beweismittel-Datensätzen — der Text ist die Information, die Farbe hat keine feste Bedeutung, und ein mit Tag versehener Datensatz gilt als starkes Relevanzmerkmal. Drei Modi liefern eine globale Übersicht mit Zählungen und referenzierten Datensätzen, alle Tags eines Falls oder eine Textsuche in Tag-Texten, mit einem Umfangsfilter, der persönliche von fallgebundenen Tags trennt. Sachverhaltsgruppen führen die gesamte Falllandschaft eines Mandanten als Gruppen mit verschachtelten Fällen einschließlich der Eltern-Beziehungen im Baum auf. Die gespeicherte Fallbewertung ist je Fall abrufbar.

15. Suche in der Akte

Die zentrale Beweismittelsuche bewertet über alle Beweismittelfelder, die extrahierten Dokument-Volltexte und die Transkriptinhalte, mit konjunktiv verknüpften Mehrwortanfragen, Diakritika-Unabhängigkeit und einem Phrasenbonus; Ergebnisse sind nach Relevanz geordnet, ohne Punktzahlen offenzulegen, jeder Treffer benennt, welches Feld ihn ausgelöst hat, die Vorgabe ist fünfzehn und das Maximum dreißig Treffer, und die Antwortform folgt der Tor-Wahl aus Abschnitt 8. Die Passagensuche zerlegt Dokumente und Transkripte in Absatz- und Satzfenster und gibt die am besten passenden Passagen mit ihrem Verweis zurück — sie ortet, wo in einem Text etwas steht, nicht bloß in welchem Datensatz —, mit OCR-tolerantem Abgleich, der Erfassungsfehler überbrückt, einem Phrasenbonus und der Eingrenzung auf genau einen Fall oder auf alle Fälle genau eines Mandanten (das vorgesehene Instrument für Fragen der Art „hat X jemals, irgendwo“; nie mandantenübergreifend), mit einer Vorgabe von acht und einer Kappung bei zwanzig Passagen. Ein Datumsbereichs-Werkzeug führt Beweismittel zwischen zwei Daten auf. Der eigene Finder für Korrespondenz einer Partei ist Pflicht, wenn der Benutzer nach Dokumenten von oder an eine bestimmte Partei fragt: er gleicht die Partei diakritika-tolerant gegen die Beteiligungs-Datensätze ab, filtert nach Richtung (an mich, von mir oder beides), schließt Chats und Transkripte aus, blendet selbst erstellte Screenshots standardmäßig aus und nennt dabei ihre Zahl, und ordnet die neuesten zuerst — ausdrücklich unterschieden von der Stichwortsuche, die auch Datensätze zurückgäbe, die die Partei bloß erwähnen.

16. Deterministische Analysewerkzeuge

Diese Werkzeuge rechnen aus den Datensätzen ohne jede Beteiligung einer KI. Die Zeitleiste gibt alle Stücke eines Falls zurück, nach Ereignisdatum absteigend geordnet, mit Verweis, Zeitstempel, Datensatztyp und Titel, mit einer Vorgabe von dreihundert und einer Kappung bei fünfhundert Stücken. Der Widerspruchssammler urteilt bewusst nicht: er sammelt bis zu einhundertzwanzig Kandidaten (Vorgabe sechzig), optional auf eine Entität gefiltert, mit Verweis, Datum, Beteiligten und Kurzinhalt, und überlässt das Urteilen und die anschließenden Volltext-Lesevorgänge dem Modell. Das Wer-sagte-was-Werkzeug findet jedes Stück, in dem eine Person vorkommt — als Beteiligter, in Titel oder Text oder im Wortlaut eines Transkripts —, diakritika-unabhängig, kennzeichnet die Quelle jedes Treffers, mit einer Vorgabe von vierzig und einer Kappung bei einhundert. Das Beteiligtennetz-Werkzeug zählt, welche Personen und Entitäten in denselben Stücken gemeinsam vorkommen, global oder je Fall, optional auf eine Entität fokussiert. Das Pflichtenwerkzeug führt offene, mit Frist gekennzeichnete Stücke nach Fälligkeitsdatum auf, mit Tageszählung, Beschreibungen, Verweisen und der Kennzeichnung überfällig/dringend.

Fünf weitere deterministische Werkzeuge dienen der Charakterisierung einzelner Richter und Staatsanwälte; als Entscheidungen zählen nur eingehende Dokumente eines Gerichts oder einer Staatsanwaltschaft. Der Entscheidungslister gibt jede Entscheidung zurück, an der eine Person als Richter mitgewirkt oder als Staatsanwalt gehandelt hat, über alle Fälle hinweg, und zählt nur einen Namen im Kopf (Besetzung des Gerichts) oder im Unterschriftenblock — ein Name im Fließtext zählt nicht, und Gerichtsschreiber werden nie aufgeführt. Der Strukturleser zerlegt eine Entscheidung in Gericht, Abteilung, Fallnummer, Art, Nummer und Datum, Sitzung, Spruchkörper, den Satz, der Parteien und Gegenstand nennt, den Tenor wörtlich, Ergebnis-Schlagwörter, Rechtsmittel, Verkündung, Gesetzeszitate mit ihrem Bibliotheksstatus und den Umfang der Begründung, jeweils mit der Zeichenposition, und meldet Fehlendes als nicht gefunden. Der Eingabensammler schreibt jede Eingabe, die im Fall bis zum Datum der Entscheidung eingereicht wurde, in zwei Zwischenspeicher-Dateien — die ausgehenden Dokumente des Mandanten und die eingehenden der Gegenseite —, beschränkt auf Dokumente, die an ein Gericht oder eine Staatsanwaltschaft gerichtet sind, jede nur mit ihrem Hauptdokument (Begleit-E-Mail und Beilagen abgeschnitten), und führt als nicht zugeordnet auf, was sich nicht einordnen lässt; seine Dateien tragen die Lesepflicht. Der Entscheidungsvergleich misst, welcher Anteil der eigenen Begründung des Gerichts als Text mit den Eingaben des Mandanten, mit denen der Gegenseite, mit beiden, mit Gesetzestext der Bibliothek oder mit nichts (die eigene Formulierung des Gerichts) übereinstimmt, misst die Wiedergabe der Standpunkte der Parteien gesondert und führt die übereinstimmenden Passagen mit ihrer Übereinstimmungsquote ab siebzig Prozent aufwärts auf, die höchste zuerst, im Originalwortlaut mit Zeichenpositionen. Der Dokumentenvergleich hält zwei beliebige Dokumente über Mandanten und Fälle hinweg gegeneinander, stuft übereinstimmende Passagen als Gesetzestext, als gemeinsame zitierte Quelle oder als nur von diesen beiden geteilt ein und beginnt seine Antwort mit dem Hinweis, dass er nur einen ersten Eindruck gibt und dass beide Dokumente vollständig gelesen werden müssen, bevor irgendetwas über eine Verbindung ausgesagt wird.

Die Familie der Einreichungsverfolgung arbeitet deterministisch gegen die gespeicherten Schriftsätze: das Verwendungswerkzeug beantwortet für ein Beweismittel, welche Beilagen es physisch enthält und in welchen Schriftsätzen es selbst eingereicht wurde (mit Datum und Aktenzeichen, fallübergreifend), oder für einen Fall den Lückenbericht der nie eingereichten Stücke; der Lister eingereichter Beweismittel gibt je gespeichertem Schriftsatz die beigefügten Kennungen sowie die deduplizierte Gesamtmenge zurück und ist Pflicht, bevor die Beilagenliste eines neuen Schriftsatzes zusammengestellt wird, mit dem dokumentierten Vorbehalt, dass nur strukturell beigefügte Beilagen erfasst sind. Die Registraturnummern-Kette findet, ausgehend von einer Briefnummer oder von allen in einem Dokument vorkommenden Nummern, jedes Dokument, das diese Nummer teilt, in chronologischer Reihenfolge — der dokumentierte Gang eines Verwaltungsverfahrens. Der Beilagenlister löst die physisch enthaltenen Beilagen eines Dokuments auf, einschließlich des deterministischen Einreichungsstempels je Beilage; das Stempelwerkzeug löst jede Beweismittelkennung zu ihrem deterministischen Einreichungsstempel auf (mehrere gespeicherte Dateien ergeben mehrere Stempel; ein Datensatz ohne gespeicherte Datei ergibt eine ausdrückliche Leermarkierung). Beide stempelführenden Werkzeuge verbieten das Erfinden von Stempeln — sie müssen immer abgerufen werden.

17. OCR-Heilung

Ein vierstufiger Eskalationsweg repariert ruinierte gespeicherte Volltexte und ist ausdrücklich von der Verwendung als bequemer Leseersatz ausgeschlossen. Die Rescan-Anforderung bittet die Anwendung, das gespeicherte Original-PDF erneut per OCR zu erfassen; der Benutzer wählt die Seiten in IRONSTICK, und das Modell ist angewiesen, den Benutzer in einem Satz zu informieren und zu warten. Das Statuswerkzeug ist einmal aufzurufen, wenn der Benutzer sagt, dass die Seiten gewählt wurden — Abfrageschleifen sind verboten —, und gibt, wenn der Scan bereit ist, den Arbeitsauftrag zusammen mit zwei Zwischenspeicher-Dateien zurück, die den frischen Scan und den aktuellen Datenbanktext enthalten. Die Regel für Vergleich und Heilung erlaubt nur mechanische OCR-Korrekturen, nie Umformulierungen, wobei Zahlen, Namen und Beträge exakt bleiben. Wo eine Stelle in BEIDEN Quellen unlesbar ist, darf das Modell den Benutzer vor dem Einreichen um eine Sichtprüfung bitten — höchstens drei Punkte je Dokument, wobei der Datensatz an der genauen Stelle geöffnet und die Stelle präzise benannt wird („Seite 7, zweiter Absatz — der Betrag?“); bei deaktivierter Navigation werden Datensatz und Seite stattdessen im Chat genannt. Das Einreichungswerkzeug übergibt die geheilte Zwischenspeicher-Datei an die Anwendung, die sie dem Benutzer in einem Modal zeigt; erst das Speichern durch den Benutzer ersetzt den Datenbanktext, und nichts wird automatisch gespeichert. Die letzte Eskalation, die Anforderung der PDF-Übergabe, öffnet den Datensatz und lässt das Modell den Benutzer bitten, das Original-PDF persönlich in den Chat zu ziehen — die Bridge bietet bewusst keine Pfadhilfe, verweigert hart, wenn kein Rescan vorausging, und verweigert PDFs über zehn Megabyte oder über neunzig Seiten; das Modell liest das PDF dann visuell, baut die geheilte Fassung im Zwischenspeicher auf und reicht sie durch dasselbe Prüf-Tor ein. Bei einer Verweigerung wegen Größe oder Seitenzahl endet der Ablauf nicht: der Abschrift-Ausweichweg öffnet den Datensatz dennoch, und das Modell bittet den Benutzer, das PDF über die Büroklammer zu öffnen und die entscheidenden Stellen wörtlich abzutippen („Seite X, oben, dort müsste stehen … — bitte tippen Sie es genau ab“) — höchstens drei Stellen, wörtlich in die geheilte Fassung übernommen; jede verbleibende Lücke wird offen ausgewiesen. Der Anwalt handelt damit als visuelles Präzisionsinstrument für genau den Bruchteil eines Scans, den die Maschine nicht auflösen kann, statt das Dokument manuell zu verarbeiten.

18. Personen, Institutionen, Mandanten und Datenvorschläge

Auflösungswerkzeuge finden Mandanten, Personen und Institutionen nach Namensbruchstück, diakritika-tolerant; ein Stichwortfinder durchsucht Namen, Notizen und Analysefelder, wenn nur ein Bruchstück bekannt ist. Ein deterministischer Listen-Abgleich gleicht ein Dokument, das eine Namensliste enthält, gegen alle aktenkundigen Personen und Firmen ab, adressiert über die Beweismittelkennung oder über den Fall — dann wird der neueste Eintrag des Falls gescannt und in der Antwort benannt. Auf den Verbindungen zu Claude und ChatGPT nimmt die Parteienprüfung die nächsten Parteien im Voraus entgegen und sucht sie im Hintergrund, während die aktuelle abgearbeitet wird; Ergebnisse bleiben dreißig Minuten erhalten, und die Reihenfolge des Tors bleibt unverändert. Netzwerkwerkzeuge führen alle auf, die mit einer Partei über ausdrückliche Beziehungen und gemeinsame Fälle verbunden sind, die Cliquen des gesamten Parteiennetzes nach deterministischer Community-Erkennung (genau die Universum-Ansicht des Personen-Bildschirms, mit einem Verdachtskennzeichen für ungewöhnlich dichte Gruppen und einer optionalen Trennung von Personen und Institutionen in Ebenen) und die am stärksten verbundenen Parteien; jede parteibezogene Antwort beginnt mit dem Block der Fälle, mit denen die Partei verknüpft ist. Der Profilleser gibt jedes Stammdaten- und Analysefeld vollständig und ungekürzt zurück. Profilleser geben das Entitätsprofil mit Analyse und Beziehungen, alle Beziehungen einer Person in beiden Richtungen über Personen und Institutionen, das Institutionsprofil und die förmlich mit einem Fall verknüpften Institutionen zurück. Der Zeiterfassungsleser meldet passiv gemessene Arbeitszeit (jeder Seitenaufruf dauert bis zum nächsten, begrenzt auf dreißig Minuten, der letzte zählt als eine Minute) als Übersicht der Summen und der Spitzen bei Fällen, Mandanten und Tagen oder als Aufschlüsselung eines Falls je Tag, über einen Datumsbereich oder ein Fenster der zurückliegenden Tage mit der Vorgabe sieben.

Direkt in Stammdaten zu schreiben ist unmöglich. Zwei Vorschlagswerkzeuge legen Befunde als Prüfposten in den Datenkonsistenz-Monitor der Anwendung: der Stammdatenvorschlag (erst nachdem der Benutzer im Chat bestätigt hat, dass der Befund abgelegt werden soll) zielt auf eine bestehende Entität oder Institution — zuerst nach Namen aufgelöst — oder beschreibt einen neuen Datensatz mit Namen und Feldern, mit einer Liste zulässiger Felder, in der Firmen- und Personen-Identifikationsnummern ein Feld teilen, nur belegte Felder zulässig sind und Beweismittelverweise optional sind; der Beziehungsvorschlag beschreibt eine Beziehung zwischen zwei aufgelösten Personen oder zwischen einer Person und einer Institution, mit genau einem Gegenüber, einer Pflichtkategorie, einer optionalen Begründung und optionalen Fall-, Mandanten- und Beweismittelverweisen. Ein Vorschlag darf auch einen Datensatz umbenennen (Feld Name), seine Art setzen (Feld PersonKind: natürlich oder juristisch), die Kategorie einer bestehenden Beziehung ändern, eine Löschung vorschlagen (eines Datensatzes, eines Tags oder einer erledigten Frist) mit einer Begründung in der Systemsprache, die Pflicht ist, oder zwei Datensätze als Dubletten vorschlagen; ein neuer Datensatz wird erst angenommen, nachdem die Art im Dialog entschieden wurde, und ein Vorschlag, der die Beschreibung oder die Kontaktdaten einer Person berührt, wird verweigert, solange der Aufrufer dieses Profil nicht innerhalb der letzten dreißig Minuten gelesen hat. In beiden Abläufen ändert sich der Datensatz erst, wenn der Benutzer den Vorschlag im Monitor annimmt. Ein Vorschlag für einen neuen Datensatz wird zunächst mit der Liste ähnlicher bestehender Datensätze beantwortet — locker abgeglichen, nichts gespeichert —, und der Aufrufer muss entweder bei einem davon ablegen oder per Parameter ausdrücklich bestätigen, dass die Partei wirklich neu ist; ein strenger Treffer wird auf den bestehenden Datensatz umgeleitet. Jede gespeicherte neue Partei liefert einen verpflichtenden Folgeauftrag zurück, der den Aufrufer anweist, die Verbindungen der Partei zu recherchieren und abzulegen, Webrecherche eingeschlossen. Ein drittes Vorschlagswerkzeug ordnet eine Partei einem Fall zu: genau eine Entität oder Institution, eine Pflichtbegründung und optionale Beweismittelverweise werden zu einem Fallverknüpfungs-Prüfposten im selben Monitor; die Annahme schreibt die Beteiligtenverknüpfung, auf der die Cliquen- und Verbindungsansichten aufbauen, während eine bestehende Verknüpfung, eine anhängige Dublette oder eine frühere Ablehnung gemeldet statt erneut vorgeschlagen wird. Die Anwendung zählt außerdem Vorschläge je Aufrufer: nach zwei gespeicherten Stammdatenvorschlägen und einem Beziehungs- oder Fallverknüpfungsvorschlag behandelt sie die Sitzung als Pflege des Parteiennetzes, hängt einmal den Hinweis an, dass diese vollständig torgesicherte Arbeit kein Spitzenmodell braucht, und hält — im In-App-Chat — den Lauf auf der mittleren Modellklasse. Unabhängige Hintergrundprozesse speisen denselben Monitor: ein an der Quelle deduplizierter Datenextraktor und ein periodischer Normalisierungsscan, der Zusammenführungen und Umklassifizierungen entlang des Drei-Kategorien-Modells vorschlägt (natürliche Person; juristische Person als jede Körperschaft, die kein einzelner Mensch ist, wobei ein Handelsregistereintrag staatliches Eigentum übertrifft; Institution als staatliche Stellen ohne Registereintrag) — nie mit automatischer Zusammenführung.

19. Die Gesetzes-Bibliothek

Die Bibliothek hält vollständige Gesetzestexte als Markdown-Dateien mit einer internen Registrierungsnummer je Gesetz. Das Listenwerkzeug blättert durch das Inventar (Kennung, Rechtsraum, Titel, Art, Dateiname, Datum der letzten Prüfung; Vorgabe fünfzig, Maximum fünfhundert) und ist nur lesend. Das Suchwerkzeug ist Pflicht vor jeder Internetsuche nach einer Norm: es gleicht entweder nach Bezeichnung gegen Titel und Beschreibung oder nach zitierter Passage mit unscharfer Toleranz ab (rund sechzig Prozent der Wörter genügen, und Wortendungen werden toleriert), verlangt den aus dem Fall übernommenen Rechtsraum, reiht Titeltreffer weit über Inhaltstreffer (ein Titeltreffer zählt neun Zehntel, jeder Inhaltstreffer ein Zehntel, höchstens drei Ausschnitte je Datei) und gibt je Treffer die Registrierungsnummer, den Dateinamen, kurze Ausschnitte mit ihren exakten Zeichenpositionen und einen fertigen Aufruf für den wörtlichen Auszug zurück, dessen Bereich bereits vergrößert ist — um mindestens fünfhundert Zeichen über den Ausschnitt hinaus —, sodass das Modell den maßgeblichen Wortlaut selbst abruft, statt dem Ausschnitt zu vertrauen. Das Auszugswerkzeug gibt den wörtlichen Inhalt eines Gesetzes zwischen zwei Zeichenpositionen zurück, adressiert über die Registrierungsnummer, auf die Datei begrenzt, mit einem vorangestellten Hinweis, dass der Bereich angepasst werden kann und dass das ganze Gesetz ladbar ist, wobei übergroße Ergebnisse automatisch in den Zwischenspeicher umgeleitet werden; der Ziffernabgleich in Gesetzessuchen verwendet Grenzregeln, die die Tausenderpunkt-Schreibweise amtlicher Portale tolerieren. Ganze Gesetze sind nach Dateiname oder nach Registrierungsnummer ladbar, wobei große Dateien automatisch umgeleitet werden. Das Registrierungswerkzeug ist der verpflichtende Meldeweg für jedes im offenen Web gefundene Gesetz: nur der Link, der Rechtsraum und optional Titel und Satz werden eingereicht; ein Hintergrundprozess ruft die Quelle ab, konvertiert sie, speichert sie und kündigt sie im Datenmonitor an, und das Modell selbst konvertiert nie etwas. Ein Prüfzyklus der Bibliothek verfolgt das Datum der letzten Prüfung jeder Quelle. Ein Gesetz, das der Benutzer als Datei ohne Online-Quelle hochgeladen hat, trägt in jeder Antwort eine Aktualitätswarnung, weil seine Geltung nicht überprüft werden kann. Das Ablehnen eines Gesetzes im Datenmonitor verlangt eine Bestätigung, die die Folge benennt: das Gesetz verlässt die Bibliothek, und das Ablehnen einer Aktualisierung entfernt das gesamte Gesetz, auch auf dem Büro-Server.

Ein Werkzeug zur erneuten Prüfung prüft ein Gesetz auf Wunsch gegen seine Quelle und meldet unverändert, aktualisiert oder Dublette; ein frischerer Abruf übernimmt den Eintrag, und auf dem Büro-Server gewinnt der letzte Prüfer, gleich wer das Gesetz zuerst registriert hat. Ganze Gesetze oberhalb der Konnektor-Grenze landen im Zwischenspeicher und registrieren nichts als gelesen; die Herkunft kommt vom Artikelwerkzeug.

20. Validatoren und Register

Deterministische Prüfwerkzeuge decken ab: IBAN (Format, länderspezifische Länge, Prüfsumme); nationale Personen-, Versicherungs- und Steuernummern über neun Schemata in sechs Ländern mittels Prüfziffern, mit einem gezielten Modus je Schema und einem automatischen Modus, der alle Schemata testet und die gültigen meldet; europäische USt-Identifikationsnummern (zuerst Offline-Prüfung des Länderformats, dann der amtliche Live-Dienst der Union, der freigegebene Firmendaten zurückgibt, wo der Mitgliedstaat sie bereitstellt); EORI-Nummern gegen den Live-Validierungsdienst der Union; Rechtsträgerkennungen (zuerst Prüfsumme, dann das globale Register für Status und Namen); und Handelsregisternummern über das europäische Unternehmensregister-Portal, gerendert in einer echten Browser-Engine, wobei das Modell angewiesen ist, die zurückgegebene Seite zu lesen und den Befund zu bestätigen. Jeder Validator gibt ein konkretes, begründetes Ergebnis zurück — gültig mit Einzelheiten, ungültig mit dem fehlschlagenden Aspekt, nicht gefunden oder Dienst nicht erreichbar samt Status —, nie ein bloßes Ja oder Nein, sodass eine wirklich falsche Nummer immer von einem Ausfall unterscheidbar ist. Die Instruktionsschicht macht das Ausführen des passenden Validators zur Pflicht, bevor eine solche Nummer in ein erzeugtes oder geprüftes Dokument gelangt. Dasselbe Toolset führt das grobe Standortwerkzeug des Benutzers (Land, Stadt und öffentliche Adresse aus dem letzten Anmelde-Schnappschuss, ausdrücklich keine Rechtsraum-Quelle) und ein Wetterwerkzeug nach bestem Bemühen.

21. Webzugriff

Zwei Werkzeuge erreichen das offene Internet, beide als Ergänzung zu den eigenen Webfähigkeiten der Desktop-KI gefasst, mit der ausdrücklichen Anweisung, sie direkt zu verwenden, wenn die KI keinen eigenen Webzugriff hat, und dem Verbot, sie für fallbezogene Daten zu verwenden. Das Suchwerkzeug fragt über eine menschenähnliche Weboberfläche mit einer Auswahl von Suchmaschinen ab und gibt betitelte, verlinkte Treffer zurück, denen mit dem Seitenöffner nachgegangen werden soll. Der Seitenöffner ruft genau eine öffentliche URL mit einer gestuften Pipeline ab, die die Beschreibung vollständig aufzählt, damit das Modell nie vorzeitig aufgibt: eine menschenähnliche HTTP-Anfrage mit echten Browser-Headern, Behandlung von Weiterleitungen und Kompression; automatische Erkennung von Anti-Bot-Hürden mit Eskalation in eine echte eingebettete Browser-Engine; Erkennung von JavaScript-Hüllenseiten mit Rendern, bis Inhalt erscheint; seitengenaue PDF-Konvertierung, die je Seite die Textebene und OCR nur für gescannte Seiten verwendet, sodass gemischte Dokumente funktionieren; und die Konvertierung von Office- und Textformaten in lesbaren Text. Die Ausgabe ist Markdown, vollständig: der Hauptinhalt wird extrahiert (Navigation, Werbung und Cookie-Banner entfernt), Seiten ohne Artikelkörper behalten ihre Fußzeile, weil dort Adress- und Kontaktdaten stehen, und wo die Extraktion so gut wie nichts übrig ließe, wird stattdessen die ganze Seite geliefert. Ein Aufruf antwortet innerhalb von fünfundvierzig Sekunden; ein großes oder gescanntes Dokument wird im Hintergrund weiterverarbeitet und beim nächsten Aufruf mit derselben Adresse sofort geliefert. Gesetzesportale werden nach dem Gesetzes-Tor verweigert, bis die Bibliothek durchsucht wurde.

22. GUI-Navigation und Exporte

Alle Navigation ist Opt-in über einen Schalter des Benutzers; ohne ihn existiert die gesamte Gruppe nicht. Die Navigationswerkzeuge öffnen im Hauptfenster der Anwendung: einen Fall (optional auf seinem Chronik- oder Bewertungs-Reiter), die Fallliste eines Mandanten, eine Person, eine Institution (beide hervorgehoben mit geöffnetem Detail), einen Beweismitteleintrag (richtige Chronikseite, hervorgehoben), die Dossier-Vorbereitung (mit einer vollautomatischen Variante, die dem ausdrücklichen Wunsch des Benutzers nach einem vollständigen PDF vorbehalten ist), das Tagesprotokoll (optional das Detail eines bestimmten Tages), den E-Mail-Monitor (optional das Detail einer bestimmten Mail), die globale Suche mit ausgelöster Anfrage (dem ausdrücklichen Wunsch vorbehalten; Chat-Antworten verwenden stattdessen die interne Suche), den Backup-Bereich mit sofortigem Backup-Start und jeden benannten Bildschirm aus der kanonischen Bildschirmliste. Exportdialoge decken die Mandantenliste, die Fristenliste, die Fallübersicht eines Mandanten, das Falldossier in zwei Dokumenttypen und die Karte ab, dazu den Bau des KI-Pakets des Mandanten. Alle Navigationswerkzeuge unterliegen der harten Sperre und sind die Ziele der Navigationsangebote aus Abschnitt 7.

23. Schreiben, Formate und Auslieferung

Das Schreib-Toolset bindet die Dokumenterstellung an abgerufene Spezifikationen. Das Ausgabeformat-Werkzeug gibt die verbindliche Erzeugungsinstruktion für die angeforderte Artefaktart zurück — für Schriftsätze unterschieden in juristischen Schriftsatz und einfachen Brief, jeweils in vertretener und selbst vertretener Form, wobei Rechtsraum, Sprache und Datum des Falls direkt in die Instruktion aufgelöst sind, mit Platzhaltern, die das Modell aus Konnektor-Daten füllt; das Mailversand-Format-Werkzeug gibt die verbindliche Spezifikation für Gerichtssendungen mit aufeinanderfolgender Paketauslieferung zurück. Beide sind buchstabengetreu zu befolgen. Die Editor-Übergabe schiebt einen Markdown-Schriftsatz direkt in die Textverarbeitung von IRONSTICK, mit geladenem Text, aber nichts gespeichert — der Benutzer prüft und speichert —, und ist auf der Claude-Verbindung verfügbar. Das Chronik-Erfassungswerkzeug öffnet das vorausgefüllte Chronikformular im richtigen Fall und speichert selbst nichts.

Die Auslieferung von Dateien an den Benutzer läuft ausschließlich über das Auslieferungswerkzeug, das das Front-End selbst ausführt: die Datei landet im eigens dafür vorgesehenen Auslieferungsordner unter dem Download-Verzeichnis des Benutzers, der Ordner öffnet sich mit hervorgehobener Datei, und ein Link wird ausgegeben. Der Ordner dient nur der Auslieferung — nichts darin wird vom Modell je gelesen, bearbeitet oder gelöscht. Der Inhalt kommt entweder inline an oder, bevorzugt und bei großen oder bereits geschriebenen Dateien verpflichtend, per Quellpfad, den das Front-End direkt von der Festplatte liest, sodass nichts durch das Modell neu getippt wird, Binärformate eingeschlossen. Das Modell versioniert Dateinamen selbst, eine neue Nummer je Auslieferung, wobei eine Auslieferung unter gleichem Namen überschreibt; das Ergebnis meldet die vorhandenen Versionen des Namensstamms und die höchste und warnt, wenn die ausgelieferte Nummer nicht die höchste ist. Die Auslieferung erfolgt einmal je Aufgabe, am Ende, nie für Zwischenstände, und durchläuft zuerst das Förmlichkeits-Tor aus Abschnitt 8.

24. Peer-Review zwischen KIs

Das Übergabewerkzeug reicht ein erarbeitetes Stück an die andere Desktop-KI weiter: der Inhalt geht in einen kurzlebigen Großspeicher, ein Aufgaben-Datensatz verweist darauf, die Anweisung (auf tausend Zeichen begrenzt) sagt, was der Peer tun soll, und das Modell bittet dann den Benutzer, den Peer in der anderen Anwendung anzustoßen. Das Eingangswerkzeug führt offene Aufgaben auf, die an den Aufrufer gerichtet sind — seine eigenen erscheinen nie —, mit Kennung, Auftrag und vollständigem Inhalt, optional nach Mandant oder Fall gefiltert. Das Antwortwerkzeug schließt eine Aufgabe (und löscht ihren kurzlebigen Inhalt) und sendet zugleich die Bewertung als neue Aufgabe an den ursprünglichen Absender zurück; das Abschlusswerkzeug schließt ohne Rückgabe. Lesen und Schreiben im Zwischenspeicher sind Mitglieder dieses Toolsets, um den ausgetauschten Inhalt zu handhaben.

25. KI-Instruktionsdateien

Je Fall kann der Benutzer Instruktionsdateien ablegen, die das Modell heranziehen muss. Der Lister zeigt die Instruktionen eines Falls mit Kennung, Dateiname, Größe, Upload-Datum und Auszug, ohne Volltexte; das globale Inventar führt jede Instruktion über alle Mandanten und Fälle auf; der Einzelleser gibt eine Instruktion ungekürzt über ihre numerische Kennung zurück, mit der Option, den Rohinhalt bytegenau zur Durchleitung in den Zwischenspeicher zu lenken; der Sammelleser gibt alle Instruktionen eines Falls in einem Aufruf mit derselben Zwischenspeicher-Option zurück. Beide Listenausgaben werden bei Übergröße automatisch umgeleitet. Das Aktualisierungswerkzeug schlägt eine geänderte Fassung auf genau einem von drei Wegen vor — ein Anhängefragment (der bevorzugte Weg für Ergänzungen, wobei die Anwendung das Ergebnis selbst zusammensetzt und dem Modell verboten ist, den bestehenden Inhalt wiederzugeben), ein Quellpfad zu einer vollständigen neuen Fassung auf der Festplatte oder der vollständige neue Inhalt inline —, und die Anwendung zeigt dem Benutzer die Änderung als Diff; nur die ausdrückliche Zustimmung übernimmt sie, das Ergebnis (angenommen, abgelehnt oder ausstehend) wird zurückgegeben, und ein ausstehender Zustand verbietet das erneute Senden. Der Paketexport baut das vollständige Instruktions-und-Skill-Bündel eines Mandanten und öffnet den Exportdialog.

26. Begleitintegrationen außerhalb der Werkzeugoberfläche

Ein clientseitiger Begleiter ergänzt die Bridge, ohne Teil der MCP-Oberfläche zu sein: ein installierbares Skill-Plugin für jede Desktop-KI (fünf Skills, die das Arbeitsmodell aus Toolset und Ausführungswerkzeug abbilden, vom Konfigurator der Anwendung erzeugt und versioniert). Die Konfiguration des Bridge-Front-Ends für jede KI wird von den entsprechenden Konfigurator-Schaltflächen geschrieben, die immer die Aufruferidentität und den Instruktionspfad schreiben, um vor einer gemeinsamen Nutzung der Konfiguration durch mehrere KIs zu schützen.

27. Fehler- und Verweigerungssemantik — Zusammenfassung

Jede Verweigerung im System ist belehrend statt kahl: Schemaverstöße geben das erwartete Schema zurück; unbekannte Namen geben den nächstliegenden Treffer zurück; das Datums-Tor nennt die genaue Abhilfe; das Gesetzes-Tor nennt das Bibliotheksverfahren; die Navigationssperre nennt den geschützten Bildschirm und die aufgeschobene Alternative; die Zustimmungssperre nennt das Fenster für den erneuten Versuch; Antworten bei Übergröße nennen die Datei und die zwei Fortsetzungsbefehle oder die eingrenzenden Filter; Validator-Fehlschläge nennen den fehlschlagenden Aspekt und unterscheiden Ausfälle; Kapazitätsabweisungen im Gedächtnis nennen Belegung und Rest und, nahe der Grenze, die Möglichkeiten zur Umstrukturierung; das Auslieferungs- und das Such-Tor nennen ihre Antwortmöglichkeiten einschließlich des universellen Auswegs „unknown“; der Instruktions-Riegel nennt die zwei Aufrufe, die ihn öffnen; das Vorbereitungs-Tor nennt die ungelesenen Teile mit Kennungen und Prozentwerten; der Schriftsatz-Prüfer nennt je abgelaufenem oder zurückgesetztem Lesevorgang den genauen Aufruf, der ihn wiederherstellt. Der Vertrag gegenüber dem Modell lautet, dass das Modell nach höchstens drei korrigierten Versuchen bei jedem fehlschlagenden Aufruf anhält und dem Benutzer den genauen Fehler meldet.