TGV · Master-Konzept · Betrieb — Daten & Dokumente · Stand 2026-07-14

Dokumentmanagement im KI-Zeitalter

Du fragst nach Ergebnissen aus dem Inhalt deiner Dokumente — nicht „wo liegt welches Dokument". Dieses Konzept erklärt den Bereich „Dokumente & Ablage" TGV-weit; die verbindliche Quelle ist 00_LEITDOKUMENT/KONZEPT_DOKUMENTMANAGEMENT_KI_ZEITALTER_AUFBAU.md (Gate-A-Verfeinerung, JC 13./14.07.).

§1Der Paradigmen-Wechsel

„Im KI-Zeitalter fragst du nach ERGEBNISSEN aus dem Inhalt deiner Dokumente — nicht ‚wo liegt welches Dokument'."— Konzept-Brief, Kern-Satz. KAI durchsucht den Content (Metadaten + DB + RAG); du bekommst die Antwort, nicht den Ordner-Pfad.

Drei Sätze tragen den ganzen Bereich:

GrundsatzWas er bedeutet
Ablage = sichtbarer BEWEISDie Ablage ist der Beweis guter Ordnung — nicht dein Arbeitswerkzeug. Idealfall: du musst gar nicht mehr reinschauen. Die Verzeichnis-Ansicht existiert, damit du vertraust und kontrollierst, dass der Dokumentalist alles sauber eingeordnet und — vor allem — richtig geschützt hat (Geheimhaltung).
Selektiv, nicht allesKEIN Ersatz für 10-TB-Archiv, OneDrive-Massen oder Mail-Spam. Rein kommt das Geschäfts-/Steuer-/Rechts-Relevante, das TGV verarbeitet. (Das Auswahl-Kriterium ist eine offene Design-Entscheidung, §6.)
Zeitgewinn (Mission)Du sparst das Suchen UND das Sortieren — beides erledigt die Hintergrund-Maschine. Das ist Bibel-Prinzip 1 (Lebenszeit ↓) und Prinzip 2 (Touch Once) auf Dokumente angewandt.

§2Die Abgrenzung — zwei Bereiche, klar getrennt

JCs Kern-Frage beantwortet eine Grenze: die Ablage ist die Infrastruktur, die KI-Arbeit die Anwendung. Content-Suche gehört zu KAI; die Ablage zeigt Ordnung + Schutz.

🗂️ „Dokumente & Ablage" (dieser Bereich)

  • Ordnung · Verwaltung · Sicherheit
  • Wo + wie geordnet/geschützt — der Dokumentalist pflegt
  • Verzeichnisse · Vertraulichkeit · Kanäle · Parking/Raw · Benennung · Metadaten-Index
  • liefert die geordneten, indexierten, geschützten Dokumente

💬 KI-Arbeit mit dem INHALT (KAI/RAG, Chat)

  • Ergebnisse aus dem Content
  • Was steht drin + was bedeutet es — KAI antwortet
  • Fragen beantworten · zusammenfassen · verknüpfen
  • nutzt sie — siehe Chatbot First Facette „Antworten wo sie liegen"

§3Die zukunftsorientierte KI-Sicht — zwei Sucharten koexistieren

Der User denkt in Fragen und Ergebnissen, nicht in Ordnern. Die Ablage ist die Hintergrund-Maschine für Ordnung, Sicherheit und Auffindbarkeit — sie läuft automatisch (Dokumentalist). Die Content-Indexierung (RAG) macht jedes Dokument bedeutungs-auffindbar — nicht über den Pfad, sondern über den Inhalt. Vertraulichkeit wird automatisch + user-bewusst zugeordnet, nicht manuell pro Datei.

Wie die Stufe beim Upload/Intake entsteht (JC 19.07., Register #34) — Kurzfassung: a) Ordner-Erbe = Default (Datei nur strenger; ohne Kontext „Team der Entität") · b) ⛔ RAG fail-closed: neue Datei = „nur ich", bis der Vorschlag steht · c) ORCH schlägt vor mit Konfidenz-% (Signale: Erbe · Dokument-Typ · Mail-Absender+Empfänger) · d) User entscheidet nach Klär-Schwelle (Normalfall still mit Badge, 🔒-Kandidaten → Klärungs-Karte). Die vollständigen Regeln leben an EINER Stelle: Sicherheit · Einstufungs-Pipeline (Konsolidierungs-Gesetz: referenzieren statt doppeln).
SuchartRangFrageAntwortet
🧠 Content / KIprimär„Was haben wir mit Lieferant X vereinbart?" · „Alle Belege über 500 € im Q2?"KAI — aus Metadaten-DB + RAG-Chunks, mit Quellen-Beleg (R-91)
🗂️ Verzeichnis-Kontrollesekundär„Ist alles richtig einsortiert und richtig geschützt?"Die Verzeichnis-Ansicht — Vertrauen + Prüfen, v.a. der Geheimhaltungs-Badges

§3bWas in den Index kommt — und was nie

JC-Direktive 03.08. („Das gehoert im KONZEPT MASTER!!", Register #288). Die geltenden Regeln standen bis dahin nur im n8n-Workflow „RAG Ingest v0.2" (bdejCuX2AN6ptdz5) und im P5_WFB_INTEGRATION_PLAN.md — also in der Maschine, nicht im Kanon. Hier stehen sie als Regel; die Lese-Seite (wer den Index befragen darf) liegt in Chatbot First §9.

FrageAntwort (geltend)
WAS wird indexiertDer extrahierte Text → Chunks + Vektor-Embedding (OpenAI 1536 / Mistral 1024), dazu Volltext-Suche de+fr. NICHT die Rohdatei — die liegt im Storage und wird nie in den Vektorraum gelegt.
WANNAutomatisch am Ende der Kette, nicht beim Upload.
WER liestexecutors_rag → RPC search_knowledge_scoped (Mig 221 APPLIED): mandant_id hart, Entitäts-Verengung, Vertraulichkeits-Decke fail-closed (NULL → „streng"). Details: Chatbot First §9.
⛔ ENTSCHEIDEN 04.08. (JC, E-50① / Register #304) — die drei Filter sind AUFGEHOBEN: Indexiert wird alles außer echten Geheimnissen. Die Vertraulichkeit setzt künftig der Fach-Agent fachlich (R-178) statt der Ingest pauschal; „streng" bleibt Privatem, Personendaten und Gehältern vorbehalten. Das löst #288 und die Hiscox-Aussperrung #301. Offen: der Backfill der bestehenden Chunks — bis er läuft, ist der Bestand weiter nach der alten Regel eingestuft. Der Block darunter bleibt als Narbe stehen, damit nachvollziehbar bleibt, warum KAI monatelang Fotos und Notizen nicht fand (Konzepte fortschreiben, nie überschreiben).
⛔ ALT-STAND bis 04.08. — die DREI Filter, die unsichtbar wirkten — sie entscheiden, was KAI überhaupt finden kann: ① nur was finalState==done erreicht · ② nur Finanzbelege (RECHNUNG/STEUER) · ③ nur ab 120 Zeichen Inhalt. ⇒ Fotos, kurze Notizen und private Dokumente landeten NIE im Index. Das war der Grund, warum KAI sie nicht fand — kein Modell-Fehler, sondern eine Auswahl-Entscheidung, die niemand ausspricht. Belegter Fall (E-41.19): JC kann den Tacho-Beleg #8211 selbst ansehen, KAI antwortet wahrheitsgemäß „Mehr Inhalt steckt nicht in meinen Daten". Regel dazu: R-177 — ein unsichtbarer Filter ist eine Behauptung über Vollständigkeit.
✅ GEMESSEN 04.08. ~03:30–04:10 UTC (AGENT-ORCH#01, gegen die Live-DB) — die fuenf offenen Zahlen sind da. Der frühere „Messung ausstehend"-Block ist damit abgelöst. Was gemessen wurde, steht unten; was NICHT gemessen wurde, ist als Lücke benannt.
FrageGemessene Antwort
Greifen die drei Filter noch?⛔ JA, alle drei, live. Node Finalize im Skill-Router mvOybw4cBU7y8X5Y („TGV Skill Router v0.7.4", aktiv): finalState==='done' + Finanzbeleg-Typen + rContent.trim().length >= 120. Der Block steckt zusätzlich in einem äußeren done-Guard — Filter 1 wirkt doppelt. ⇒ E-50① ist NICHT wirksam: der Entscheid ist gefallen, der Code steht unverändert.
Chunk-Bestand / Backfill-Umfang1298 Chunks. confidentiality_level NULL: 0 — ⚠️ die Annahme „viele NULL" ist damit überholt. Verteilung: streng_vertraulich 1062 = 82 % · intern 113 · publishable_book 58 · private_gabriel_jc 29 · vertraulich 24 · family_close 6 · editorial_team 5 · excluded 1
Schreibt der Ingest conf/language/mandant?Zwei Pfade, gegensätzliche Antwort. n8n bdejCuX2AN6ptdz5: ⛔ nein/nein/nein, Vektorraum embedding (OpenAI 1536). Python ingest_core_privat.py: ✅ ja/ja/ja, embedding_mistral (1024)
rag_chunks.project_code99 von 1298 belegt (7,6 %) — und zwar ausschließlich Gabriel-Memoir; im TGV-Korpus 0. ⚠️ Ursache liegt eine Stufe früher: auch in der Quelle documents.project_code sind 0 von 219 Kandidaten belegt ⇒ der Ingest kopiert korrekt durch, es steht nur nichts zum Kopieren da
Mig 232 (lexikalischer Fallback)✅ appliziert, RPC existiert; tgv_migrations führt 221 · 227 · 232 · 238
⛔⛔ DER BEFUND, DER ALLES ANDERE ÜBERLAGERT: es gibt keinen automatischen RAG-Ingest. Gemessen: 1298 von 1298 Chunks sind mistral-embed, 0 OpenAI, und in agent_events steht kein einziges skill.rag-ingest-Ereignis (nur skill.rag01_core_privat.done 22 / .error 6). ⇒ Der Index wird von einem handgestarteten Python-Skript gepflegt. Die ONE-TOUCH-Kette aus E-26 („… → AUTO-RAG-Ingest, kein manueller Chunk-Schritt, nie") ist nicht halb gebaut, sondern gar nicht (Register #316/#317). Und der n8n-Pfad wäre, wenn er liefe, dreifach unsichtbar: falscher Vektorraum (beide Retrieval-RPCs lesen ausschließlich WHERE embedding_mistral IS NOT NULL, Mig 221:70 · 227 · 232:64), confidentiality NULL (fail-closed) und mandant_id NULL (matcht nie, auch nicht für den Owner).
⛔ Und deshalb wäre „die Filter öffnen" die falsche Lehre. Der Pfad hinter den Filtern ist tot — Öffnen erzeugt unsichtbare Chunks, kein Wissen (AGENT-ORCH#01 ausdrücklich). E-50① bleibt richtig, aber es ist der zweite Schritt, nicht der erste.
⚠️ KORREKTUR EINER ANNAHME, DIE HIER STAND: der Ingest stuft NICHT pauschal ein. classify_chunk_visibility() (ingest_core_privat.py:564) erbt eine vorhandene Stufe korrekt und fällt nur mangels Einstufung fail-closed auf „streng" zurück. Die wahre Kette: 189 von 191 prf_contracts haben confidentiality_level = NULL, weil der Fach-Agent nie lief → documents NULL → Chunks streng. ⇒ Die 82 % sind kein Einstufungs-Fehler, sondern der Schatten einer nie gelaufenen Kaskade (§4b/#303). Das schließt den Kreis zu R-173: fail-closed war hier korrekt — kaputt war die Zulieferung.
Ehrliche Lücken beim SCHREIBEN (#288, P5-Plan): (d) der Live-Ingest setzt confidentiality_level, language und mandant_id nicht — das Lese-Gate stuft fehlende Werte als „streng" ein, also korrekt vorsichtig, aber KAI findet möglicherweise nicht, was es finden dürfte (R-173). (c) Kein Auto-Purge stale Chunks bei Dubletten. Dazu: lexikalischer Fallback (Mig 232) ist im Code verdrahtet, DB-seitig STAGED. ⛔ Vorbedingung für alles: ohne API-Key am Embedding-Service ist die Wissenssuche tot (E-42-P1).

§3cWo der Index liegt, was drin ist — und was NICHT

JC 08.08., wörtlich: „Wo wird der Index gespeichert, pro Mandant, wann aktualisiert, was wird außer den Input-Dateien noch indexiert? Wird die Datenbank auch indexiert?" — er sagt dazu „ich kenne mich nicht aus". Deshalb steht es hier, nicht in einem Chat.

FrageAntwort — gemessen 08.08.
Wo liegt er?In derselben Datenbank, Tabelle rag_chunks (Supabase/Postgres + pgvector). Keine separate Suchmaschine, kein zweiter Dienst.
Welche Indizes?HNSW auf embedding_mistral (1024) = der Bedeutungs-Weg · GIN auf content_tsv + content_tsv_french = der Wortsuche-Weg. (Dazu ein Altbestand auf embedding 1536.)
Pro Mandant?Eine Tabelle, Spalte mandant_id + RLS — nicht ein Index je Mandant. Die Trennung ist eine Bedingung in der Abfrage, kein getrennter Speicher.
Was ist drin?1372 Chunks: core_privat 1193 · user_doc 80 · life_memory 99. ⇒ Nur Dokumente (und System-Doku), keine Geschäftszahlen.
⛔ Wird die Datenbank indexiert?NEIN. Beträge, Fristen, Salden kommen über Werkzeuge (executors_core, get_contracts_expiring …), nicht über den Index. ⭐ KAI findet einen Vertrag als DOKUMENT, aber die Frist darin über ein WERKZEUG — zwei Wege zu denselben Daten, und nur einer heißt „Index". Welches Datum was bedeutet (Beginn ≠ Frist ≠ Stichtag, je Dokumentart, gemessen): Datenfluss §6 Datums-Semantik →
Wann aktualisiert?Beim Ingest — und nicht laufend: ein Chunk erbt Stufe und Mandant im Moment des Chunkens. Ändert sich das Dokument danach, trägt der Chunk den alten Stand, bis er neu gezogen wird (Chatbot First §9e).
⛔ Die eine offene Stelle, richtig verortet (gemessen 08.08.): 99 Chunks tragen keine mandant_id — und es sind AUSSCHLIESSLICH die 99 Gabriel-Chunks (life_memory_*). Kein einziger TGV-Chunk ist betroffen (0 von 1273).
⇒ Das ist kein Loch in der Mandantenwand, sondern die Gegenrichtung: die RPC filtert mandant_id = ANY(...) — ein Chunk ohne Mandant ist für jeden unsichtbar, auch für seinen Eigentümer. Der Mandant existiert (gabriel · „Gabriel · Mémoire de vie"); die Chunks zeigen nur nicht auf ihn.
⭐ Und es ist zugleich der beste Beleg für JCs Typ-A/B-Frage: derselbe Speicher, zwei Projekte — und die Aussage über „die Wand" hängt davon ab, welches man meint. Ein Typ-B-Befund, kein TGV-Leck. offen

§4Aspekte & Funktionen — mit ehrlichem Stand

Die JC-Liste aus dem Brief als Element-Tabelle. Reuse-Grundsatz (R-V4-19): nichts davon wird neu erfunden — jede Zeile nennt ihren Anker; im Gate B des jeweiligen Screens wird der Reuse verifiziert.

AspektWas es heißtReuse-AnkerStand heute (ehrlich)
⬆ Asynchroner UploadUpload-Queue blockiert die Inbox nicht — Dateien laufen im Hintergrund einGabriel-Upload · PLAT#07 Async-Jobs (Vision)teils bei Gabriel angelegt — im Gate B zu verifizieren; TGV-CORE-Verdrahtung offen
📥 Kanäle je Mandant + je UserMail-Catch-All (mandant-getrennt) · Drive · Upload · Foto · Chat-Drag&Drop — Verwaltung pro Mandant UND pro User im ProjektMail-Kanon (EINE email-IMAP) · Pipeline-Intake (Datenfluss §1)teils Mail/Drive-Intake läuft (Pipeline); die Kanal-Verwaltung (UI je Mandant/User) = zu bauen
🛡 Vertraulichkeit + UsergruppenGeheimhaltung klar und user-bewusst zugeordnet (.ds-axis, kein Schloss) + wer sehen darf (Identity/RLS-Gruppen)Badge-Kanon · Sicherheit §3/§4teils .ds-axis V4 kanonisch (R-116/R-120) · Governance v1.1 GELOCKT · RLS-Fundament steht; Endpoint-Scope-Guard erst 2/57 (Lücken-Landkarte)
🪄 Wizard: Ordner + NamenDer Dokumentalist schlägt Verzeichnisse UND Dateinamen vor, User bestätigt — Dialog, kein FormularWizard-Engine (KONZEPT_WIZARD_ENGINE) · Dokumentalist⬜ zu bauen Konzept steht; Bau GO-gated
🅿 Layer: Parking + RawRoh-Datei ZUERST sichern (save_raw), Unklares ins Parking statt ratenPIPELINE#01 Intake e2estaged gebaut in PIPELINE#01, Deploy JC-gated — Fluss-Invariante Nr. 1 (Datenfluss)
🔗 Quellen benannt + verlinktJede Quelle trägt Namen + klickbaren Link — nie nackte IDs (GOLDENE REGEL: Beleg-ID immer mit Drive-Link)R-91 Beleg-LinkRegel ⚙ kanonisch verankert; Konsumenten ziehen lane-weise nach
🔎 Meta-Index + Content-SucheMetadaten in der DB (Supabase) indexiert; Content im Vektorraum (RAG) — beides zusammen beantwortet Fragendocuments-Tabelle · RAG#01 (Vektorraum, Mistral-OCR, Reranker)teils Meta-DB live · RAG#01 reaktiviert; „Kai fragen"-RAG-Zugang heute NICHT verdrahtet (JC-Prio, 3 Lanen staged)
🌳 Struktur: Default vs. individuellKAI schlägt den Default vor (Entität ▸ Jahr ▸ Typ), pro Mandant anpassbar — im Setup als Erzählung, kein FormularKONZEPT_DATENVERZEICHNIS (§5, am Badge-Punkt korrigiert)Konzept ✅ Bau (Drag&Drop, Drive-Sync, Dokumentalist-Logik) GO-gated

§5Ablage-Struktur & Dateiverzeichnis — der Kontroll-Blick

Aus dem Struktur-Konzept (Dateiverzeichnis & Dokumentalist, JC-Direktive 27.06.: „TGV ersetzt jede andere Ablage — wenn Verwalten sehr einfach ist"). Der Default, den KAI im Setup vorschlägt:

<Entität>  (C3 GmbH · C4 · Privat)
  └ <Jahr>  (2025 · 2026 …)
      ├ Rechnungen   intern
      ├ Verträge     vertraulich
      ├ Banking      intern
      ├ Steuer       vertraulich
      ├ Projekte ▸ <Projekt Typ A>   intern
      └ (Privat) Gesundheit          streng vertraulich
⚠ Quell-Doku am Badge-Punkt korrigiert: Das Struktur-Konzept (01_ITERATIONS/AGENT_UX_01_DESIGN_GUARDIAN/KONZEPT_DATENVERZEICHNIS.md) zeigte Schutzlevel als 🔒-Schloss-Symbole — überholt. Kanonisch ist die 3-Achsen-Badge-Systematik .ds-axis (Entität · Konfidenz · Geheimhaltung; JC-Entscheide 13.07., Guards R-116/R-120 — Badge-Dossier). Das Quell-MD trägt jetzt einen Korrektur-Vermerk; Rest (Struktur, UI-Pattern, Wording) bleibt gültig.

Das UI-Pattern ist kein roher Explorer-Klon, sondern drei Elemente + KI-Check: Ordner-Baum (mit Geheimhaltungs-Badge + Anzahl) · Datei-Liste (Listen-Standard: sortieren, blättern, Thumbnails) · Aktionen (Neuer Ordner · Umbenennen · Verschieben · Export). Jede Verschiebung prüft der Dokumentalist vor dem Ausführen mit einer Bestätigungs-Karte (ApprovalCard-Muster): „Du verschiebst X nach Y. ⚠ Y ist streng vertraulich — passt das? Vorschlag: besser Z." — Ordnung bleibt erhalten, der User behält die Kontrolle (Human-in-the-Loop, Human First).

§5bDer Dokumentalist — Bestandsaufgabe, nicht Laufzeit-Aufgabe Gate-A, Bau ab 07.08.

JC 04.08. (E-53, Register #256): „Der Dokumentalist-Agent sollte auch bald aktiv werden." — Ernte zuerst: Der Ablage-Kanon dafür existiert seit STORAGE#01 und ist reicher, als „Ordner-Regeln" vermuten lässt (00_LEITDOKUMENT/ABLAGE_KANON.md, 99 Zeilen).

Was der Kanon schon entscheidetFundstelle
Entität = Rechnungsempfänger (Bill-to), nie Zahlstelle/Konto/Mailbox — mit maschinenlesbarer Signal-Priorität: billto_ustid → billto_text → db_entity → unassignedABLAGE_KANON §1
Ordner-Kanon je Art (Beleg · Vertrag · Parking · Rejected · _RAW immutable); Jahr/Monat aus dem Rechnungsdatum, nicht dem Verarbeitungsdatum§2
⛔ Unklares wird unassigned + Parking — NIEMALS privat. „privat" ist eine echte Entität, kein Sammelbecken (behebt JCs „eine Zeit lang wurde alles privat" an der Wurzel)§3
Vier empirisch belegte Verbote: kein natives „New Folder" (37 entstanden, versteckten Verträge) · Infrastruktur nie trashen · Race-Guard bei Ordner-Anlage · Roh vor DB-Zeile (Wurzel der dateilosen Belege)§4
Benennung + Beleg-Nummer · Guard-Checks fail-loud§5/§6
⛔ Und der Kanon enthält bereits seine eigene Reihenfolge — sie ist noch nicht erfüllt.ABLAGE_KANON §7 (Tower#19): ① PIPELINE#01-Intake-Wurzeln → ② dieser Ablage-Kanon → ③ dann der Dokumentalist. Mit der Begründung, die heute zur Messlatte wird: „Ein Ordnungs-Agent, der aufräumt, während der Intake weiter falsch anlegt, ist Sisyphos."
⛔⛔ GEMESSEN 04.08.: Bedingung ① ist NICHT erfüllt — der Intake legt weiterhin memoir-geprägt ab, und zwar BAUARTBEDINGT. Der Schlüssel-Bauer 08_OPS/credentials/_storage.py:64-65 trägt hartcodiert PROJECT_PREFIX = "oeuvre-de-vie" (Kommentar: „Gabriel's only project") und FILE_PREFIX = "MB-LM-Gabriel", dazu _DEFAULT_FOLDER = "autres" als Auffangnetz. Benutzt wird er von einem TGV-Skill: tgv-skill-rka-pdf-burst (CORE/FES-Lane, Reisekosten-Belege von C3) ruft _storage.build_key(...) (skill.py:638). ⇒ Deshalb liegen C3-Rechnungen unter oeuvre-de-vie/autres/MB-LM-Gabriel_… — das ist die Regel, nicht der Einzelfall (RKA#10), und es ist die strukturelle Ursache des Fahrtenbuch-Befunds „#8211 im Gabriel-Bereich". Klasse: R-184/R-168 — ein Hardcode, der eine Mandanten-Annahme einfriert. ⛔ Und es ist das DRITTE Glied einer Familie, die in einer Nacht dreimal auftauchte — an drei Schichten: ① Schema — prf_contracts.mandant_id text DEFAULT 'jcbinetti' (Mig 193, der stille Ersatzwert) · ② Code — mandant_id:"jcbinetti" konstant im Skill (#313, die aktive Ursache, inzwischen korrigiert) · ③ Namensbildung — dieser Gabriel-Prefix. Wer sie einzeln repariert, übersieht die vierte (Schwester-Suche, R-174). Das Tückische an allen dreien: sie waren einmal wahr und sind es seit dem ersten weiteren Mandanten nicht mehr — nicht falsch geschrieben, sondern richtig geschrieben und dann überholt. Register: #323.

⇒ Würde der Dokumentalist heute die 293 Objekte umsortieren, wäre das wörtlich der Sisyphos-Fall aus dem eigenen Kanon. Erst die Schlüssel-Wurzel mandantenfähig machen, dann sortieren.
✅ Stand 19.09. (ABLAGE#04, Register #2171/#2173): Bedingung ① ist erfüllt, der Bestand bleibt. Seit #1679 (09.08.) ruft kein TGV-Weg mehr build_key. Er steht nur noch in save_and_link (_storage.py:604), und das rufen nur die drei Gabriel-Skills. Neuester TGV-Beleg mit Gabriel-Präfix: #8211. Eingefroren bleiben 211 TGV-Zeilen (188 autres + 23 RKA-scans). 199 davon liegen im richtigen Bucket, nur ihr Name ist falsch; 12 liegen im fremden. Sie heilt 08_OPS/ablage04_heile_altschluessel.py, ein Rufer, der den Zielpfad bei der Endstation erfragt statt ihn selbst zu bilden. Trockenlauf ist die Vorgabe, --apply ist JCs Hand. Ein Bucketwechsel bleibt gesperrt, bis Weg A/B/C (#1278/#1630) entschieden ist. Damit erfüllt das Werkzeug die Auflage aus §5c: Manifest Quelle → Ziel je Objekt, Rückweg im Zwischenstand.
⛔ Die Ablage entscheidet keine Entität. Sie ergänzt nur, wo die Triage keine gesetzt hat.Gelernt an #8419 (16.09.): Die Triage sagte c3. Die Endstation nahm die Firma des Lieferanten aus der Lieferanten-Tabelle (privat) und legte den Beleg in den privaten Bucket. Seit store-file v0.9.1 gilt: supplier_entity/counterparty_entity füllen nur ein unassigned, wie _build_patch seit #1278 (unbestimmt → bestimmt ist Ergänzung, bestimmt → anders bestimmt ist Entscheidung). Der Einwand „der Lieferant kennt die Firma manchmal besser als die Triage“ ist berechtigt, gehört aber in die Einstufung (ORCH, aus dem vollständigen Inhalt), nicht als Wenn-Dann-Regel aus dem Lieferantennamen in den Ablage-Weg. Der Lieferantenname sagt, WER geschrieben hat, nicht WEM der Beleg gehört.

Der Bestand, den er vorfindet (gemessen, Register #320): 723 Dokumente · 449 ohne Storage-Key · 388 nur auf Drive · 61 ohne jeden Ablageort (32 Karteileichen · 8 wiederfindbar · 8 „Mail ist das Original" · 13 nur per IMAP) · 188 ohne lesbaren Text — für jede Suche unsichtbar, auch für KAI. ⇒ Der Auftrag ist überwiegend Bestand, nicht Laufzeit: er sortiert nicht nur Neues ein, er räumt Gewachsenes um.

⚠️ Und ein Bereich bleibt ausdrücklich AUSSEN VOR: tgv-mb-lm-gabriel (99 reale Objekte). RKA#10 hat ihn aus der Namens-Systematik ausgenommen, und E-51.3 (Gabriel und TGV wachsen zusammen) macht ihn zu einer eigenen Entscheidung — nicht zu einem Nebenprodukt einer Aufräum-Aktion. ⇒ Der Dokumentalist fasst ihn nicht an. Das ist keine Lücke, sondern eine gesetzte Grenze: es sind dieselben 99 Chunks, die als einzige project_code tragen und als einzige ohne mandant_id stehen — ein anderes Scoping-Modell, das erst entschieden und dann angefasst wird, nie umgekehrt.
Neuer Beleg-Typ, den er beherrschen muss: „Original = E-Mail" (Register #318, 8 gemessene Fälle). Bei Uber-/Apple-/Riverty-Bestätigungen gibt es keine Datei — die Nachricht IST das Original. Sie fehlen nicht, sie werden bisher nur als fehlend dargestellt. ⇒ Der Dokumentalist muss diesen Typ einsortieren können, ohne einen leeren Datei-Slot zu erzeugen; „kein Storage-Key" ist hier ein gültiger Endzustand, kein Defekt. Sonst produziert die Aufräum-Aktion 8 neue Falsch-Rot-Meldungen (R-173: leer ist nicht kaputt — und kaputt ist nicht leer).

§5c⛔ Verschieben ist eine Freigabe-Handlung — die Reihenfolge-Regel

Die Frage (Tower#32): Sortiert der Dokumentalist um, bevor die Vertraulichkeit fachlich eingestuft ist — oder danach? Die Antwort ist keine Reihenfolge, sondern eine Monotonie-Regel, und sie folgt zwingend aus zwei Sätzen, die bereits im Kanon stehen.

Ein Ordner trägt eine Reichweite, und die Datei erbt sie (K-41). Wer verschiebt, verteilt also Sichtbarkeit — auch wenn er nur aufräumen wollte.Daraus folgt: eine Verschiebung ohne geprüfte Einstufung ist eine unbelegte Freigabe. Nicht falsch abgelegt — sondern ungeprüft veröffentlicht.
⛔ DIE REGEL (abgeleitet, nicht neu erfunden):
① Verengen darf er immer. Ein Zug in eine engere oder gleich enge Reichweite ist jederzeit erlaubt — dieselbe Logik wie beim Scope (§8: die innere Ebene verengt, sie widerspricht nie der äußeren) und beim Session-Scope, der nur verengen darf.
② Erweitern nie ohne fachliche Einstufung. Ein Zug in eine weitere Reichweite setzt voraus, dass die Vertraulichkeit vom Fach-Agenten fachlich gesetzt wurde (E-50①/R-178) — nicht vom Dokumentalisten selbst. Er ordnet, er stuft nicht ein.
③ Unklassifiziert ⇒ Parking, nicht Zielordner. Fehlt die Einstufung, gilt unassigned + _PARKING/needs_review (ABLAGE_KANON §3) — sichtbare Warteschlange statt stillem done.
⇒ Damit löst sich das Entweder-Oder auf: er darf sofort anfangen — aber nur in die enge Richtung. Die 293 Objekte zerfallen in die, die er heute schon räumen kann (Verengung/gleiche Reichweite), und die, die auf den Fach-Agenten warten. Kein Stillstand, kein Risiko.
⛔ Gegenbeweis vor der ersten Bewegung — Bestandsaufgaben-Auflage: Bevor irgendetwas bewegt wird, liegt ein Trockenlauf-Manifest vor: je Objekt Quelle → Ziel mit Reichweiten-Delta (enger / gleich / weiter). Jede Zeile mit „weiter" ist gesperrt, bis eine fachliche Einstufung vorliegt. Und der Rückweg wird mitgeschrieben: eine Umsortierung ohne Umkehrpfad ist keine Ordnung, sondern ein Umzug ohne Adressbuch. Das ist dieselbe Beweislast, die für jeden Scope-Fix gilt (R-173: fail-closed ist die Richtung, nie der Beweis) — hier auf Dateien statt auf Abfragen angewandt.

Rolle: Der Dokumentalist ist ein Agent, kein Skill (E-52-Test): „Wohin gehört dieses Dokument?" ist eine Entscheidung unter Mehrdeutigkeit — Entität, Projekt, Ordner, Reichweite. Er gehört damit als Fach-Agent in die Zuständigkeits-Registry (R-178) und darf ein stärkeres Modell rufen. Das Verschieben selbst bleibt Skill — Agent ≠ alles selbst machen.

§5dEin Papier, zwei Bücher — der Interco-Beleg Entwurf BELEG#01, 05.09. · JC-Ball

JCs Frage (05.09.), sein Satz: „Es gehört in BEIDE!! C3 für die Lohnbuchhaltung und Privat als eigener Nachweis. Es ist der gleiche Fall wie KM-Abrechnung, Rechnungen zwischen C3–C4 usw." — Der Fachbegriff dafür ist Interco-Beleg. Er ist nicht neu und nicht TGV-spezifisch: dasselbe Papier trägt in zwei Büchern zwei verschiedene Bedeutungen.

Die Zuordnung eines Belegs beantwortet heute die Glossar-Probe „WEM GEHÖRT DER BELEG?" (Entität) — und bei diesen Fällen hat die Antwort zwei Namen.Deshalb erzählt jede Einzel-Zuordnung die halbe Geschichte: ein Gehaltsbeleg bei C3 ist Lohnaufwand und für JC privat der Einkommensnachweis, den ihm sonst niemand ausstellt.
⛔⛔ DIE ENTSCHEIDUNG IST NICHT NEU — sie steht seit dem 27.08. mit JC-Freigabe. konzept_multimandant §8 hat den Fall bereits beantwortet: „ein Dokument, aber NICHT eine Zeile … Zwei Ausfertigungen heissen zwei Zeilen mit je eigener entity — nicht eine Zeile, die über die Wand schielt." Dieser Abschnitt ersetzt §8 nicht, er schreibt ihn fort — um das Stück, das dort offen blieb: woran erkennt man, dass zwei Zeilen dasselbe Papier sind, und wer von beiden bucht?
⛔⛔ WARUM DIE NAHELIEGENDE LÖSUNG (eine Zeile, zwei Entitäten) AUSSCHEIDET — gemessen, nicht vermutet. BELEG#01 hat live gefragt, welche Entität unter welchem Mandanten liegt: alle sechs Entitäten liegen 1:1 in sechs verschiedenen Mandanten — c3-convis-gmbh→c3-convis · c4-convis-sarl→c4-convis · privat→jcbinetti. ⇒ Jeder Interco-Fall des Hauses quert eine Mandantenwand. Eine einzelne Zeile mit einer Rollen-Nebentabelle müsste im Mandanten c3-convis einen Nachweis für den Mandanten jcbinetti tragen — das ist die Narbe vom 22.07. mit umgekehrtem Vorzeichen. Die Doppelbuchung ist ein Buchhaltungsfehler; die Wand zu queren ist ein Datenabfluss.
DAS MODELL — zwei Zeilen, ein Band, je eine Rolle: beide Zeilen bleiben (die Wand verlangt es), und zwei Felder machen aus ihnen ein Papier mit klarer Buchungslage.
① interco_gruppe (uuid) — beide Zeilen tragen dieselbe. Das Band ist damit maschinell lesbar, statt wie im Anlassfall #8016 aus dem Betreff geraten zu werden (§8: „das tragfähige Merkmal liegt verteilt über zwei Felder").
② buchungsrolle — ausgang · eingang · aufwand · ertrag (buchend) · nachweis · erstattung (nicht buchend). Sie sagt, WAS die Entität mit dem Papier tut — die Frage, die counterparty_entity seit Iter 42 offen lässt.
⭐⭐ DER RIEGEL GEGEN DIE DOPPELBUCHUNG FOLGT AUS DER BAUART, NICHT AUS DISZIPLIN. Nicht „zwei Zeilen" ist die Gefahr, sondern „dieselbe buchende Rolle zweimal in derselben Gruppe." ⇒ ein partieller UNIQUE-Index über (interco_gruppe, buchungsrolle), nur für die vier buchenden Rollen. nachweis und erstattung bleiben unbegrenzt, weil sie nichts buchen. Ein und derselbe Constraint trägt beide Fälle, die JC genannt hat — den mit einer Buchung und den mit zweien.
JCs FallZeile AZeile BBuchungen
Gehalt #8372/#8379
je 10.500 €		c3-convis-gmbh · aufwand
Lohnaufwand		privat · nachweis
Einkommensnachweis		EINE — nachweis bucht nicht
Rechnung #8393
16.320 €		c3-convis-gmbh · ausgang
Forderung		c4-convis-sarl · eingang
Verbindlichkeit		ZWEI — verschiedene Rollen, Riegel hält
KM-Abrechnung
(von JC benannt)		c3-convis-gmbh · aufwand
Reisekosten		privat · erstattung
Anspruch gegen C3		EINE — erstattung bucht nicht
⭐ Was mit den bestehenden Feldern geschieht — Reuse vor Neubau, und eine Altlast wird beendet.
entity bleibt unverändert — sie ist je Zeile das eine Buch, und §8 verlangt ausdrücklich, dass sie beim Intake wandert und nie im Nachtrag.
project_id löst den Fall NICHT (Mig 249): sie ist eine andere Hoheit — Zuschnitt, nicht Eigentum. Zwei Achsen, die verschiedene Fragen beantworten, ersetzen einander nicht.
⛔ counterparty_entity (Mig 086) wird abgelöst, nicht ausgebaut. Von 9 gefüllten Werten sind 4 counterparty = entity (ein Transfer zu sich selbst ist keine Information) und 2 tragen fremde Parteien (RATP, Senat — Kunden, die auf die Debitor-Achse gehören), obwohl ihr eigener Kommentar „die ANDERE eigene Entity" verlangt. Nur 2 der 9 Werte bedeuten, was die Spalte behauptet — und diese 2 sind ausgerechnet #8372/#8379: JCs Fall war seit Iter 42 eingetragen, nur konnte ihn niemand sehen.
⛔ Und sie hätte die Vokabular-Kluft vertieft: ihr Soft-FK zeigt auf entity_signatures.entity, das gabriel-binetti führt, während entities.slug gabriel führt — ein drittes Namenspaar neben dem von SICHERHEIT#05 gemessenen. ⭐⭐ Das Zwei-Zeilen-Modell entgeht dem, weil es gar keinen neuen Entitäts-Träger einführt: die Entität ist je Zeile das vorhandene documents.entity. Wer kein zweites Namensfeld anlegt, kann auch kein zweites Vokabular erben. ⛔ Und ein FK wäre hier ohnehin nicht baubar — gemessen: documents.entity trägt heute keinen einzigen Constraint (kein FK, kein CHECK — Freitext), und entities ist UNIQUE über (mandant_id, slug), nicht über slug allein. Derselbe Slug darf per Schema in zwei Mandanten existieren — ein FK auf entities(slug) ist damit technisch unmöglich, nicht bloss ungebaut. Das ist die Wurzel der Vokabular-Kluft und gehört SICHERHEIT#05s Bahn.
⛔⛔ DIE ABGRENZUNG, an der schon zweimal danebengegriffen wurde — sie gehört zum Modell, nicht in eine Fussnote.
Ein Entitäts-Widerspruch ist NICHT dasselbe wie ein Interco-Beleg, und die beiden Mengen überlappen nur zum Teil:
⇒ Entitäts-Widerspruch: „gehört dieser Beleg zu C3 oder zu C4?" — EINE richtige Antwort, die andere ist ein Fehler. Beispiel #8030: eine AWS-Rechnung (fremder Lieferant), Zeile steht auf c3-convis-gmbh, der Orchestrator schlug c4-convis-sarl vor. Das ist eine Zuordnungsfrage — sie gehört der Ablage-Bahn, nicht hierher.
⇒ Interco-Beleg: „welche Rolle spielt dieses Papier bei C3, und welche bei C4?" — ZWEI richtige Antworten gleichzeitig, weil zwei Bücher betroffen sind. Beispiel #8393: Ausgangsrechnung bei C3, Eingangsrechnung bei C4.
⭐⭐ Die Probe, die sie trennt: hat der Beleg einen FREMDEN Dritten (Amazon, ein Kunde, ein Lieferant), oder stehen sich zwei EIGENE Entitäten gegenüber? Nur im zweiten Fall gibt es zwei Bücher — im ersten gibt es ein Buch und eine offene Frage.
⛔ DIE MENGE — und die erste Zahl, die ich hatte, war eine RICHTIGE ZAHL ZUR FALSCHEN FRAGE.
Gemessen an der ROLLE (das einzige Merkmal, das einen zweiten Buchungskreis wirklich behauptet): 18 von 861. Neun tragen party_role='transfer', neun party_role='intern'. ⛔ Davon sind genau ZWEI vollständig — #8372/#8379, die als einzige Rolle und eine Gegenseite und zwei verschiedene Entitäten tragen. Bei vieren zeigt die Gegenseite auf sich selbst, bei zwölf fehlt sie ganz. Die Achse existiert seit Iter 42 und ist praktisch unbenutzt — das ist der eigentliche Befund, und er begründet dieses Modell besser als jede grosse Zahl.
⛔⛔ WAS DIE ZAHL NICHT IST — der Irrtum benannt, statt ihn zu glätten: Eine erste Messung zählte 83 Belege, bei denen Eimer oder Pfad der entity widersprechen. Diese 83 sind KEINE Interco-Menge. Der Blick in die Pfade zeigt es: es sind Anthropic-, Google-Cloud- und Mietplatz-Rechnungen, die im Ordner DOCUMENTS/PRIVAT/ liegen und entity=c3-convis-gmbh tragen. Das ist eine Fehlablage — ein Beleg am falschen Ort, nicht ein Papier in zwei Büchern. ⭐ Ein Ordner-Widerspruch sagt „hier stimmt etwas nicht", nie „dieser Beleg gehört in zwei Kreise". Wer beides zusammenzählt, misst Unordnung und nennt sie Struktur. ⛔ Und 13 dieser 83 sind nicht einmal meine Messung: sie sind der bereits erhobene Bestand von ABLAGE#03 (#1630 — „13 statt 11 im fremden Eimer"), derselben Bahn, aus deren Befund zu #8372/#8379 JCs Frage überhaupt entstand. Die Ablage-Achse gehört dort, nicht hier.
⛔ EHRLICHE GRENZE, benannt statt verschwiegen: der UNIQUE-Index wirkt unter der RLS und ist damit mandantenblind — das MUSS er sein, sonst riegelt er nicht. Er verrät dabei die Existenz einer Gruppen-ID über die Wand, nie deren Inhalt. Das ist derselbe Handel, den §8 für _doc_lookup_by_sha schon eingegangen ist: „Finden ohne Scope ist richtig; urteilen ohne Scope ist es nicht."
⛔ JCs zweite Sorge ist ein ANDERES Thema — dieses Modell löst sie ausdrücklich NICHT. Sein Satz: „damit wenn ein Bucket gelöscht wird, der andere es nicht verliert." Das ist Sicherung, nicht Ablage. Redundanz gehört auf die Eimer-Ebene; doppelte Belegzeilen als Backup zu bauen wäre genau die Doppelbuchung, vor der dieser Abschnitt schützt. ⭐ Was die Bytes heute schützt, hat §8 schon gemessen: save_raw läuft vor der Dubletten-Prüfung — es gibt Objekte im Eimer, auf die keine Zeile mehr zeigt. Der Schutz ist heute die Versionierung des Anbieters, nicht TGV; ein zweiter, getrennter Ablageort fehlt — das ist die Bahn der Eimer-Wand (SICHERHEIT#04), nicht diese.

Stand: Entwurf mit PROPOSED_281_beleg01_interco_gruppe_und_buchungsrolle.sql — nicht gefahren, DDL ist JCs Hand. Die Nummer ist gegen tgv_migrations gezogen (DB 280, Verzeichnis 279). Offen und bewusst nicht vorentschieden: wer die zweite Zeile anlegt — Intake, Dokumentalist oder JC von Hand — und ob die 83 Bestandsfälle nachgezogen werden. Das ist eine Freigabe-Handlung im Sinne von §5c und gehört nicht in eine Migration.

§5eFotos — eine Datei, viele Zusammenhänge entschieden · JE-211 · 11.10.

JCs Frage (11.10.), sein Satz: „Es geht darum, bei echten Fotos, dass TGV auch in der Lage ist, es zuzusortieren: Entität, ggf. Projekt oder nach einer Zuordnung vom User. […] Privat xxFOTOS / Jahr / Monat oder XXFOTOSAMMLUNG / Thema-Titel / Jahr / Monat?“

⚠ Stand heute, gemessen 11.10.: Eine Rechnung als Foto läuft in den Belegweg und wird gelesen (#7615, #8246). Ein echtes Foto wird erkannt und beschrieben (bild_art=anderes + ein Satz), die Beschreibung endet aber im Rohtext eines Protokoll-Eintrags. Die Datei liegt ohne Entität in tgv-raw-unassigned. Drei Fotos stehen als „Quittung“ im Bestand, weil bild_art nichts steuert.
⭐ ENTSCHIEDEN 11.10. (JE-211): „Foto sind dann eher ERINNERUNGEN die wir nach Jahr/Monat sortieren mit ggf. eine Gruppierung zu einem TAG.“ ⇒ Ein Foto ohne Belegmerkmale verlässt die Belegliste und kommt ins Erinnerungs-Regal — über die Gabriel-Mechanik (genre='photo'), im Eimer seiner Entität. Jahr/Monat aus media_meta.captured_at, der TAG ist ein Etikett. Bau: FOTO#02. Offen: Form der Bestätigungs-Karte, US-Modell je Mandant.
⭐ Drei Ausgänge, nicht zwei (JE-212): Beleg → Belegweg · Information (ablesbarer Wert, z. B. Kilometerstand → Fahrtenbuch) bleibt mit dem Wert in der Klärung, bis sein Abnehmer ihn übernimmt · Erinnerung → Erinnerungs-Regal. Einteilung im Bildzweig (SOUVERAEN#03), Weitergabe im Dispatcher (FOTO#02).
📋 Abschluss der Bahn (17.10.): vier offene Antworten mit Vorschau — zwei Merges, sechs Gabriel-Fotos, Erinnerungsfotos in den Gedächtnisraum.
Die Regel aus der Vorlage (①, ②, ④ durch JE-211 bestätigt): ① physisch einmal — Eimer der Entität, FOTOS/{Jahr}/{Monat}/ nach Aufnahmedatum (Schwesterform von DOCUMENTS/{Jahr}/{Monat}/). Thema, Projekt, Reise und Personen sind Etiketten (tags, project_code), keine Ordner — Touch Once: ein Foto, viele Zusammenhänge, keine Kopie. ② je Foto gemerkt: Kamera-Metadaten (media_meta) · Ortsname · Beschreibung, Szene, Zahl der Personen (ai_image_analysis, Form aus Gabriel/Mig 173) — Namen nur vom Nutzer, nie per Gesichtserkennung. ③ Zuordnung als Vorschlag, eine Karte je Serie (Ort+Zeit), Privat nur bei positivem Signal. ④ Ohne Belegmerkmale kein Belegweg (Ausgang „kein Beleg“: SOUVERAEN#03). ⑤ Bilder nur an ein EU-Modell; Abweichung je Mandant und Aufgabe erst, wenn der Kostenkanal sie zählt.
Die Vorlage mit beiden Varianten als Grafik, sechs OK-Fragen und dem Vorschlag für die neun vorhandenen Fotos: 📷 Fotos — wohin, was merken, wem zuordnen?

§5fSteuerrelevanz — eine Achse neben Entität und Belegart entschieden · JE-216 · 11.10.

JCs Satz (11.10.): „Wir haben Buchhaltungsrelevant aber AUCH STEUERRELEVANT. Eine Rechnung zur Brille ist relevant für die private Steuer. […] Es kann auch als Arbeitsmaterial zur Steuererklärung-Vorbereitung-Prozess genutzt werden!“

⚠ Stand heute, gemessen 11.10. (nur lesend): Die Entität beantwortet „wem gehört der Beleg buchhalterisch“; „in wessen Steuererklärung zählt er“ hat keinen Ort. Drei halbe Ansätze liegen nebeneinander, keiner im Einsatz: txn_master.tax_tag → md_tax_tags (0 von 1.640 Buchungen) · tax_filings (eine Mappe, Belegliste leer, ohne Mandant/Person/Land) · tgv-skill-tax-extract (12 Kategorien, in keinem Worker-Set, 14 Läufe, US-Modell, überschreibt documents.status). 11 Privatbelege liegen unter „vertraulich“ (Stufe „intern“; ohne Stufe gilt schon als streng, rag_conf_rank(NULL)=6). Die Brillen-Rechnungen #8527/#8528 liegen seit 02.10. im Bestand und tragen kein Steuer-Merkmal.
⭐ ENTSCHIEDEN 11.10. (JE-216: „Ja B“, alle vier Empfehlungen; JE-217: drei Prozesse des Steuer-Agenten) — die Regel aus der Vorlage STEUER#03: ① Steuerrelevanz ist eine Zuordnung, kein Häkchen — ein Beleg oder eine Buchung zählt in 0…n Erklärungen; jede Zuordnung nennt Kategorie, Status (Vorschlag · bestätigt · verworfen) und Quelle; die Mappe (tax_filings, ausgebaut) trägt Steuerjahr, Person (md_persons), Land (DE/FR) und Mandant. Die Entität bleibt unberührt — eine C3-Gehaltsabrechnung gehört der C3 und ist Arbeitsmaterial für JCs Erklärung. ② ORCH schlägt vor, der Mensch bestätigt — EU-Modell, ein Schritt in der bestehenden Kaskade (tax-extract), nie automatisch gültig. ③ Die Mappe ist das Arbeitsmaterial — gegliedert nach der Checkliste des Beraters, mit Lückenliste (STEUER#01 P3), Übergabe nur mit Freigabe-Karte. ④ Datenschutz: eine Steuer-Zuordnung hebt den Beleg auf mindestens vertraulich, Gesundheit auf streng vertraulich, und senkt nie; Sicht aus der Mitgliedschaft des Aufrufers, auch für KAI. ⛔ TGV rechnet keine Steuer und sagt nicht, was absetzbar ist — finden, ordnen, liefern.

§5gBildherkunft — ein Merkmal am Bild, nicht ein Satz auf der Seite entschieden · JE-218 · 12.10.

Anlass: Brief Expats §A13 (11.10.) — Annas Seite ordnet je Bild einen Hinweis zu („mit KI erstellt“ / „Adobe Stock, teils mit KI bearbeitet“), der im Fuß erscheint. Für TGV: „Herkunft eines Bildes als Metadatum führen, nicht als Freitext auf jeder Seite.“ Register #4115 → #4118.

⚠ Stand heute, gemessen 12.10. (nur lesend): Jedes Bild — Beleg, Foto, Gabriel-Erinnerung — ist eine documents-Zeile; media_meta (Mig 239) trägt Aufnahmezeit, Kamera, GPS, aber keine Herkunft (source:"exif" meint die Quelle der Metadaten). Kein Herkunfts- oder KI-Feld in 05_SCHEMA, 02_SKILLS, 06_DASHBOARD, 08_OPS. TGV erzeugt keine Bilder — die Anbieterpflicht (Art. 50 Abs. 2 KI-VO) trifft es nicht; es hilft Mandanten bei der Verwenderpflicht (Abs. 4, seit 02.08.2026 anwendbar, vom Omnibus nicht verschoben).
⭐ ENTSCHIEDEN 12.10. (JE-218, ①–④ ja · Auflage „NUXIN und HARMONISIEREN mit GABRIEL!“): ⑤ Schalter je Mandant: Ⓐ Symbol am Bild (Standard) oder Ⓑ gesammelt (maschinenlesbar in der Datei + Bildnachweis-Seite). ⛔ Riegel: ein Bild mit wirkt_echt (Deepfake, Art. 50 Abs. 4 + 5: erkennbar spätestens beim ersten Sehen) bekommt das Symbol auch in Ⓑ. Der Bildnachweis ist eine andere Pflicht (§ 13 UrhG, Lizenz) und darf immer gesammelt stehen · ⑥ ein Weg: der EXIF-Leser (vision-extract/skill.py:688) wird ein Baustein, den auch Gabriels Fotoweg aufruft (ocr-to-source schreibt heute kein media_meta). Bau: MEDIA#02, Register #4126.
Die Regel aus der Vorlage (Vorlage MEDIA#01, durch JE-218 bestätigt): ① ein Feld media_meta.herkunft, vier Werte: Aufnahme · teils KI · KI-erzeugt · unbekannt (+ Bildnachweis, + wer gesetzt hat); ohne Eintrag „unbekannt“, nie still „Aufnahme“ · ② nichts erfunden: Werte = IPTC Digital Source Type, Zeichen = EU-Symbole („Fully AI-Generated“ / „Partially AI-Modified“), beim Eingang aus der Datei gelesen · ③ jede Fläche setzt den Hinweis selbst: öffentlich (Website, veröffentlichtes Megabook) Symbol am Bild + Bildnachweis; innen eine Panel-Zeile; ein Beleg „KI-erzeugt“ wird Klärfall · ④ ein Symbol, eine Bedeutung: das Bild-Symbol ist nicht das Abzeichen „KI-Vorschlag“ (kai_renderer.js:384).

§6Ehrliche Lücken & offene Design-Entscheidungen

Storage-Realität (nicht beschönigt): STORAGE#01-Audit ROT — 136/705 Dokumente ohne Datei; die Migration Drive→Hetzner (mandanten-getrennt + provider-flexibel) ist geplant, nicht vollzogen. Und BR#04 hat gezeigt: ohne Test/Prod-Isolation (is_test-Flag) landen Testbelege in der Prod-Ablage. Beides sind Vorbedingungen für das Versprechen „Ablage = Beweis guter Ordnung".

Bewusst OFFEN gelassen (im A–E-Prozess der jeweiligen Screens zu klären, nicht hier vorentschieden):

Offene EntscheidungDie FrageWo sie fällt
Ein Dokument, zwei MandantenWann ist eine zweite Ausfertigung eine Dublette und wann eine eigene Zeile mit eigener Rolle (C4-Ausgang ⇄ C3-Eingang)? Heute tilgen drei mandanten-blinde Mechanismen sie.konzept_multimandant §8 (Modell, JC-Freigabe 27.08.) + §5d (Band & Rolle, BELEG#01 05.09.) — Modell steht, JC-Ball ist jetzt nur noch die Migration
Auswahl-KriteriumWas kommt in TGV rein, was bleibt draußen (Selektivitäts-Grenze)?Gate A „Dokumente & Ablage" + JC
Datenhaltung / RetentionAufbewahrungsfristen, große Dateien, Papierkorb-Logik (Hetzner)STORAGE#01 / Migration
Kanal-VerwaltungGenauer Schnitt Mandant-Kanäle vs. Projekt-User-KanäleGate C mit Multi-Mandant
FotosAblage nach Entität+Aufnahmedatum mit Etiketten — oder Themen-Ordner? Was wird je Foto gemerkt, wer ordnet zu?Vorlage FOTO#01 → §5e — Grundsatz entschieden (JE-211), Karte + US-Modell offen
SteuerrelevanzWie hält TGV fest, dass ein Beleg in einer Steuererklärung zählt (Person, Jahr, Land, Kategorie) — Felder am Beleg, Zuordnung + Mappe oder nur Etikett? Wer erkennt, wer bestätigt?Vorlage STEUER#03 → §5f — entschieden (JE-216/JE-217), Bau STEUER#04–#06
BildherkunftWoher stammt ein Bild — Aufnahme, teils KI, KI-erzeugt? Wo wird es gekennzeichnet (Website, Megabook, Belege), damit Art. 50 KI-VO ohne Handarbeit erfüllt ist?Vorlage MEDIA#01 → §5g — entschieden (JE-218): Feld am Bild, Schalter je Mandant, ein Weg mit Gabriel; Bau MEDIA#02
Default-Struktur je MandantWie stark weicht ein Mandanten-Default vom TGV-Default ab?Onboarding-Wizard (Anna = erster Fall)
SSOT & Anschlüsse: 00_LEITDOKUMENT/KONZEPT_DOKUMENTMANAGEMENT_KI_ZEITALTER_AUFBAU.md (verbindlich, Gate-A-Verfeinerung) · Struktur-Detail: KONZEPT_DATENVERZEICHNIS.md (mit Korrektur-Vermerk) · der Fluss dahinter: 📄 Datenfluss / Touch Once · Schutz: 🔒 Sicherheit & Datenschutz First · die Content-Seite: 💬 Chatbot First + 🧠 KI-First (RAG) · Kanäle je Kunde: 🏢 Multi-Mandant. Pflege: Intention ändert sich NUR in der SSOT — diese Seite zieht nach (KONZEPT#01 wacht).