Projekte
Aktive Entwicklung Demo auf Anfrage

Brücke OS by TreuLink

Ein KI-gestütztes Beratungs-Betriebssystem (Consulting OS) für den Migrations-, Beschäftigungs- und Bildungskorridor zwischen Deutschland und der Türkei. Grundprinzip: Jede Antwort stützt sich auf eine offizielle Quelle und einen überprüfbaren Nachweis.

Vertrauen ist kein Versprechen, sondern eine überprüfbare Systemeigenschaft.

Auf einen Blick

Was KI-gestützte Beratungsplattform für den Korridor Deutschland–Türkei (Unternehmensdemo / MVP)
Meine Rolle Gründer und alleiniger Entwickler — Produkt, Architektur, Design, Inhalte
Marke Brücke OS (Produkt) · TreuLink (Dachmarke) — Treu + Link (Verbindung, Brücke)
Stack Next.js 16 · React 19 · TypeScript 5.9 · Tailwind 4 · Drizzle + PostgreSQL 16 + pgvector · Redis · Vercel AI SDK · next-intl
Architektur Ein einziger TypeScript-Monolith · Turborepo- + pnpm-Monorepo · 5 Kernprimitive + Legal-Guard
Umfang ~32.500 Zeilen TypeScript · ~364 Dateien · ~35 Datenbanktabellen · 22 Unit- + 23 End-to-End-Tests · 3 Sprachen (TR/DE/EN)
Sprachen Jeder für den Nutzer sichtbare Text gleichzeitig auf Türkisch, Deutsch und Englisch
Ziel-Hosts treulink.com (Landing) · bruecke.treulink.com (App) · briefing.treulink.com (geschützter Briefing-Raum)
Status Veröffentlichungsbereit; im Unternehmensdemo-Modus (kostensicher, vorformulierte Beratung)

Geschichte & Problem

Migration nach Deutschland, die Arbeitssuche vor Ort und Bildungswege sind komplex: Informationen sind verstreut, ihre Aktualität ist unklar, und der Beratungsmarkt schafft oft kein Vertrauen. Bewerber wissen häufig nicht, welcher Visumsweg zu ihnen passt, ob ihre Unterlagen vollständig und aktuell sind, ob ihre Beratungsstelle vertrauenswürdig ist — oder ob überhaupt ein offizieller Antrag in ihrem Namen gestellt wurde. Diese Unsicherheit kostet Zeit, Geld und psychische Widerstandskraft.

Dieses Projekt entstand aus genau dieser Lücke. In meinem eigenen Migrations- und Beschäftigungsprozess in Deutschland habe ich eine schwere Benachteiligung erlebt; ein Verlustzeitraum von rund 700 Tagen (Zeit, Geld, Mühe und psychische Belastung) wurde zur Motivation für das Projekt. Ziel ist es nicht, Personen oder Institutionen zu beschuldigen, sondern auf systemischer Ebene zu zeigen, warum solche Benachteiligungen möglich sind — und eine digitale Struktur vorzuschlagen, die Bewerber schützt, Institutionen absichert und Beratungsprozesse ordnet.

Deshalb ist die Plattform durchgängig auf einem Ehrlichkeitsprinzip aufgebaut: Garantiesprache ist verboten. Formulierungen wie „Visumsgarantie" oder „sicheres Ergebnis" werden auf keiner Ebene verwendet (Oberfläche, Daten, KI-Prompt, Präsentation). Die Standardhaltung lautet: „ersetzt keine offiziellen Stellen, bereitet auf den Prozess vor."


Was es tut

Brücke ist mehr als eine Website oder ein Chatbot. Es strukturiert die vielschichtigen, mehrere Akteure umfassenden Prozesse auf der Linie Deutschland–Türkei nach der Logik eines Fall-Betriebssystems: Bewerberprofil, Unterlagen, Ziel, Prozessstand, Beraternotizen, Arbeitgeber-Matches, Experten-Weiterleitungen und institutionelle Kontrollpunkte werden in einem sicheren System nachvollziehbar.

Architektonisch ist dies als domänenagnostischer Kern + Domain-Packs angelegt — die „Consulting OS"-Vision. Das de-tr-corridor-Paket von Brücke ist die erste Umsetzung dieses Kerns; dieselbe Engine lässt sich auf andere Beratungsbereiche übertragen.

Das System ist um sechs Rollen herum geschichtet; jeder Beteiligte sieht seine eigene Erfahrung:

  • Bewerber — Profil, Dokumententresor, Ziel, Prozessstand, Lebenslauf, Matching.
  • Berater — Fall-Warteschlange, Dokument-, Aufgaben-, Notiz- und Risikooperationen.
  • Arbeitgeber — Stellen, Bewerberpool, Match-Score, Bereitschaft, Kontakt.
  • Institution/Stiftung — Begünstigten-Tracking, Kohorten-/Programmverwaltung, Wirkungsberichte.
  • Experte — weitergeleitete Fälle, Dokumentenprüfung, Rechts-/Übersetzungsbegleitung.
  • Administrator — Audit-Panel, Audit-Log.

Brücke OS Bewerber Berater Arbeitgeber Institution/Stiftung Experte Administrator

Wichtigste Funktionen

Quellensiegel (Prüfsiegel). Jede informationstragende Antwort trägt ein Quellensiegel: Quellenname + offizielle URL + Prüfdatum + Vertrauensstufe. Eine KI-Antwort ohne Siegel gilt per Definition als Bug. Sind die Daten älter als 14 Tage, erscheint eine gelbe, ab 30 Tagen eine rote Warnung — der Nutzer sieht, wie aktuell die Information ist.

Legal-Guard (rechtliche Grenzschicht). Jede KI-Antwort durchläuft vor der Auslieferung eine rechtliche Grenzprüfung. Allgemeine Informationen werden gegeben; eine individuelle Rechtsberatung nicht (RDG-Grenze in Deutschland). Risikothemen wie Widerspruch gegen Visumsablehnung, Klagen oder Vertragswirksamkeit werden erkannt, noch bevor das Modell aufgerufen wird, und führen zu einem Experten-Weiterleitungsbildschirm (Human-in-the-Loop) — dokumentiert im Audit-Log. Dieses Design stützt sich auf das BGH-Smartlaw-Urteil: eine deterministische Berechnung ist RDG-sicher, eine LLM-Interpretation nicht.

Deterministische Regel-Engine. Schwellenwerte, Daten und Berechnungen werden nicht dem LLM überlassen, sondern in separaten, reinen Funktionen berechnet. Etwa die Gehaltsschwellen der Blauen Karte EU, die Punkte der Chancenkarte, das §81a-Schnellverfahren oder Sperrkonto-Beträge — 14 verschiedene Werkzeuge, jedes mit Quelle und Gültigkeitsdatum. Gleiche Eingabe liefert stets gleiche Ausgabe; das ist sowohl für Korrektheit als auch für Rechtssicherheit entscheidend.

§81a-Verifizierungsmodul. Das Herzstück der Präsentation: Betrugsresistenz. Der Status von Unterlagen, die Spur der im eigenen Namen vorgenommenen Schritte und deren Überprüfbarkeit werden über eine Checkliste transparent.

Matching-Pool. Ein von Menschen geprüftes System, das Bewerber und Arbeitgeber über eine offene Score-Aufschlüsselung (Beruf/Sprache/Bereitschaft/Erfahrung/Ort) und einen Einwilligungsfluss zusammenführt.

SABEV-Exposé-Assistent. Ein clientseitig laufender Erzeuger von Vorstellungsprofilen mit PDF-/DOCX-Export in drei Sprachen; es wird ausdrücklich darauf hingewiesen, dass die Daten das Gerät nicht verlassen und keine Vermittlungsgarantie gegeben wird.

Trust Showcase & geführte Touren. Eine Vitrine, die live zeigt, wie SHA-256-Hash, versionierte Einwilligung und Audit-Trail funktionieren; dazu geführte Touren, die die Rollen als anklickbare Journeys erklären, sowie der an Behörden versandte, geschützte Briefing-Raum („Wer/Was/Wie in 60 Sekunden" + Live-Demo).


Anfrage Legal-Guard Risikothema? RAG Mindestähnlichkeit Regel-Engine deterministisch LLM nur mit Quelle Legal-Guard Disclaimer Quellensiegel Quelle·URL·Datum·Vertrauen Experten-Weiterleitung keine Quelle → sichere „keine Information“

Grundprinzipien

Die unveränderlichen Regeln des Projekts werden durch Tests erzwungen:

  • Vertrauen = überprüfbare Systemeigenschaft. Jedes Modul liefert drei „sinnliche Nachweise": das Taschenrechner-Gefühl (deterministisch, mit Quelle), das Leitfaden-Gefühl (Schritt–Dokument–Dauer–Quelle) und das Berater-Gefühl (KI mit Quellensiegel).
  • Demo-Ehrlichkeit. Jeder Datensatz wird gekennzeichnet (echtes-Profil-redigiert | Demo-Daten | Mock-Stakeholder | offizielles-Quellenbeispiel | noch-nicht-integriert); in der Oberfläche gibt es ein dezentes „Demo-Daten"-Abzeichen. Keine Integration oder Billigung durch eine offizielle Stelle wird angedeutet.
  • Redaktion. Ausweis-/Passnummern, Bankdaten, QR-Codes, Unterschriften, vollständige Adressen und Kontaktdaten Dritter gelangen niemals in Daten, Oberfläche oder Repository — auch nicht das eigene Profil des Gründers.
  • Kein echter Datei-Upload. Der Dokumententresor arbeitet nur mit Metadaten + SHA-256-Hash + Simulation; Rohinhalte werden nicht gespeichert.
  • Dreisprachige Parität. Jeder für den Nutzer sichtbare String gelangt im selben Commit in die TR-/DE-/EN-Dateien; ein Paritätstest überwacht dies.
  • Typografie der Nachweisebene. Überprüfbare Inhalte (Quelle, §, Hash, Datum, Tabelle) werden in IBM Plex Mono gesetzt — das ist die Signatur der Marke.

Technische Architektur

Ein einziger TypeScript-Monolith. Oberfläche, API-Route-Handler und KI-Logik laufen in einer einzigen Next.js-Anwendung. Kein Python; schwere Frameworks wie LangGraph/LlamaIndex sind bewusst ausgeschlossen.

Stack: Next.js 16 (App Router, Turbopack) · React 19 · TypeScript 5.9 (strict) · Tailwind CSS 4 · Drizzle ORM + PostgreSQL 16 + pgvector (HNSW-Cosine-Index) · Redis (ioredis) · Better Auth (Drizzle-Adapter, Organization-Plugin für B2B) · Vercel AI SDK 7 · next-intl 4. Linting mit Biome (noExplicitAny: error), Tests mit Vitest + Playwright.

Monorepo: Turborepo + pnpm-Workspaces. Der Code ist in @brucke/*-Pakete aufgeteilt: web (Monolith), db (Drizzle-Schema + Migrationen), ui, types, config, Domain-Pack (de-tr-corridor) und die Kernprimitive.

5 Kernprimitive + Legal-Guard. Der Kern besteht aus fünf domänenagnostischen Primitiven; jedes ist ein separates Paket mit sauberer Schnittstelle, und LLM/Retriever werden von außen injiziert (der Kern berührt nie einen API-Schlüssel):

  1. Knowledge — „Was ist wahr?" — RAG-Schnittstellen (Embedder, Retriever, Retrieved Chunk).
  2. Logic — die deterministische Regel-Engine.
  3. Memory — „Wo stehe ich?" — wandelt Nutzerkontext + Prozessstand deterministisch in Prompt-Text um.
  4. Trust — Quellensiegel, SHA-256-Hash, Audit, eIDAS-Zeitstempel.
  5. Orchestration — verbindet die obigen; ohne Quelle wird das Modell nicht aufgerufen, es folgt eine sichere „keine Information"-Antwort.

Dazu die verpflichtende 6. Schicht Legal-Guard: Jede Antwort passiert vor der Auslieferung zwei Tore — eines auf der Anfrage (Erkennung von Risikothemen, ohne Modellaufruf), eines auf der erzeugten Antwort (Erkennung von Beratungsabweichung + lokalisierter Haftungsausschluss).

Die RAG-Pipeline ist empirisch kalibriert: eine Mindestähnlichkeitsschwelle filtert irrelevante Anfragen, eine Teilabdeckungsschwelle löst einen „unvollständige Information"-Ehrlichkeitshinweis aus. Das Datum des Quellensiegels zeigt nicht das Einfügedatum des Chunks, sondern das Datum, an dem die Aussage verifiziert wurde (letztes Scraping-Datum der Quelle).

Datenschutz durch Design. Rohanfragen und -dokumente werden nicht gespeichert — nur ihre SHA-256-Hashes. DSGVO-/KVKK-Einwilligung ist verpflichtend. Für die Dokumentenverifizierung ist ein eIDAS-Zeitstempel vorgesehen; Blockchain wird nicht verwendet (eIDAS + SHA-256 genügen).

Deployment: Docker Compose (mehrstufiger Build, Next.js-Standalone-Output) + Caddy (automatisches HTTPS) → Hetzner-VPS. Zusätzlich gibt es einen DB-losen „Public-Demo"-Modus (PUBLIC_DEMO-Flag) und einen kostenfreien „vorformulierten" Beratungsmodus.

Hinweis: Einige Projektdokumente (etwa CLAUDE.md) erwähnen für Embeddings einen API-Plan; in der Praxis wurde die Embedding-Schicht mit einem selbst gehosteten bge-m3 (Ollama, 1024 Dimensionen) entwickelt. Das Chat-LLM bleibt anbieterunabhängig (Standard Anthropic; Ollama als Self-Hosting-/DSGVO-Option).


LEGAL-GUARD 2 gates · RDG Domain-agnostic core Knowledge RAG Logic Rules Memory Context Trust Hash · Audit Orchestration Compose LLM · Retriever injected

Entwicklungsprozess

Das Projekt lief auf zwei Achsen. Die strategische Roadmap umfasst neun Phasen: Phase 1 Kerninfrastruktur → Phase 2 fünf Primitive + Legal-Guard → Phase 3 Visa-/Migrations-MVP → Phase 4 Beschäftigung/Bildung → Phase 5 Dashboard/Zahlung/eIDAS → … → Phase 9 Open-Source-Release (Engine AGPL, SDK Apache) + Franchise.

Die tatsächliche Build-Historie wurde in Buchstabenwellen (A bis I) eines Unternehmensdemo-Sprints durchgeführt: Markenwechsel, Schema + rollenbasierter Zugriff, Briefing-Raum, Bewerberfluss, Matching-Engine, §81a-Modul, Trust Showcase, Widerruf der Einwilligung und DSGVO-Datenexport, Legal-Guard-Umsetzung, Szenario-Bibliothek, geführte Touren und DB-loser Veröffentlichungsmodus — danach der SABEV-Exposé-Assistent und die Umstellung auf ein Full-App-Deployment auf VPS.

Die Arbeitsdisziplin ist in jeder Sitzung gleich: die einzige maßgebliche Statusquelle (HANDOFF.md) wird gelesen → kurzer Plan → kleine Commits. Am Tagesende bleiben lint, typecheck, test, build grün. Für jeden Kernfluss wird ein Playwright-Happy-Path-Test geschrieben; Schemaänderungen erfolgen nur per Drizzle-Migration. Jeder nutzersichtbare String gelangt im selben Commit in alle drei Sprachen.

Das Projekt wurde durchgängig KI-nativ, in einer Pair-Programming-Disziplin mit Claude Code, entwickelt.


Wirkung & Zukunft

Kurzfristig: Produktions-Deployment (Hetzner-VPS + Docker + Caddy), Umstellung der Beratung auf ein Live-LLM (Anthropic Haiku/Sonnet, mit DSGVO-konformen Optionen) und ein eIDAS-Zeitstempel für die Dokumentenverifizierung.

Mittel-/langfristig: Zahlungsinfrastruktur (abhängig von einer Rechtsträger-Entscheidung), ein Terminbot und Formularassistent, ein §45c-„Comply"-B2B-Modul, ein Talentmarktplatz und schließlich ein Open-Source-Release + Franchise.

Positionierung: Angestrebt wird eine beziehungsbasierte Vorstellung bei Institutionen, die entlang des deutschen Migrationssystems arbeiten (etwa auf der Achse AMIF und „Mein Weg nach Deutschland"). Dies geschieht jedoch mit einem sorgfältigen Vorbehalt: keine Integration oder Billigung durch eine offizielle Stelle wird angedeutet; wenn das Projekt auf die richtigen Institutionen trifft, hat es das Potenzial, zu einer Infrastruktur zu werden, die Bewerber schützt, Institutionen absichert und gesellschaftliche Wirkung erzeugt.


Schluss

Brücke OS steht für mehr als eine Produktidee: für den Versuch, eine persönliche Benachteiligung in eine systemische Lösung zu verwandeln. Technisch ist es ein durchgängiger Kompetenznachweis — eine moderne Monolith-Architektur aufzubauen, die deterministische Regel-Engine vom LLM zu trennen, rechtlich-ethische Grenzen in Code zu gießen, ein dreisprachiges Produkt von Anfang an diszipliniert zu führen und all das mit KI-nativer Produktivität umzusetzen.

Kurz gesagt: ein System, das zeigen will, dass Vertrauen kein Slogan, sondern eine überprüfbare technische Eigenschaft sein kann.

Projekte