Ein System, geschaffen um belastbare Entscheidungen zu ermöglichen.

HiCC operiert als Hierarchical Reasoning Model (HRM) mit einer Managed-Deep-Reasoning (mDR) Struktur. Es ersetzt die einzelne Vorhersage eines Sprachmodells durch eine mehrstufige, prüfbare Verarbeitung.

Die Unterscheidung von System 1 (schnelles, intuitives Denken) und System 2 (langsames, logisches Denken) beschreibt menschliches Denken; HiCC nutzt sie als Analogie.[M-3] Ohne Prüfschritte wählen Standard-LLMs den Pfad des geringsten Widerstands und glätten Widersprüche. HiCC erzwingt die Schritte eines rekursiven Analyseprozesses; die Denkleistung in jedem Schritt erbringt das eingesetzte Sprachmodell.

Vier Verarbeitungsebenen bilden eine kontrollierte Kognitionsarchitektur:

• Wahrnehmung (Differenzierung): Ein algorithmischer Layer zerlegt Fragen in konkurrierende Werte und Dimensionen, bevor eine Antwort formuliert wird.
• Analyse (Dialektik): Die Engine simuliert Gegenpositionen im Steelman-Verfahren. Widersprüche werden als notwendige Spannungsfelder isoliert.
• Integration (Synthese): Das Integrations-Modul sucht nach Lösungen höherer Ordnung, die das zuvor isolierte Dilemma strategisch auflösen.
• Ergebnis (Validierung): Der Output ist das Resultat einer Argumentationskette, deren logische Struktur vor der Ausgabe geprüft wird. Tiefe hat Vorrang vor Gefälligkeit.

Sicherheit ist bei HiCC kein nachträgliches Feature, sondern ein durchgängiges Architekturprinzip. Jede Schicht — vom Client bis zur Datenbank — implementiert eigene Schutzmechanismen.

Mehrschichtige Sicherheitsarchitektur:

• Client-Ebene: Input-Validierung prüft Eingaben bereits im Browser, HTML-Escaping maskiert dargestellte Inhalte gegen XSS. Diese Prüfungen lassen sich umgehen und ergänzen deshalb die serverseitigen Prüfungen im Backend.
• Transport: Ausschließlich HTTPS/TLS mit Bearer-Token-Authentifizierung.
• Backend: JWT-Validierung, Rate-Limiting (5 Requests/Minute), Body-Size-Limits und eine Model-Whitelist bilden die Zugangsregeln. Zur Verarbeitung zugelassen sind nur authentifizierte Anfragen innerhalb der Mengen- und Größengrenzen an freigegebene Modelle.
• Datenbank: Row-Level Security beschränkt den Zugriff jedes Nutzers auf die eigenen Datensätze. Serverseitige Guards steuern Credit-Abzüge, um Race-Conditions bei parallelen Anfragen auszuschließen.

Datenschutzmaßnahmen: Das Terminal setzt keine externen Tracker, keine Cookies und keine Analytics ein. Fonts, Icons und JavaScript-Bibliotheken werden lokal ausgeliefert. Fehlermeldungen werden vor der Rückgabe um interne Details bereinigt.

Das Hierarchical Reasoning Model unterscheidet HiCC von KI-Anwendungen, die eine Anfrage mit einem einzelnen API-Call beantworten. HiCC implementiert stattdessen eine mehrstufige, auditierbare Denkkette.

Transparenz statt Black Box:

• Das Zwischenergebnis jedes Schritts (Wahrnehmung, Analyse, Integration) wird gespeichert und ist einzeln einsehbar.
• Über die Agent-Details verfolgen Nutzer anhand dieser Zwischenergebnisse, wie das Ergebnis entstanden ist. Die modellinterne Verarbeitung innerhalb eines Schritts zeigen sie nicht.
• Schritt 3 (Integration) enthält einen expliziten Bias-Audit: Kognitive Verzerrungen und blinde Flecken werden aktiv geprüft, bevor die finale Empfehlung entsteht.

Qualität durch Struktur: Das Ergebnis ist nicht die wahrscheinlichste Antwort, sondern das Resultat einer Argumentationskette, die alle Verarbeitungsebenen durchlaufen hat. HRM erzwingt diese Schritte auch dort, wo schnelle Antworten bequemer wären.

HiCC operiert innerhalb definierter Grenzen. Transparenz darüber ist Teil der Architektur, nicht Schwäche.

Annahmen, die das System trägt:

• Die Eingabefrage ist präzise genug formuliert, um eine sinnvolle Analyse auszulösen. Vage Fragen erzeugen plausible, aber inhaltlich leere Ergebnisse.
• Das zugrunde liegende Sprachmodell liefert faktuell korrekte Zwischenschritte. HiCC prüft die Struktur der Argumentation, nicht die Faktenbasis jeder einzelnen Aussage.
• Der Nutzer bewertet das Ergebnis im Kontext seiner Domäne. Das System liefert strukturell geprüfte Analysen, keine Handlungsanweisungen.

Bekannte Failure Modes:

• Scheintiefe: Bei einfachen Fragen kann die vierschrittige Analyse Komplexität suggerieren, die nicht in der Sache liegt.
• Modellabhängigkeit: Die Qualität der Analyse hängt vom eingesetzten Sprachmodell ab. Modellwechsel können Ergebnisqualität verändern.
• Bias-Residuen: Der Bias-Audit in Schritt 3 reduziert kognitive Verzerrungen, eliminiert sie aber nicht vollständig.

Reversal Trigger: Wenn ein Nutzer systematisch Ergebnisse übernimmt ohne eigene Domänenprüfung, verfehlt das System seinen Zweck.

HiCC ist keine Sammlung isolierter Features, sondern ein integriertes System — von der Benutzeroberfläche über die Serverless-Logik bis zur Datenbank als zusammenhängende Architektur konzipiert.

Ganzheitlicher Ansatz:

• Frontend (SPA): Vanilla JavaScript, zustandsgesteuert, ohne Framework-Overhead. State-Management, DOM-Updates und Fehlerbehandlung folgen einer klaren Verantwortungstrennung.
• Backend (Serverless): Supabase Edge Functions mit Deno/TypeScript. Jede Funktion hat eine definierte Zuständigkeit — Authentifizierung, Validierung, KI-Orchestrierung und Credit-Management sind sauber getrennt.
• Datenbank (PostgreSQL): Row-Level Security regelt den Zugriff, typisierte Schemata legen die zulässige Datenstruktur fest, und eine klare Datenfluss-Dokumentation macht nachvollziehbar, wo Daten entstehen und gespeichert werden.

Graceful Degradation: Wenn ein Schritt fehlschlägt, gibt das System das Teilergebnis der abgeschlossenen Schritte zurück und weist den Fehler ausdrücklich aus. So bleibt auch im Fehlerfall sichtbar, welcher Schritt gescheitert ist und welche Ergebnisse vorliegen.