Klark.one ist modular aufgebaut. Die Bausteine lassen sich einzeln auf einem Server oder gemeinsam auf einem System betreiben. Diese Seite zeigt zwei Sichten: die laufenden Module und die Code-Organisation in Repos und Packages.
Laufende Module
| Modul | Aufgabe |
|---|---|
| Web App | Benutzeroberfläche und API-Gateway in einer Anwendung. Nimmt alle Anfragen entgegen, authentifiziert sie (verschlüsselte Sitzungs-Cookies) und steuert die anderen Module an. |
| Datenbank | PostgreSQL. Speichert Nutzer, Teams, Einstellungen und Prüfergebnisse — keine Dokumentinhalte. |
| Dateisystem | Dokumentablage in definierter Ordnerstruktur mit Indexdatei (Metadaten, KI-Ergebnisse, Status). Zugriff über einen Dateiserver (lokal, WebDAV, SFTP oder OCI Bucket). |
| Worker-Service | Asynchrone Hintergrundverarbeitung: Dokumentenkonvertierung, Metadaten-Extraktion, Kriterienprüfung und Nachweis-Matching. Fortschritt wird per Echtzeit-Updates gemeldet. |
| KI-Anbindung | Einheitliche Schnittstelle zu LLM-Providern — lokale Modelle ebenso wie externe Dienste (OpenAI, Anthropic, Gemini). Vertrauliche Daten werden bevorzugt lokal verarbeitet. |
Zusammenwirken
Alle Verbindungen sind verschlüsselt und authentifiziert.
| Von | Nach | Zweck |
|---|---|---|
| Benutzer | Web App | Bedienung der Oberfläche |
| Web App | Datenbank | Nutzer, Einstellungen, Ergebnisse lesen und schreiben |
| Web App | Dateisystem | Dokumente lesen, hochladen, Metadaten pflegen |
| Web App | Worker-Service | Aufgaben delegieren (Konvertierung, Prüfung) |
| Web App | KI-Anbindung | KI-Chat direkt an die Modelle |
| Worker-Service | Dateisystem | Ergebnisse zurückschreiben |
| Worker-Service | KI-Anbindung | KI-gestützte Workflows ausführen |
Die Module können auf einem einzigen System zusammen oder auf mehrere Server aufgeteilt werden — je nach Last und Datenschutzanforderungen. Für die technische Sicht siehe /docs/architecture und /docs/datenfluss.
Repositories und Packages
Klark.one ist als Metarepo organisiert. Das übergeordnete Repository orchestriert alle Repos; die eigentliche Logik steckt in den Packages der Teil-Repos.
| Repository | Inhalt | Lizenz |
|---|---|---|
| kontext.one | Metarepo: Orchestrierung, Skripte, Dokumentation. Kein eigener Laufzeitcode; steuert Deploy, Pull und Health-Checks. | — |
| klark0 | Web App (Next.js Frontend + API). Benutzeroberfläche, Authentifizierung, API-Gateway. | Proprietär |
| python-utils | Backend-Packages für Dokumentenverarbeitung und KI-Pipeline. | Proprietär (teils MIT) |
| python-openutils | Freie Shared-Packages, projektübergreifend genutzt. | MIT |
python-utils — Packages
| Package | Beschreibung | Lizenz |
|---|---|---|
| agentos | Agent-Orchestrierung für die Vergabeprüfung. | Proprietär |
| robotni_arq | Task-Scheduler für asynchrone Hintergrundaufgaben (arq + FastAPI). | MIT |
| robotni_messaging | Strukturiertes Protokoll zwischen Worker und Frontend. | Proprietär |
| ofs | Opinionated Filesystem: strukturiertes Ordnerlayout für Vergabeunterlagen. | Proprietär |
| pdf2md.skale | Konvertierung von PDF in Markdown über verschiedene Extractoren. | Proprietär |
| strukt2meta | Erzeugt fertige Metadaten aus strukturierten Daten mittels KI. | Proprietär |
Zusätzlich die workflows — Prompt-Bibliotheken (Markdown in agentos/prompts und strukt2meta/prompts), die die KI-Workflows steuern und pro Deployment überschreibbar sind.
python-openutils — Packages
| Package | Beschreibung | Lizenz |
|---|---|---|
| uniinfer | Einheitliche Inference-API für LLM-Chat über 15+ Provider, mit Streaming, Fallback-Strategien und API-Key-Verwaltung. | MIT |
| credgoo | Sichere Verwaltung und Abruf von API-Keys mit lokalem Caching. | MIT |