KI-Provenienz im GitLab-Archiv#
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.
- 01 Nutzende Idee formulieren, Prompt senden und Antwort fachlich prüfen
- 02 LLM-Provider Prompt verarbeiten und KI-Ausgabe an chatBHT zurückgeben
- 03 GitLab-Instanz Ausgewählten Chat und Worktree gemeinsam in einem Commit versionieren
- 04 Wissenschaftliche Arbeit Versionsgebundenen Link offenlegen und als KI-Nutzungsnachweis referenzieren
Nachweis und Quelle unterscheiden
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.
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.
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.
Vorhandenes Repository auswählen#
Wählen Sie Vorhandenes Repository.
Wählen Sie ein beschreibbares GitLab-Projekt aus.
Geben Sie bei Bedarf einen bestimmten Branch an. Ohne Angabe wird der Standard-Branch verwendet.
Legen Sie den Zielordner fest. Der voreingestellte Ordner lautet
chatbht.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.
Neues Repository erstellen#
Wählen Sie Repository neu anlegen.
Vergeben Sie einen eindeutigen Repository-Namen, zum Beispiel
ki-nutzungsnachweise.Wählen Sie die Sichtbarkeit. Privat (empfohlen) ist voreingestellt.
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.
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.
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.
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?.
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.
Prüfen Sie auch mitgespeicherten persönlichen Kontext. Setzen Sie erst dann das Bestätigungshäkchen. Dadurch wird Freigeben und archivieren aktiv:
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.
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. |
Einen freigegebenen Chat-Link 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. |
|
Beziehungen zwischen erfasster Person, Chatprozess, Modellroute, Nachrichten und Dateien sowie Archivziel und ausdrücklich benannten Nachweisgrenzen. |
Die Standardstruktur lautet:
chatbht/chats/<chat-id>/<titel>-<inhaltshash>.md
chatbht/chats/<chat-id>/<titel>-<inhaltshash>/chatBHT-provenance.json
chatbht/chats/<chat-id>/<titel>-<inhaltshash>/worktree/<dateipfad>
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, 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 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 |
||
Provenienzdatei |
||
Erklärung des Agenten |
||
Grafischer Beweis |
Im Worktree-Verzeichnis dieses Commits 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.
Abb. 1 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.
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 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. Sie verlangt genau |
Process (Ablauf) |
Folgen Sie der erfassten Assistant-Erzeugung nach diesem Prompt: Nachricht |
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:
{
"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:
{
"@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 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.
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.
Warnung
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 ist in der App lesbar; Chat, Worktree und Provenienz wurden im GitLab-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.
Nächster Schritt#
Im nächsten Kapitel sehen Sie, wie Sie einen Chat in chatBHT beginnen.