Blacklist Software
ACTIVE
BLACKLIST SOFTWARE · ENGINEERING

Kontrolliert statt
automatisiert.

3.3C-R2 ist eine kontrollierte AI-Engineering-Plattform: eine minimale Linux-Basis, isolierte Container, deklarierte Lifecycle-Integration, CodeNomad als zentrale Engineering-Unit und AA570 als Governance-Modell — orchestriert unter menschlicher Autorität.

Du musst die KI nicht verstehen – sie muss dich verstehen. ;)

System verstehen AA570 im Detail
  • Boundary-kontrolliert
  • Fail-closed
  • Evidence-driven
  • Lokal betrieben
SECTION 01 · SYSTEM SYSTEM

Was 3.3C-R2 ist

3.3C-R2 ist die kontrollierte Umgebung, in der KI-gestützte Engineering-Arbeit stattfindet. Fünf Komponenten bilden zusammen ein Gehäuse — keine Stationen einer linearen Pipeline und ausdrücklich nicht Kubernetes.

Systemübersicht 3.3C-R2 Schichtmodell aus AA570 als Governance-Rahmen, CodeNomad als Engineering-Unit, Podman mit Quadlet als isolierte Runtime, einer Hochleistungs-Fabric als Kommunikationssubstrat und Kali Linux als Betriebsbasis. Kein linearer Ablauf. 3.3C-R2 Kontrollierte AI-Engineering-Plattform AA570 Governance & Execution Doctrine · was die KI darf, wie abgenommen wird ENVELOPE CodeNomad Native Central AI Engineering Unit Planen Bauen Prüfen Podman Isolated Runtime · isolierte Ausführung Quadlet · Declarative Lifecycle HIGH-PERFORMANCE FABRIC UDS · Local IPC · WebSocket · HTTP · MCP · kontrollierte APIs · Session-Isolation · Realtime State Kali Linux Operating Foundation · minimale Betriebsbasis FOUNDATION Zusammenspiel in Schichten — kein linearer Ablauf. Nicht Kubernetes.

Die Plattform ist als Schichtmodell aufgebaut: Jede Komponente hat eine klar begrenzte Rolle. Zusammen entsteht eine reproduzierbare, isolierte und nachvollziehbare Umgebung.

Die Komponenten sind keine Verarbeitungsstufen. Sie greifen als Betriebsbasis, Isolationsschicht, Lifecycle-Kante, Engineering-Zentrum und Governance-Rahmen ineinander.

Kein linearer Ablauf

Die fünf Komponenten sind ein Zusammenspiel, keine Kette. Kein Schritt „übergibt“ an den nächsten.

Nicht Kubernetes

Ausführung und Lifecycle sind bewusst einfach und lokal gehalten — ohne Cluster-Orchestrierung.

Öffentliche Abstraktion

Gezeigt werden Rollen und Strukturen. Interne Details bleiben bewusst nicht öffentlich.

  1. 01 · OPERATING FOUNDATION

    Kali Linux

    Minimale Linux-Basis und unterste Betriebsschicht des Systems.

  2. 02 · ISOLATED RUNTIME

    Podman

    Führt Dienste isoliert in Containern aus — ohne zentralen Daemon-Zwang.

  3. 03 · DECLARATIVE LIFECYCLE

    Quadlet

    Beschreibt Lifecycle, Abhängigkeiten und Systemstart deklarativ.

  4. 04 · NATIVE CENTRAL AI ENGINEERING UNIT

    CodeNomad

    Die zentrale Einheit, in der KI-gestützte Engineering-Arbeit stattfindet.

  5. 05 · GOVERNANCE & EXECUTION DOCTRINE

    AA570

    Der Rahmen dafür, was die KI tun darf und wie Ergebnisse abgenommen werden.

Unterstützende Lifecycle-Technologie
  • systemdDeclarative Lifecycle Integration
SECTION 02 · FABRIC HOCHLEISTUNGS-FABRIC

Interne Fabric

Dienste kommunizieren lokal und kontrolliert. Die Fabric beschreibt, wie diese Kommunikation technisch möglich wird — und warum der lokale Weg für viele Lasten der naheliegende ist.

Hochleistungs-Fabric zwischen isolierten Diensten Dienste auf demselben Host kommunizieren über eine lokale Fabric aus Unix Domain Sockets, Local IPC, WebSocket, HTTP und MCP. Kein offener Netzwerk-Port, getrennte Dienste, kontrollierte Wege. Interne Fabric Derselbe Host · getrennte Dienste · kontrollierte Wege Dienst A isoliert Dienst B isoliert Dienst C isoliert UDS · LOCAL IPC · WEBSOCKET · HTTP · MCP · CONTROLLED APIS Session-Isolation · Job-Korrelation · Realtime State Kein offener Netzwerk-Port Zugriff über dateisystem-gebundene, kontrollierte Kanäle auf demselben Host.

Nicht jede Last sollte über öffentliche Netzwerkpfade laufen. Die Fabric verbindet Dienste auf demselben Host über lokale, kontrollierte Kanäle wie Unix Domain Sockets und Local IPC — dazu WebSocket, HTTP und MCP sowie kontrollierte APIs.

Das trennt Isolationsgrenzen von Kommunikationswegen: Dienste bleiben voneinander isoliert und können dennoch direkt über lokale, kontrollierte Kanäle miteinander sprechen — ohne den Umweg über ein externes Netzwerk.

Beispielhafte Lasten
  • Finanz-Streams
  • Candle- & Zeitreihen
  • Telemetrie
  • Sensor- & Event-Streams
  • Logs
  • Modell & Inferenz
  • Realtime-Analytik

Diese Lasten sind Beispiele für die Art von Datenverarbeitung, für die eine lokale Fabric geeignet ist. Handel ist nicht das Produkt. Es werden bewusst keine Benchmark-, Durchsatz- oder Latenzzahlen veröffentlicht.

SECTION 03 · CODENOMAD ENGINEERING-UNIT

CodeNomad

CodeNomad ist die zentrale Einheit, in der die eigentliche Engineering-Arbeit stattfindet: Aufträge werden analysiert, umgesetzt, getestet und mit Nachweisen zurückgegeben.

CodeNomad als Engineering-Unit CodeNomad als zentrale Einheit mit Arbeitsbereich, getrennten Rollen für Planen, Bauen und Prüfen, Werkzeugen, Tests und Builds sowie Ergebnissen mit Evidenz. CodeNomad Native Central AI Engineering Unit Arbeitsbereich Abgegrenzter Raum für genau einen Auftrag Auftrag Kontext Grenzen Modell-Routing · lokal / remote Planen Zerlegen und formen Rolle · Planer Bauen Umsetzen und testen Rolle · Builder Prüfen Gegen Auftrag prüfen Rolle · Reviewer ERGEBNISSE & EVIDENZ Werkzeuge, Tests und Builds liefern prüfbare Nachweise zurück.
WORKSPACE

Arbeitsbereich

Ein abgegrenzter Bereich, in dem ein Auftrag bearbeitet wird.

ROLLEN

Planen, Bauen, Prüfen

Getrennte Rollen für Planung, Umsetzung und Review.

MODELLE

Lokales & Remote-Routing

Modelle werden je Aufgabe lokal oder remote angebunden — abstrakt, ohne Anbieterdetails.

CODE

Code Intelligence

Analyse und Verständnis über den bestehenden Code hinweg.

WERKZEUGE

Tools, Tests, Builds

Ausführung von Werkzeugen, Tests und Builds entlang des Auftrags.

EVIDENZ

Ergebnisse & Nachweise

Ergebnisse gehen zusammen mit prüfbarer Evidenz zurück.

Technologien in der Engineering-Unit
  • CodeNomadEngineering Unit
  • OpenCodeCode Intelligence
  • OllamaLocal AI
Modell-Routing
  • OpenAIRemote-Modell, abstrakt angebunden
  • DeepSeekRemote-Modell, abstrakt angebunden

Gezeigt werden Rollen und Fähigkeiten. Interne Kennungen, Endpunkte oder Infrastruktur-Details bleiben nicht öffentlich.

SECTION 04 · RAGFLOW MEMORY LAYER

RAGFlow

RAGFlow ist die persistente Memory- und Kontextschicht für Projektarbeit: Sie hält fest, was in Episoden und Projekten entstanden ist, und stellt es als abrufbaren Kontext bereit.

Arbeitsoberflächen wie ChatGPT und OpenWebUI sind dort, wo Menschen mit dem System arbeiten. RAGFlow liegt darunter und sorgt dafür, dass Kontext nicht verloren geht: Episoden- und Projektgedächtnis, geteiltes Wissen, Dokumentation und Retrieval-Kontext.

Aus diesem Kontext strukturiert AA570 (Abschnitt 05) den darauf folgenden Work Order. CodeNomad (Abschnitt 03) führt die eigentliche Implementierung aus und gibt Ergebnisse samt Nachweisen zurück. Der Austausch läuft über die lokale Fabric (Abschnitt 02) — lokale, kontrollierte Kanäle statt externer Umwege.

  1. OPERATOR

    Mensch

    Autorisiert und entscheidet.

  2. SURFACES

    ChatGPT / OpenWebUI

    Arbeitsoberflächen, an denen gearbeitet wird.

  3. MEMORY

    RAGFlow

    Persistenter Memory- und Kontextkern.

  4. GOVERNANCE

    AA570

    Rahmen dafür, was ausgeführt werden darf und wie Ergebnisse abgenommen werden.

  5. ENGINEERING

    CodeNomad

    Die Engineering-Unit, in der Umsetzung und Verifikation stattfinden.

Was im Gedächtnis bleibt

Episode Memory

Was in einer einzelnen Arbeitsepisode entschieden und getan wurde.

Project Memory

Was über die Dauer eines Projekts hinweg gilt.

Shared Knowledge

Gemeinsam genutztes Wissen über Projekte hinweg.

Dokumentation

Abgelegte Beschreibungen, Entscheidungen und Referenzen.

Retrieval-Kontext

Der zur Aufgabe passend zusammengestellte Ausschnitt.

Schematisch: Wie Kontext für eine Aufgabe zusammengestellt wird.
Schematischer Kontextabruf Eine schematische Darstellung, wie Kontext für eine Aufgabe abgerufen wird. Die gezeigte Abfrage ist eine visuelle Metapher und bildet kein reales internes Datenbankschema ab. Kontextabruf Schematische Metapher · kein reales Datenbankschema -- Kontext für eine Aufgabe zusammenstellen (schematisch) SELECT d.title, d.summary FROM episode_memory AS e JOIN project_knowledge AS p ON p.id = e.project_id WHERE p.project = PROJECT_ROOT AND e.status = 'decided' ORDER BY relevance DESC LIMIT context_window; -> Entscheidungen, offene Punkte und Artefakte als Kontext

Die gezeigte Abfrage ist eine visuelle Metapher und bildet nicht das reale interne Schema von RAGFlow ab. Gezeigt werden Rollen und Strukturen; interne Details bleiben nicht öffentlich.

SECTION 05 · AA570 GOVERNANCE & EXECUTION DOCTRINE

AA570

AA570 ist kein JSON-Schema, sondern die Doktrin für kontrollierte Ausführung: Sie legt fest, was die KI tun darf, wie Ausführung und Abnahme getrennt bleiben und wann im Zweifel gestoppt wird.

AA570: kontrollierte Ausführung und Abnahme AA570 trennt Ausführung von Abnahme: Auf einen menschlich autorisierten Auftrag folgt die kontrollierte Ausführung, dann ein Nachweis, danach die menschliche Entscheidung. Im Zweifel wird fail-closed gestoppt. AA570 Execution ≠ Acceptance · kontrolliert und nachweisbar MENSCHLICHE AUTORISIERUNG · HUMAN_AUTHORIZATION Auftrag Ziel, Grenzen, Umfang bounded scope verify before mutate Ausführung kontrolliert, begrenzt mutation accounting Ability ≠ Authority Nachweis Evidenz zum Ergebnis evidence-driven UNKNOWN = FAIL_CLOSED Menschliche Entscheidung Annehmen, korrigieren oder stoppen. Abschluss ist keine Freigabe. ACCEPTANCE

Abschluss ist keine Freigabe

Dass eine Aufgabe beendet ist, bedeutet nicht, dass sie angenommen ist. Abnahme ist ein eigener, menschlicher Schritt.

Nachweis vor Fortschritt

Ohne belastbare Evidenz gibt es keinen Fortschritt — im Zweifel wird gestoppt.

Explizite Ausnahme

Abweichungen werden ausdrücklich benannt, nicht stillschweigend eingebaut.

Arbeitsaufträge machen Ziel, Grenzen, Authority, Verifikation, Stop-Bedingungen und Abnahme ausdrücklich; Doctrine Sync hält den Governance-Kontext aktuell. Die vollständige Erklärung steht auf der Detailseite.

AA570 im Detail
SECTION 06 · PROJEKTE PROJEKTE

Projekte & Nachweise

Referenzprojekt, Software und Werkzeug: Was aus der Arbeitsweise konkret entsteht.

REFERENZPROJEKT
ACTIVE

Ghost 3.3c-R2

Das zentrale Referenzprojekt und der Nachweis der Arbeitsweise: kontrolliert, nachvollziehbar und boundary-geführt.

Zum System
SOFTWARE · OPEN SOURCE

ChatGPT Soft Dark Theme

Unabhängiges, frei konfigurierbares Userscript für ChatGPT: Soft-Dark-Theme, Quick Actions, individuelle Workflows. MIT-Lizenz.

Download v2.16.1 Mehr erfahren
WERKZEUG · VORSCHAU

Design Controller

Vorschau des geplanten Userscripts: Darstellung dieser Website direkt im Browser anpassen — Presets, Glas, Glow, Hintergrund. Die Simulation läuft bereits auf dieser Seite.

Das Userscript wird veröffentlicht, sobald es fertig verifiziert ist.

Weitere Projektprofile werden ergänzt, sobald sie öffentlich belegt sind.

SECTION 07 · ÜBER / KONTAKT ÜBER / KONTAKT

Über Blacklist Software

Softwareentwicklung mit klaren Grenzen, nachvollziehbaren Prozessen und menschlicher Verantwortung.

Blacklist Software entwickelt eigene Software und überführt bestehende Projekte in einen kontrollierten, wartbaren Zustand.

Der Anspruch ist nicht Geschwindigkeit um jeden Preis, sondern nachhaltige Substanz: Architektur, Nachweise und Entscheidungen, die auch später noch tragen.

Impressum Datenschutz
Technische Basis dieser Website
RUNTIME

PHP

Serverseitiges Rendering ohne Framework-Zwang.

PRÄSENTATION

Handgeschriebenes CSS

Ein Designsystem ohne Build-Schritt, ohne externe Fonts, ohne CDN.

INTERAKTION

Minimales JavaScript

Nur wo nötig — progressive enhancement.

DATEN

Zentrales Modell

Inhalte und Zustände liegen an einer Stelle.