Wie wir bauen.

01 — WRITE

Externalisiere Entscheidungen.

Bevor wir Code schreiben, schreiben wir Architektur-Dokumente. Jede Funktion startet mit einem klaren Anforderungsdokument: Wir halten vorab schriftlich fest, welches Problem für wen gelöst wird, wie die Lösung aufgebaut ist, welche Alternativen es gab und warum wir uns entschieden haben.

Die Regel: Was nicht im Architektur-Dokument steht, existiert nicht. Implizite Annahmen werden expliziert oder fallen weg. Das verlangsamt den Start eines Features um Stunden — und beschleunigt das Ende um Wochen, weil keine Diskussionen revisitet werden müssen.

Dahinter steht ein festes Arbeitsprinzip, das wir intern WISC nennen: In vier klaren Regeln legt es fest, welche Informationen zusammengetragen, sauber getrennt, gezielt ausgewählt und verdichtet werden, bevor eine Entscheidung fällt — ob ein Mensch daran arbeitet oder ein intelligenter Assistent.

02 — COMPLIANCE-INVARIANTEN

Compliance vor Convenience.

Sicherheits-Invarianten sind keine Sprintziele, sondern Architektur-Pflichten. Bei OneLog gelten diese Invarianten ausnahmslos:

• →Jeder Kunde sieht nur seine eigenen Daten — erzwungen bis auf die einzelne Datenzeile. Was nicht ausdrücklich erlaubt ist, bleibt gesperrt, ausnahmslos auch für privilegierte Konten.
• →Jede Schnittstelle prüft bei jedem Zugriff, wer was darf — anhand fester Rollen- und Attribut-Regeln. Kein Zugriff ohne ausdrückliche Freigabe.
• →Jedes sicherheitsrelevante Ereignis wird protokolliert, zukunftssicher signiert und fortlaufend verkettet — nachträgliche Änderungen werden so erkennbar.
• →Betrieb nur in europäischer Cloud — keine US-Großanbieter, keine US-Bausteine. KI-Modell, E-Mail-Versand und Speicher bleiben in der EU.
• →Zugangsdaten liegen zentral im geschützten Tresor, nie offen im Code. Fest einprogrammierte Schlüssel werden schon vor dem Speichern automatisch abgelehnt — ohne Ausnahme.

Wer eine Invariante umgehen will, schreibt eine ADR (Architecture Decision Record) mit Begründung. Die ADR landet im Repo. Geprüft. Dokumentiert. Auditierbar.

03 — TEST-BEFORE-DONE

Kein „sollte funktionieren". Nur grüne Pipelines zählen.

Bevor wir Fertig melden, läuft die komplette Build- und Test-Pipeline grün. In jeder Sprache, jedes Mal, ohne Ausnahme. Bei Fehlern geht der Engineer (oder Agent) autonom in eine Korrektur-Schleife — analysiert, fixt, re-validiert. Erst nach grünem Build kommt die Antwort an den User.

Das gilt auch für Texte, die die KI erstellt: Bevor ein automatisch erstelltes Dokument freigegeben wird, wird es automatisch geprüft und muss einen definierten Qualitätswert erreichen (Eval-Pipeline mit Score-Schwelle). Geprüft wird dreifach — auf frei erfundene Angaben (Halluzinations-Check), auf Einhaltung Ihrer Vorgaben (Compliance-Check) und auf den passenden Schreibstil (Tone-of-Voice-Check). Wird der Wert nicht erreicht, geht das Dokument automatisch zurück in die Überarbeitung und wird erneut geprüft.

04 — AGENTIC BY DEFAULT

Ein Klick im UI ist UX-Schuld.

Wir bauen keine Dashboards für menschliche Klick-Arbeit. Wir bauen Plattformen, die Probleme erkennen, lösen und protokollieren — bevor ein Operator sie sieht. Dashboards sind Eskalations-Pfade, keine Arbeitsoberflächen.

Das ist mehr als „Automation". Es ist eine architektonische Wette: wenn ein Problem deterministisch lösbar ist, wird es deterministisch gelöst. Lässt es sich nicht über eine feste Regel klären, übernimmt es ein Verbund zusammenarbeitender KI-Assistenten und schreibt jeden Schritt nachvollziehbar mit. Nur wenn beide Wege nicht weiterkommen, sieht ein Mensch das Problem — und dann mit allem Kontext.

Das verändert das Geschäftsmodell unserer Kunden: ein MSP-Techniker, der heute 50 Geräte betreut, betreut mit OneLog 500. Nicht durch mehr Klicks pro Stunde — sondern durch dramatisch weniger nötige Klicks.

Stack-Wahl, kurz

Womit wir bauen — und warum.