TGV · Master-Konzept · First-Prinzipien · Stand 2026-07-15
TGV wird so gebaut, dass es in 5 Jahren noch stimmt: die Wahrheit liegt in Daten, Regeln, Prompts, Tests und Freigaben — nicht in der gerade aktuellen Technologie. Dieses Konzept verankert die Codex-Arbitrage (JC 15.07.) in der Familie; verbindliche Quelle ist 00_LEITDOKUMENT/KONZEPT_NACHHALTIG_FIRST_PROJEKT_CONSTRUCTOR_ARBITRAGE_2026-07-15.md. Die Betriebs-Seite dazu (Projekt Typ A, Constructor, Wizard, Rechnung) ist 📁 Projekte & Constructor.
Die zehn technischen Konsequenzen (Arbitrage §6), an denen sich jeder Bau messen lässt: austauschbare KI-Provider (Modellwechsel ohne Daten-/Prozessverlust) · stabile Skill-Verträge (Skills sind Hände, Implementierung darf wechseln) · semantische Datenkerne (Rechnung/Projekt/Vertrag als Datenobjekt, nicht PDF-first) · Golden Tests · Continuous Compliance · Deprecation-Pfad für veraltete Prompts/Regeln/Skills · Rollback in der ANWENDUNG (nicht nur im Code) · Provenance überall (Quelle? Annahme? Inferenz? Bestätigung?) · Human Oversight als Gate · Audit by Design. Vieles davon IST bereits TGV-Kanon — die Anti-Amnesie-Lehre („Kanon strukturell binden: Prompt · Schema · Guard"), das Freigabe-Prinzip und R-91-Provenance. Neu ist der Rahmen, der sie zu EINEM Prinzip bündelt. Die Betriebs-Form davon ist GUARD-FIRST (JC 17.07.): „Eine Arbeit gilt erst als fertig, wenn ein Guard sie dauerhaft sichert — und ein Guard, den niemand absichtlich gebrochen hat, ist kein Guard." → Beweislage, Guard-Spalte und Kollisionsregel: 📐 Regelwerk · Guard-First.
Git versioniert die Entwicklung — aber nicht die Anwendung. Wenn eine Rechnung, eine Regel oder ein Prompt sich ändert, muss TGV später rekonstruieren können, mit welcher Version etwas entschieden wurde („Rechnung X entstand mit Projektregel v3 · Vertrag v2 · Steuerregel DE-2026.1 · Prompt vY · Freigabe Z"). Die neun Bereiche mit ehrlichem Stand — einiges existiert schon, als solches markiert:
| Bereich | Was versioniert werden muss | Stand heute (ehrlich) |
|---|---|---|
| Prompts | Version · Autor · Grund · Scope · gültig_ab · Rollback | teils prompt_config existiert echt+versioniert (ADMIN#01); Scope-Kaskade Mandant/Entität/Projekt = Ziel |
| Regeln | Global/Mandant/Entität/Projekt mit gültig_ab/bis | ⬜ Konzept — berührt KANON#01 (Design-Regeln haben Guards, aber keine Laufzeit-Versionen) + MANDANT#02 (Policy-Speicher-Lücke) |
| Skills | jede Ausführung speichert die Skill-Version | teils Registry-SSOT (02_SKILLS/_registry.yaml) + Versionen je Skill (z.B. contract-extract v0.2.2); Ausführungs-Log mit Version = Ausbau |
| Agenten-Doktrin | System-Prompt-Version je Rolle/Scope | teils CANON_LAYER (canon.py, SSOT-verlinkt) + 3-Schichten-Modell (Chatbot First §4); Versions-Historie = Ziel |
| Rechnungslogik | Land · Format · Steuer · Validator-Version | ⬜ Konzept — Semantic Invoice Core (Projekte §5) |
| Projektlogik | Nachträge + Änderungshistorie (Projekt v1→v2→v3) | ⬜ Konzept — Projekt Typ A (Projekte §2) |
| UI / render_hints | welche Karte/Komponente zeigte welches Ergebnis | ⬜ Ziel — Karten-Vertrag existiert (KI-First §3b), Anzeige-Log nicht |
| User-Freigaben | Approval-Entscheidung als revisionssicheres Log | teils approval_card-Muster + record_decision live; Vollausbau approval_decisions = Ziel |
| Provider | Modell/OCR/Storage/Mail-Provider + Datenresidenz je Vorgang | ⬜ Konzept — Provider-Registry (§4); heute hardcoded (LLM-Provider-Governance) |
| ⭐ Die Anwendung selbst | Welche Version der Shell/des Service ist gerade live, und aus welchem Commit? | teils Service ✅ (eigene Reihe, 0.57→0.59 in einer Woche); Shell dreifach inkonsistent — siehe Kasten |
v2.5.1, das Header-Element :2212 zeigt hart „v2.5", und der Kanon-Footer :13051 fällt per Regex-Fallback ebenfalls auf „v2.5" zurück. Die Anweisung „Versionsmarke beim Bump mitziehen" steht seit jeher im Kopf (:5) — aber sie hat keinen Guard. Ergebnis: ~15 Shell-PRs in einer Woche, null sichtbare Bumps.
_setBuildStamp (:2810-2823) liest data-build (:2212, Platzhalter {{BUILD}}), aber deploy_full injiziert den Hash nicht und der Last-Modified-Fallback greift nicht; angezeigt wird „staging". Damit stehen zwei Fußzeilen untereinander — Kanon-Bruch, denn es gibt genau EINE (EU · Vertraulichkeit · Version · Deploy-Stempel).
deploy_full injiziert Commit-Kurzhash + Deploy-Zeit in data-build ③ Build-Stempel wandert in die Kanon-Fußzeile, die zweite Zeile entfällt ④ Guard: rot, wenn ein core_shell-PR den Marker nicht bumpt oder Marker ≠ Header ⑤ schriftlich im Manifest-Kopf: Shell = MINOR je Screen-/Kanon-Welle, PATCH je Fix-PR; Service = eigene Reihe wie bisher.
JC-Entscheid 15.07.: EU-First beantwortet „WO und mit WEM werden Daten verarbeitet" — Compliance-First beantwortet „nach WELCHEN Regeln arbeitet TGV gerade, und kann TGV das BELEGEN?" Es ist die Ordnungsschicht über sechs Bereichen — die vorhandene KI-Regelung wird nicht ersetzt, sondern eingeordnet:
| Bereich | TGV-Ordnung | Wo es heute lebt |
|---|---|---|
| DSGVO / Datenschutz | Mandantentrennung, RLS, Vertraulichkeit, Löschung, Export, Datenminimierung | 🔒 Sicherheit (komplett: §2–§7, §10) Konzept steht |
| EU AI Act / KI-Governance | Risikoklasse, Human Oversight, Transparenz, Logging, Zweckbindung, Monitoring | Human-in-the-Loop (Human First §2) + Audit; AI-Act-Mapping ⬜ neu |
| E-Rechnung / Steuer | DE/FR/EU-Formate, Pflichtfelder, Validatoren, Archivierung, Übermittlungswege | Projekte §5 Invoice Core ⬜ neu (Pflicht: DE 2025 · FR 2026/27) |
| Business-Recht | Vertrag, Nachtrag, Leistungsumfang, Freigabe, Vollmacht, Zahlungsziel | VERTRAG#01 (contract-extract live) + Projekt-Versionierung teils |
| Cybersecurity / CRA / NIS2 | Security-by-design, Vulnerability-/Incident-Prozess, Provider-/Dependency-Monitoring | Sicherheits-Lernschleife (Sicherheit §9); Continuous-Monitoring ⬜ Ziel |
| Nachhaltigkeit / CSRD-ESRS | Projekt-/Unternehmensberichte, Förder-/ESG-Nachweise | ⬜ später aktivieren (JC-Entscheid G3) |
Zielbild ist eine COMPLIANCE-ENGINE mit sechs versionierten Regelquellen (privacy_rules · ai_governance_rules · invoice_rules · contract_rules · security_rules · reporting_rules) plus Regulatory Watch: Regulatorik (E-Rechnung, AI Act, CRA, NIS2, CSRD) ändert sich laufend — sie wird als beobachtete, versionierte Regelquelle geführt, nicht als einmalige Doku.
Terminologie-Abgleich (ehrlich): „EU-First" (Codex) ist kein neues Prinzip — es IST Bibel-Prinzip 5 „EU-SOUVERÄN". Neu ist die Verschärfung (JC-Entscheid A3): die Garantie wird nur ANGEZEIGT, wenn technische Checks grün sind. Der ehrliche IST-Stand je Stack-Komponente lebt in 🔒 Sicherheit §11 (Schnitt-Regel: dort der Stand, hier der Bauplan). Der Trust-Layer, der die Garantie prüfbar macht:
| Baustein | Was er beweisbar macht | Stand |
|---|---|---|
| provider_registry | Welcher Provider (LLM/Embedding/OCR/Storage/Mail/E-Invoice-Plattform), welches Land, DPA, Training ja/nein, Subprozessoren, Zertifikate, Evidenz-Link — keine Adressliste, sondern die technische Grundlage für Trust, Audit und Mandantenwahl | ⬜ Konzept (JC F1: Ja) |
| mandant_provider_policy | Erlaubte Provider je Mandant, z.B. „nur EU/EEA-Provider für Docs mit Vertraulichkeit ≥ vertraulich" — Premium-/Souveränitätsmerkmal | ⬜ Konzept (JC F2: Ja) · verzahnt Mandant-Modi Verwaltet/Souverän |
| data_residency_log + ai_processing_log | WO Daten verarbeitet wurden · welches Modell, Zweck, Datenklasse, Scope, Ergebnis — je Vorgang | ⬜ Konzept (JC F3: Ja) |
| security_self_audit | KAI erklärt den ECHTEN Systemzustand — check-basiert, nicht behauptet (JC F4) | ⬜ Konzept · Vorbild: r5_gate_proof-Muster (Sicherheit §9) |
| eu_first_badge | Das Badge erscheint NUR, wenn die technischen Checks grün sind — sonst nicht | ⬜ Ziel · verzahnt Badge-Kanon (EU-Chip) — heute zeigt der EU-Chip den KURS, nicht den Beweis |
Kein neues Prinzip, sondern die Beschaffungs-Form von EU-Souverän (Bibel-Prinzip 5): Open Source ist unsere Souveränitäts- und Beschaffungsstrategie — nicht unser Vertriebsmodell. Das TGV-Produkt selbst bleibt privat (bewusste Repo-Sichtbarkeit). Für jeden Fremd-Baustein gilt die Kaskade — in dieser Reihenfolge geprüft:
| Vorzug (in Reihenfolge) | Bedeutung | Gate je Baustein |
|---|---|---|
| ① Reuse | vorhandener TGV-Baustein zuerst | Lizenz zitierfähig · EU-Datenresidenz / No-Training · Ops-Kosten · Mandanten-Isolation |
| ② Open-Source, EU-self-host | Apache/MIT/permissiv, self-hostbar auf Hetzner-EU | |
| ③ Managed EU | z.B. Mistral — managed, kein Self-Host-Aufwand | |
| ④ US-proprietär | nur befristet / unkritisch, mit Migrationspfad |
| Baustein | Kern | Anschluss |
|---|---|---|
| Regulatory Watch | Regulatorik als beobachtete Quelle: regulatory_watch_items mit Versionen (z.B. „Steuer-/E-Rechnungsregel DE-2026.1") | Compliance-Engine §3 · Quellen: BMF-FAQ, impots.gouv.fr, EN 16931, AI Act, ISO 42001, NIST AI RMF |
| Deprecation-Pfad | Veraltete Prompts/Regeln/Skills werden MARKIERT und MIGRIERT (deprecated_capabilities), nicht still vergessen | genau die R-50/R-52-Lehre der Familie: Veraltung sichtbar machen (⚠-Kästen im Regelwerk) |
| Human-First messbar | gesparte Handgriffe · vermiedene Doppeleingaben · offene Entscheidungen · Zeit bis Rechnung · Fehlerquote · wie oft KAI sinnvoll NACHFRAGT statt rät | Human First (Nordstern Lebenszeit ↓ bekommt Metriken) · JC G4: Ja |
| Datenportabilität | Voll-Export · Projekt-Archivpaket · Rechnungs-/RAG-/Prompt-Export · Offboarding-Protokoll — Verkaufsargument UND DSGVO-Pflicht | Archivierung (Projekte §7) · Sicherheit §7 Lösch-Stufen |
| Governed AI Operations | TGV verkauft nicht „KI nutzt Tools", sondern governete KI-Betriebe: Lebenszyklus, Risiko, Doku, Monitoring, Human Oversight (AI Act / ISO 42001 / NIST-Richtung) | Markt-Differenzierer neben den vieren aus Chatbot First §5 |
| Punkt | Lage | Call |
|---|---|---|
| KONZEPT_v3 §1-Nachtrag | Prinzip 7 in START-HERE-Index UND Bibel-Quelle (KONZEPT_v3.md §1.5) verankert | ✅ erledigt 15.07. (Tower#24-GO) |
| Lane-Zuschnitt | Codex schlägt vor: COMPLIANCE#01 (Ordnung/Registry) · COMPLIANCE#EINVOICE · PLAT#? (Versionierung) — Lane-Namen und -Schnitt sind Tower-Hoheit | → Tower |
| Versionierungs-Andockung | Tower#24-Entscheid 15.07.: KEINE neuen Tabellen, erst Reuse-Inventar — (1) inventarisieren, was heute schon versioniert (prompt_config · learning_events · agent_events), (2) Lücken je Bereich benennen, (3) erst dann andocken/erweitern. Owner: KANON#01 (R-V4-19) + MANDANT#02 (Policy-Speicher). Kein Bau vor 31.07. (Buchhaltungs-Deadline hat Vorrang); Konzept darf laufen | entschieden (Bau gated) |
| Glossar-Pflege | Neue Begriffe (Nachhaltig-First, Compliance-First, Provider-Registry, Runtime-Versionierung, Semantic Invoice Core, Empty-Mandant) gehören ins Glossar | KONZEPT#01, mit nächstem Glossar-Pass |