# KI-Provenienz im GitLab-Archiv
```{raw} html
```
Mit **Archive** sichern Sie einen abgeschlossenen Chatstand in GitLab. Halten Sie dafür das Archiv-Symbol unter einer Antwort eine Sekunde gedrückt. Dabei entstehen ein versionierter Commit und ein Link auf genau diesen Stand. Im Agentenmodus werden auch die zugehörigen Arbeitsdateien archiviert.
chatBHT und `gitlab.chatbht.com` verwenden dieselbe institutionelle Anmeldung. Die zusätzliche GitLab-Freigabe erlaubt chatBHT, das von Ihnen gewählte Repository als Archiv zu verwenden.
## So entsteht der Nachweis
Sie wählen einen Chatstand aus, archivieren ihn und übernehmen den Commit-Link in Ihre Arbeit. Nach einer Sekunde Gedrückthalten wird der Archivstand geprüft. Bei internen oder öffentlichen Repositories bestätigen Sie anschließend die Freigabe; erst danach entsteht der Commit.
```{include} ../_includes/chatbht-archive-information-flow.md
```
```{admonition} Nachweis und Quelle unterscheiden
:class: important
Die **wissenschaftliche Quellenangabe** belegt, woher eine fachliche Aussage stammt. Der **KI-Nutzungsnachweis** dokumentiert, wie generative KI am Arbeitsprozess beteiligt war. Beide Angaben ergänzen einander; keine ersetzt die andere.
```
## GitLab einmalig verbinden
Für die Archivierung benötigt chatBHT ein Repository auf der angebundenen GitLab-Instanz. Die Einrichtung erfolgt im Einstellungsfenster. Danach steht die Quellenangabe direkt unter den KI-Antworten bereit.
### Schritt 1: Einstellungen öffnen
Öffnen Sie **Einstellungen** über das Zahnrad in der Kopfzeile oder über **Account → Einstellungen** in der Seitenleiste. Wählen Sie im Fenster den Reiter **Archive**.
```{include} ../_includes/ui-account.md
```
### Schritt 2: Mit GitLab verbinden
Wählen Sie im Reiter **Archive** die Schaltfläche **GitLab verbinden**. Falls die Integration noch nicht eingerichtet ist, zeigt die App dies hier an.
```{include} ../_includes/ui-gitlab-settings.md
```
Die institutionelle Anmeldung und die GitLab-Freigabe erfüllen zwei unterschiedliche Aufgaben:
- Das **Single Sign-on** stellt sicher, dass chatBHT und GitLab dieselbe institutionelle Identität verwenden.
- Die **GitLab-Freigabe** erlaubt chatBHT zusätzlich die ausdrücklich bestätigten Repository-Aktionen im Namen dieser Person.
Ist bereits eine institutionelle GitLab-Sitzung geöffnet, kann die Anmeldung ohne erneute Eingabe von Zugangsdaten fortgesetzt werden. GitLab zeigt dennoch die Berechtigungsfreigabe an. Diese Freigabe ist nutzerbezogen, serverseitig gespeichert und widerrufbar.
Nach erfolgreicher Verbindung kehren Sie zu chatBHT zurück. Im Archivbereich erscheinen der GitLab-Benutzername, der Status **Verbunden** und die verfügbaren Archivziele.
### Schritt 3: Repository auswählen oder anlegen
Die beiden Schaltflächen **Vorhandenes Repository** und **Repository neu anlegen** stehen direkt oben im Bereich **Archive**, vor Verbindungsstatus und Archivzielliste. Sie können ein vorhandenes GitLab-Projekt verwenden oder hier ein neues Repository anlegen.
```{include} ../_includes/ui-gitlab-repositories.md
```
#### Vorhandenes Repository auswählen
1. Wählen Sie **Vorhandenes Repository**.
2. Wählen Sie ein beschreibbares GitLab-Projekt aus.
3. Geben Sie bei Bedarf einen bestimmten Branch an. Ohne Angabe wird der Standard-Branch verwendet.
4. Legen Sie den Zielordner fest. Der voreingestellte Ordner lautet `chatbht`.
5. Bestätigen Sie mit **Als Archivziel verwenden**.
In der Projektauswahl erscheinen nur Projekte, für die das verbundene GitLab-Konto ausreichende Schreibrechte besitzt und deren Repository initialisiert ist.
```{include} ../_includes/ui-gitlab-picker.md
```
#### Neues Repository erstellen
1. Wählen Sie **Repository neu anlegen**.
2. Vergeben Sie einen eindeutigen Repository-Namen, zum Beispiel `ki-nutzungsnachweise`.
3. Wählen Sie die Sichtbarkeit. **Privat (empfohlen)** ist voreingestellt.
4. Bestätigen Sie mit **Anlegen und auswählen**.
chatBHT erstellt das Projekt über die GitLab-Schnittstelle, initialisiert es und setzt es unmittelbar als Archivziel. Für ein internes oder öffentliches Repository ist eine zusätzliche ausdrückliche Bestätigung erforderlich: Der vollständige Chat und – im Agentenmodus – der gesamte Arbeitsstand werden damit für angemeldete institutionelle Nutzer beziehungsweise für alle im Internet lesbar.
```{include} ../_includes/ui-gitlab-create.md
```
#### Archivziel festlegen
Öffnen Sie die Einstellungen ohne aktiven Chatbezug, wird ein ausgewähltes Repository zum **Standard-Archivziel**. Öffnen Sie sie aus einem konkreten Chat heraus, kann stattdessen ein **Archivziel für diesen Chat** festgelegt werden. Angezeigt werden nur Repositories, auf die der verbundene GitLab-Nutzer Zugriff hat; die HTML-Ansichten zeigen das Beispielkonto **demo**.
Die ausgefüllte Optionsschaltfläche kennzeichnet das aktive Ziel. Mit **↗** öffnen Sie das Repository in GitLab; mit **×** entfernen Sie es aus der Liste der konfigurierten Archivziele. Das GitLab-Projekt selbst wird dabei nicht gelöscht.
#### GitLab-Verbindung trennen
Wählen Sie im grünen Verbindungsfeld **Trennen**, um die Verknüpfung aufzuheben. chatBHT versucht dabei, die GitLab-Freigabe zu widerrufen, und entfernt die lokal gespeicherte Verbindung. Bereits erzeugte Commits und Repositories bleiben in GitLab erhalten. Sie unterliegen weiterhin den dort vergebenen Zugriffsrechten.
## Chat archivieren und Commit-Link kopieren
Nach der einmaligen Einrichtung befindet sich die Archivierungsaktion rechts unten unter jeder abgeschlossenen KI-Antwort – neben der Umschaltung zwischen Markdown und Plaintext sowie der Kopierfunktion. Im Agentenmodus erscheint der zugehörige Worktree mit den erzeugten Dateien unmittelbar unter der Antwort.
### Vor dem Archivieren
Unter der Antwort steht das Archiv-Symbol. Ein Commit-Link erscheint erst nach einer erfolgreichen Archivierung. Prüfen Sie zuerst den gesamten Chat und gegebenenfalls die Arbeitsdateien.
```{include} ../_includes/ui-response.md
```
Die Vorschau ist bedienbar: Halten Sie das Archiv-Symbol gedrückt, um den Ablauf mit Beispieldaten auszuprobieren. Dabei werden weder Daten übertragen noch echte Commits angelegt.
### Eine Sekunde gedrückt halten
Schon beim Antippen erscheint ein schmaler Hinweis mit **Halten**, einem kleinen Ring und **1,0 s**. Während des Haltens füllt sich der Ring im Uhrzeigersinn; die Zeit läuft in Zehntelsekunden bis **0,0 s** herunter. Auch auf dem Smartphone bleibt die Anzeige klein und mit Abstand zum Finger.
```{include} ../_includes/ui-archive-hold.md
```
Ein kurzer Tipp zeigt nur den Hinweis. Lassen Sie vor Ablauf los oder ziehen Sie den Finger vom Symbol weg, wird abgebrochen: Der Ring läuft wie eine Wählscheibe zurück, die Zeit kehrt auf **1,0 s** zurück. Der Hinweis bleibt kurz sichtbar und verschwindet auch beim Antippen einer anderen Stelle. Jeder neue Versuch erfordert wieder eine volle Sekunde; mehrere kurze Tipps addieren sich nicht. Mit der Tastatur fokussieren Sie das Symbol und halten **Leertaste** oder **Enter**; **Escape** bricht ab. Bei aktivierter reduzierter Bewegung wird der Rücklauf ohne Animation zurückgesetzt.
### Institutionelle Freigabe prüfen
Nach dem Halten prüft chatBHT das Ziel und den aktuellen Inhalt. In einem **privaten** Repository wird der geprüfte Stand direkt archiviert. Bei **Intern** öffnet sich **Institutionell teilen?** – auf Englisch **Share within the institution?**.
```{include} ../_includes/ui-archive-release.md
```
Das Fenster nennt Repository, Branch, Nachrichtenanzahl, Arbeitsdateien und den Empfängerkreis. **Intern** bedeutet: angemeldete institutionelle GitLab-Nutzer können den Archivstand gemäß den GitLab-Zugriffsregeln lesen. Es geht um eine GitLab-Momentaufnahme; einen öffentlichen Chat-Link erstellen Sie separat über [Chat teilen](../sharing-collaboration/share-a-chat.md).
Prüfen Sie auch mitgespeicherten persönlichen Kontext. Setzen Sie erst dann das Bestätigungshäkchen. Dadurch wird **Freigeben und archivieren** aktiv:
```{include} ../_includes/ui-archive-release-approved.md
```
Mit **Abbrechen** oder **Escape** entsteht kein Commit. Bei **Öffentlich** zeigt das entsprechende Fenster ausdrücklich, dass die Inhalte im Internet lesbar werden. Das Halten allein bestätigt diese Freigabe nicht.
### Nach dem Commit
Warten Sie nach der Freigabe auf das grüne Häkchen und den **Commit-Link**. Öffnen Sie den Link oder kopieren Sie die Linkadresse für Ihre Referenzangabe.
```{include} ../_includes/ui-archive-result.md
```
Der Link verwendet die vollständige Commit-Kennung und keinen veränderlichen Branch-Verweis. Er führt deshalb zu genau der Archivdatei, die mit diesem Commit erzeugt wurde. Nach dem Neuladen oder erneuten Öffnen des Chats bleibt die erfolgreiche Archivierung an der Antwort sichtbar.
Archiviert wird der gesamte, bis zu diesem Zeitpunkt abgeschlossene Chat, einschließlich des gespeicherten persönlichen Kontexts. Im Agentenmodus wird zusätzlich der vollständige zugehörige Arbeitsstand in denselben Commit aufgenommen. Erneutes Halten prüft den aktuellen Stand; identische Inhalte erzeugen keinen doppelten Commit.
## Chatarchiv und GitLab-Nachweis unterscheiden
In der Oberfläche gibt es zwei Archivierungsaktionen mit unterschiedlichen Ergebnissen. Im Chatverlauf wählen Sie im Drei-Punkte-Menü **Archivieren**, um ein Gespräch aus der normalen Verlaufsliste zu nehmen. Unter einer abgeschlossenen Antwort halten Sie das **Archiv-Symbol** gedrückt, um den geprüften Chat und im Agentenmodus den Worktree in GitLab zu sichern.
| Aktion | Was Leserinnen und Leser erhalten |
| --- | --- |
| **Archivieren** im Chatverlauf | Ein archiviertes Gespräch im selben chatBHT-Konto. Dabei entsteht weder ein GitLab-Commit noch ein öffentlicher Nachweis. |
| **Archiv-Symbol** unter einer Antwort | Ein GitLab-Commit mit abgeschlossenem Chat, erfasstem Kontext, Provenienz und gesichertem Worktree. Der Commit-Link fixiert diese Version. |
```{include} ../_includes/ui-chat-menu.md
```
Einen [freigegebenen Chat-Link](../sharing-collaboration/share-a-chat.md) erstellen Sie gesondert mit **Teilen**. Über ihn kann die ausgewählte Zielgruppe das Gespräch in chatBHT lesen; er ist nicht der GitLab-Commit. Das folgende Beispiel zeigt beide Links: Das Gespräch lässt sich in der App ansehen und der gespeicherte GitLab-Nachweis unabhängig davon prüfen. Temporäre Chats können nicht nach GitLab übertragen werden.
## Was wird archiviert?
Das lesbare Markdown-Protokoll beginnt mit einer YAML-Kopfzeile und führt die Nachrichten in Reihenfolge auf. Im selben Commit stehen ein JSON-Provenienznachweis und im Agentenmodus bytegenaue Kopien regulärer Worktree-Dateien.
| Teil des gesicherten Stands | Was er nachvollziehbar macht |
| --- | --- |
| **Chat-ID, Titel und Zeitstempel** | Welches Gespräch gesichert wurde und wann Nachrichten und Archivstand erfasst wurden. |
| **Nachrichten, Rollen und erfasster Kontext** | Was gefragt und geantwortet wurde; Modellroute und Personalisierung erscheinen, sofern sie aufgezeichnet wurden. |
| **SHA-256-Inhaltshash** | Welche kanonischen Chatdaten und welcher Worktree-Dateikatalog zu dieser Momentaufnahme gehören. |
| **Worktree-Dateikatalog und Dateien** | Namen, Größen und SHA-256-Prüfsummen der gesicherten Dateien sowie deren ursprüngliche Bytes. |
| **`chatBHT-provenance.json`** | Beziehungen zwischen erfasster Person, Chatprozess, Modellroute, Nachrichten und Dateien sowie Archivziel und ausdrücklich benannten Nachweisgrenzen. |
Die Standardstruktur lautet:
```text
chatbht/chats//-.md
chatbht/chats//-/chatBHT-provenance.json
chatbht/chats//-/worktree/
```
Ein leerer Agentenordner wird durch eine `.gitkeep`-Datei dargestellt. Git-interne Metadaten werden nicht in den Worktree-Stand kopiert. Symbolische Links werden nicht verfolgt; ein Fund stoppt die Archivierung, statt eine Datei stillschweigend auszulassen. Identische Inhalte werden im selben Projekt und Branch nach Prüfung wiederverwendet; ein veränderter Chat oder Worktree erzeugt eine neue Version.
## Beispiel: ein Agentenlauf, ein öffentlicher GitLab-Commit
Am **15. September 2026** bat ein Nutzer einen Agenten um einen publikationsreifen grafischen Beweis von `(a + b)² = a² + 2ab + b²`. Der Prompt verlangte genau zwei Ergebnisse: eine kurze englische `README.md` und eine zugängliche, eigenständige SVG-Datei. Im archivierten Chat stehen der Prompt und eine Assistant-Antwort. Der Worktree enthält beide angeforderten Dateien; dazu kommen die Provenienzdatei und eine `.gitkeep` für den leeren Ordner `artifacts/`.
[Öffnen Sie den freigegebenen Chat in chatBHT](https://chatbht.com/chat/shared/c457be1a-935d-44b0-86c6-58b83307d4ef/), um das Gespräch in der App anzusehen. Das ist eine gesonderte öffentliche Ansicht des gleichnamigen Chats; der GitLab-Commit unten ist der fixierte Archivnachweis.
[Öffnen Sie den genauen Archiv-Commit ba895503c93ff202a2d6d3c08568452aadec27d0](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/commit/ba895503c93ff202a2d6d3c08568452aadec27d0) im öffentlichen Repository `open-weight-models-benchmark`. Alle folgenden Links verwenden diese Commit-Kennung und nicht `main`; sie zeigen damit weiterhin diesen Stand, auch wenn sich der Branch ändert.
| Nachweis in diesem Commit | Ansehen | Archivierte Bytes herunterladen |
| --- | --- | --- |
| Chatprotokoll mit YAML-Kopfzeile | [Markdown](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/blob/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523.md) | [Markdown herunterladen](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/raw/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523.md) |
| Provenienzdatei | [`chatBHT-provenance.json`](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/blob/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/chatBHT-provenance.json) | [JSON herunterladen](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/raw/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/chatBHT-provenance.json) |
| Erklärung des Agenten | [`README.md`](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/blob/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/worktree/README.md) | [README herunterladen](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/raw/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/worktree/README.md) |
| Grafischer Beweis | [`first-binomial-theorem.svg`](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/blob/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/worktree/first-binomial-theorem.svg) | [SVG herunterladen](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/raw/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/worktree/first-binomial-theorem.svg) |
Im [Worktree-Verzeichnis dieses Commits](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/tree/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/worktree) können Sie beide Arbeitsdateien gemeinsam prüfen. Das folgende SVG ist eine lokale Kopie der archivierten Datei. Nach Veröffentlichung wird die Abbildung deshalb auch von `docs.chatbht.com` geladen.
```{figure} ../_static/images/first-binomial-theorem.svg
:alt: Flächenbeweis der ersten binomischen Formel mit einem Quadrat der Seite a plus b, unterteilt in a Quadrat, zwei a-mal-b-Rechtecke und b Quadrat
:name: first-binomial-theorem-archive-example
:width: 720px
Das im Agenten-Worktree gesicherte SVG: Vier beschriftete Teilflächen machen die Flächengleichung sichtbar. Seine SHA-256-Prüfsumme lautet `92cd8fa76e50fcd25a6013c95f7f09b3b27d2cc3ca90a98ae3f8fa860114fe33`.
```
### Metadaten des Archivstands lesen
Die Markdown-Datei beginnt mit der folgenden Kopfzeile aus diesem Beispiel. Der Modellwert benennt das im Chat gespeicherte Modell; die weiter unten erfasste Route nennt das Modell und den Provider der Assistant-Erzeugung gesondert.
```yaml
schema: "chatbht.archive/v2"
chat_id: "27721406-bf85-47c7-8264-910844d79ec3"
title: "First Binomial Theorem - DeepSeek V4 Flash 0731"
archived_at: "2026-09-15T00:12:55.354889+00:00"
model: "deepseek_v4_flash"
message_count: 2
worktree_file_count: 2
worktree_total_size: 4528
content_sha256: "e4dd09c71523230a8c47c00c824531ecb2d4e1dba40b4e684805f996e41b92ff"
```
Die 4.528 Bytes sind die Summe der beiden gesicherten Worktree-Dateien, nicht die Größe des ganzen Repositories. Das Protokoll hält `generation_routing` als Agentenmodus mit Modell `deepseek-v4-flash-0731` und Provider `deepseek` fest; außerdem ist aufgezeichnet, dass Erinnerungen deaktiviert waren und keine verwendet wurden. Diese Angaben beschreiben, was chatBHT für diesen Lauf erfasst hat. Das neue Beispiel enthält weder ein archiviertes Sitzungsprotokoll noch Tokenverbrauchseinträge; die Tokenzahlen des früheren Beispiels gelten hier nicht.
### Die drei P: Prompt, Process, Provenance
Die [Provenienzdatei im selben Commit](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/blob/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523/chatBHT-provenance.json) verwendet Beziehungen des W3C-PROV-Modells. Die **drei P** bilden für die Archivpraxis eine Lesereihenfolge; sie sind keine wörtlichen JSON-Feldnamen:
| P | Was Sie in diesem Beispiel prüfen |
| --- | --- |
| **Prompt (Auftrag)** | Lesen Sie die Nutzernachricht im [archivierten Chatprotokoll](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/blob/ba895503c93ff202a2d6d3c08568452aadec27d0/chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523.md). Sie verlangt genau `README.md` und `first-binomial-theorem.svg`, beschreibt den Flächenbeweis und fordert eine Prüfung. Die JSON-Datei erfasst den Prompt außerdem als Nutzernachricht `7144`, mit Zeitstempel und Zuordnung zur verbundenen Person. |
| **Process (Ablauf)** | Folgen Sie der erfassten Assistant-Erzeugung nach diesem Prompt: Nachricht `7145`, Agentenmodus, Modell `deepseek-v4-flash-0731` und Provider `deepseek`. Antwort und zwei Worktree-Dateien zeigen das gesicherte Ergebnis. Für die GitLab-Archivierung folgen eine Sekunde Halten, Prüfung und bei diesem öffentlichen Repository eine ausdrückliche Freigabe vor dem Commit. Nicht jeder Laufzeiteingang und kein Agenten-Sitzungsprotokoll sind erfasst. |
| **Provenance (Herkunftsnachweis)** | Anhand der commitgebundenen JSON- und Dateilinks prüfen Sie, welche Person den Stand ausgewählt hat, welches öffentliche Projekt und welcher Branch ihn aufgenommen haben, wann archiviert wurde und welche Bytes gesichert sind. Die JSON-Datei verknüpft Prompt, Erzeugung und Dateiobjekte, liefert Prüfsummen und benennt fehlende Zuordnungen oder Beglaubigungen ausdrücklich. |
Einige ausgewählte Felder der JSON-Datei zeigen, wo der Stand gesichert wurde und wie weit die Beglaubigung reicht:
```json
{
"schema": "chatbht.provenance/v1",
"capture": {
"archived_at": "2026-09-15T00:12:55.354889+00:00",
"branch": "main",
"gitlab_origin": "https://gitlab.chatbht.com",
"project_id": 20,
"selected_by": "https://auth.chatbht.com/o/subjects/55",
"visibility": "public",
"markdown_path": "chatbht/chats/27721406-bf85-47c7-8264-910844d79ec3/first-binomial-theorem-deepseek-v4-flash-0731-e4dd09c71523.md",
"markdown_sha256": "7d141f8b052c13c31a6a181df04a84d72123fb6b03db12a84d4fdfac7b79a157"
},
"attestation": {
"signed": false,
"trusted_timestamp": false
}
}
```
`selected_by` bezeichnet hier die erfasste Identitätsreferenz, `project_id` das GitLab-Ziel und `markdown_path` den Ort des Chatprotokolls darin. Die JSON-Datei wurde mit Protokoll und Arbeitsdateien in denselben Commit geschrieben; sie enthält selbst noch nicht die danach erzeugte GitLab-Commit-Kennung. Der Commit-Link benennt diese feste Version.
Der tatsächliche Graph-Eintrag des SVG hilft besonders beim Prüfen einer heruntergeladenen Datei:
```json
{
"@id": "./worktree/first-binomial-theorem.svg",
"@type": "prov:Entity",
"generation_attribution": "not_recorded",
"sha256": "92cd8fa76e50fcd25a6013c95f7f09b3b27d2cc3ca90a98ae3f8fa860114fe33",
"size": 3223
}
```
`generation_attribution: "not_recorded"` ist eine bewusst ausgewiesene Grenze: Das Archiv erhält die SVG-Bytes und die Aussage des Assistant über seine Arbeit, belegt aber nicht unabhängig, welcher einzelne Modellaufruf oder welche menschliche Änderung die Datei erzeugt hat. Ebenso steht bei der Erzeugungsaktivität `input_context_completeness: "not_recorded"`: Der erfasste Prompt ist verknüpft, ein vollständig gespeicherter Laufzeitkontext wird nicht behauptet. Die Provenienzdatei ist weder signiert noch mit einem vertrauenswürdigen Zeitstempel versehen. Die kurzzeitig gültige signierte Prüfung vor dem Commit ist ein anderes Verfahren.
Für das öffentliche Archivziel verlangt die Oberfläche eine Freigabebestätigung. Die JSON-Datei enthält aber kein gesondertes Ereignisprotokoll dieser Geste; `capture.visibility` hält die Sichtbarkeit des Ziels zum Archivierungszeitpunkt fest.
### Den fixierten Archivstand nachvollziehen
Die GitLab-Commit-Kennung fixiert eine Repository-Version. `content_sha256` in der Markdown-Datei benennt die kanonischen Chatdaten und den Worktree-Dateikatalog dieses Archivstands; es ist nicht die SVG-Prüfsumme. `capture.markdown_sha256` prüft die exakten Bytes des Protokolls; jedes Worktree-Dateiobjekt hat seine eigene SHA-256-Prüfsumme. Leserinnen und Leser können den festen Commit öffnen, das Chatprotokoll lesen, die Provenienzbeziehungen prüfen, Dateien herunterladen und ihre Prüfsummen vergleichen. Das öffentliche Repository macht diese Links ohne GitLab-Konto zugänglich; der [freigegebene Chat](https://chatbht.com/chat/shared/c457be1a-935d-44b0-86c6-58b83307d4ef/) ist eine gesonderte Ansicht des Gesprächs.
## Sichtbarkeit des Archivs festlegen
Neue Repositories werden standardmäßig privat angelegt. Die passende Sichtbarkeit richtet sich nach dem Arbeitskontext und dem Schutzbedarf der Inhalte.
| Sichtbarkeit | Zugriff und geeignete Verwendung |
| --- | --- |
| **Privat** | Nur berechtigte Projektmitglieder erhalten Zugriff. Geeignet für persönliche Arbeitsstände, vertrauliche Projekte und Nachweise vor einer Freigabe. |
| **Intern** | Authentifizierte Angehörige der GitLab-Instanz können den Inhalt im Rahmen der Instanzregeln einsehen. Geeignet für hochschulinterne Lehre und institutionelle Begutachtung. |
| **Öffentlich** | Der Nachweis kann ohne Anmeldung erreichbar sein. Geeignet für veröffentlichte Arbeiten und Lehrmaterialien, sofern Datenschutz, Urheberrecht und Vertraulichkeit dies zulassen. |
GitLab unterscheidet diese drei Sichtbarkeitsstufen auf Plattformebene. Administratorinnen und Administratoren können die verfügbaren Stufen zusätzlich einschränken. Einzelheiten stehen in der [GitLab-Dokumentation zu Projekt- und Gruppensichtbarkeit](https://docs.gitlab.com/user/public_access/).
Ein privater Commit-Link ist technisch eindeutig, für Außenstehende aber erst nach einer Zugriffsfreigabe lesbar. Für eine öffentlich zugängliche Publikation muss auch der Nachweis für die vorgesehene Leserschaft erreichbar sein. Ein internes Repository setzt eine berechtigte Anmeldung an der Instanz voraus; es ist nicht allgemein öffentlich.
```{warning}
Archivieren Sie keine personenbezogenen, vertraulichen, urheberrechtlich geschützten oder anderweitig sensiblen Inhalte in einem intern oder öffentlich sichtbaren Repository, wenn dafür keine Freigabe vorliegt. Die Sichtbarkeit sollte vor jedem publizierten Nachweis bewusst geprüft werden.
```
## Commit-Link in einer Arbeit angeben
Die konkrete Form richtet sich weiterhin nach dem Zitierstil, dem Fachgebiet sowie den Vorgaben der Lehrveranstaltung, des Prüfungsamts oder des Publikationsorgans. Der Commit-Link kann eine Offenlegung jedoch um einen konkret prüfbaren Interaktionsstand ergänzen.
### Beispiel für eine methodische Offenlegung
> Ein über chatBHT an **deepseek-v4-flash-0731** geleiteter Agent wurde gebeten, die erste binomische Formel zu erklären und ein SVG zu erstellen. Das [freigegebene Gespräch](https://chatbht.com/chat/shared/c457be1a-935d-44b0-86c6-58b83307d4ef/) ist in der App lesbar; Chat, Worktree und Provenienz wurden im [GitLab-Commit ba895503c93ff202a2d6d3c08568452aadec27d0](https://gitlab.chatbht.com/gdyballa/open-weight-models-benchmark/-/commit/ba895503c93ff202a2d6d3c08568452aadec27d0) gesichert. Vor einer Weiterverwendung muss das SVG als mathematische Erklärung geprüft werden.
## Grenzen des Nachweises
Der Commit belegt, welcher Chat- und Arbeitsstand archiviert wurde. Er belegt nicht, dass die darin enthaltenen Aussagen richtig sind. Die Verantwortung für Prüfung, Auswahl, Überarbeitung und wissenschaftliche Einordnung bleibt vollständig beim Menschen.
Insbesondere gilt:
- KI-Ausgaben ersetzen keine wissenschaftlichen Originalquellen.
- Von einem Modell genannte Literatur muss geprüft und unmittelbar zitiert werden.
- Ein Commit dokumentiert einen gesicherten Stand, nicht die Wahrheit der darin enthaltenen Aussagen.
- Hochgeladene Bilder und Dokumente werden im gegenwärtigen Archivformat nicht automatisch als Originaldateien mitgesichert.
- Die Erreichbarkeit eines Links hängt von der Sichtbarkeit und dem Fortbestand des GitLab-Projekts ab.
- Die im Archiv gespeicherte Modellangabe bezeichnet das im Chat hinterlegte Modell; weitergehende technische Angaben hängen von der jeweiligen Installation ab.
- Für Anforderungen der Langzeitarchivierung können ergänzend geschützte Branches, signierte Commits oder ein institutionelles Repositorium erforderlich sein.
## Technischer Hintergrund
Die Ein-Sekunden-Geste wird im Browser ausgewertet. Frühes Loslassen beendet den Timer sofort; auch während des sichtbaren Ring-Rücklaufs wird keine Archivanfrage gesendet. Dezimalanzeige und Fortschrittsring verwenden in der App und in den netzwerkfreien Vorschauen dieselbe Halteinteraktion.
Nach dem Halten prüft der Server das angemeldete Konto, Schreibrechte, Sichtbarkeit sowie Chat und Worktree. Daraus entsteht eine signierte Prüfung, die zehn Minuten gültig ist. Vor dem Commit müssen Inhalt und Ziel weiterhin genau diesem Stand entsprechen; Änderungen erfordern eine neue Prüfung. Für interne und öffentliche Ziele ist zusätzlich die ausdrückliche Freigabe erforderlich.
Markdown-Chat, Arbeitsdateien und `chatBHT-provenance.json` werden gemeinsam in einem GitLab-Commit gespeichert. Ein SHA-256-Inhaltshash kennzeichnet den Stand; ein Archiv-Tag hält die Zuordnung fest. Der angezeigte Link verwendet die vollständige Commit-SHA und zeigt deshalb auch nach Änderungen am Branch auf diese Version. Bereits vorhandene identische Archive werden geprüft und wiederverwendet. Der Repository-Zugriff nutzt die widerrufbare OAuth-Freigabe des Nutzers; die institutionelle Anmeldung stellt davon getrennt die Identität fest.
## Nächster Schritt
Im nächsten Kapitel sehen Sie, wie Sie einen Chat in chatBHT beginnen.
[Weiter: Chat beginnen](start-a-chat.md)
