RecordWebProof of Concept · Archivische Perspektive
1 / 11

RecordWeb · Eine Geschichte für Archive

Wenn eine Anwendung endet.

Wie RecordWeb Records und ihren Zusammenhang über Systemwechsel hinweg begleitet.

Nicht erst retten, wenn das System verschwindet.
Den Übergang von Anfang an begleiten.

Szene 1 · Solange die Anwendung lebt

Ein finalisierter Record ist bereit.

Frau Roth und ihr Team haben ihre Arbeit abgeschlossen. Der MiniChat ist finalisiert. Der Record bleibt unverändert in einer RWP-konformen Anwendung.

Finalisierung ist nicht der Beginn eines Wartens auf die spätere Aussonderung. Der Record ist jetzt bereits eindeutig, vollständig referenzierbar und bereit für seinen weiteren Lebensweg - und das bereits in einem archivtauglichen Format.
MC

MiniChatRWP-konforme Anwendung

MiniChat zu Fragestunde-Case
finalized · Version 1
✓ Über den Namespace-Endpoint auflösbar

Szene 2 · Der Record bleibt erreichbar

Der Namespace zeigt, wo der Record aufgelöst wird.

did:rwp:s73f42a3:records:787475d4-5572-44a2-a62e-b4aaf7d590e3
✓ Record erfolgreich aufgelöst

MiniChat zu Fragestunde-Case

Status: finalized
Aktuelle Version: sha256:…

recordEndpoint → Anwendung stellt den Record bereit

Die DID ist der dauerhafte Bezugspunkt. Der Namespace verweist auf einen Resolver, und der RecordEndpoint liefert den Record aus der zuständigen Anwendung.

Das Archiv muss nicht zuerst ein eigenes, nachträglich rekonstruiertes Abbild herstellen, damit der Record grundsätzlich erreichbar und verständlich ist.

Szene 3 · Die reale Gefahr

Und wenn die Anwendung verschwindet?

https://minichat.example.gov/api/records/787475d4-…
404Record not foundDie Anwendung wurde abgelöst. Der alte Endpoint ist nicht mehr verfügbar.

Wenn Anwendungen enden, genügt es nicht, nur Dateien zu retten. Ohne vorbereiteten Übergang drohen verlorene Auflösung, unklare Herkunft, fehlende Beziehungen und aufwendige Rekonstruktion.

Szene 4 · Der Gamechanger

Der Record wird nicht erst nach zehn Jahren vorbereitet.

1

Mit der Finalisierung ist der Record bereit.

Er erhält seinen stabilen Bezugspunkt, seine finale Fassung und seinen nachvollziehbaren Kontext. Eine spätere Überführung muss ihn nicht erst aus verstreuten Daten, Dateien und Metadaten zusammensuchen.

ArbeitChat, Daten, Entwürfe, Abstimmung
FinalisierungRecord ist archivtauglch und auflösbar
EoL bei BedarfKontrollierte Überführung statt nachträglicher Rettungsaktion
Nicht zuerst zehn Jahre sammeln und dann aufräumen, konvertieren und vorbereiten. Der relevante Aufwand wird an den richtigen Zeitpunkt verlagert: an die Entstehung und Finalisierung des Records.

Szene 5 · End of Life ist der Auslöser

Erst wenn die Anwendung endet, braucht es eine Überführung.

Nicht die Finalisierung der Antwort löst eine Archivierung aus. Der Anlass ist das End of Life der Anwendung, die den Record bisher bereitgestellt hat.

RWP-konforme AnwendungDer Record bleibt unverändert und über den Namespace auflösbar.
End of LifeDie Anwendung wird abgelöst oder ausser Betrieb genommen.
custodyTransferDer Record wechselt kontrolliert in einen neuen Aufbewahrungskontext.

Szene 6 · Zwei kontrollierte Wege

Wohin geht ein Record, wenn seine Anwendung endet?

Weg 1

Nachfolge-Fachanwendung

Die neue Anwendung übernimmt die Verantwortung für den Record und stellt ihn über einen neuen, zuständigen Endpoint weiter bereit.

Weg 2

AIS

Der Record wird in das Archivinformationssystem überführt und dort im archivischen Kontext weiter bereitgestellt.

In beiden Fällen bleibt der Record der Record. Was sich verändert, ist sein Aufbewahrungs- und Bereitstellungskontext.

Szene 7 · Der PoC-Fall MiniChat → AIS

Das SIP ist ein Rahmen um den unveränderten Record.

Unveränderter MiniChat-Record

DID, finale Fassung, Metadaten, Beziehungen und Integritätsbezug bleiben Bestandteil desselben Records.

MiniChat zu Fragestunde-Case
finalized · Version 1

Wichtig: Das SIP erzeugt keinen Ersatzrecord. Es stellt einen Übergaberahmen bereit, damit das AIS den bestehenden Record kontrolliert übernehmen kann.

Im PoC-Fragestunde wird MiniChat als End-of-Life-Anwendung angenommen. Deshalb wird der Record für die Übergabe an AIS in einen SIP-Rahmen eingebettet.

Szene 8 · Sichtbarer Nachweis im PoC

Der Endpoint zeigt den neuen Bereitstellungskontext.

Nach der Überführung enthält das DID-Dokument denselben Record-Bezug. Im recordEndpoint wird sichtbar, dass der Record nun durch AIS bereitgestellt wird.

DID-Dokument · AuszugMiniChat-Record
{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:rwp:s73f42a3:records:787475d4-5572-44a2-a62e-b4aaf7d590e3",
  "recordEndpoint": "https://vps.recordweb.dev/ais/api/records/787475d4-5572-44a2-a62e-b4aaf7d590e3",
  "created": "2026-08-25T14:12:02.574Z",
  "updated": "2026-08-25T14:31:10.420Z",
  "currentVersion": "sha256:8a68bf1e26aa786b6a1f64edc027b02987ca9cadc5835c81c502f333dbd90d8a",
  "controller": "did:rwp:s73f42a3",
  "record": {
    "recordType": "MiniChat",
    "status": "finalized",
    "version": 1,
    "title": "MiniChat zu Fragestunde-Case zu Frage did:rwp:a3f9e21c:records:afe21014-94e2-4a4a-b87b-9b680b4676e3"
  }
}
Lesart: Vor der Überführung verwies der Endpoint auf MiniChat. Im demonstrierten EoL-Fall verweist er auf ais. Die DID bleibt der stabile Bezugspunkt; der auflösende Kontext wechselt.

Szene 9 · Vertrauen entsteht durch Prüfung

Eine Überführung muss nicht nur behauptet, sondern prüfbar sein.

Unabhängig finden

Ein RecordFinder kann den Record unabhängig von seiner ursprünglichen Anwendung suchen und abrufen.

Über Resolver prüfen

Die Auflösung der DID zeigt, welcher Endpoint den Record aktuell bereitstellt.

Fassung erkennen

Der aktuelle Versionsbezug erlaubt, die bereitgestellte Fassung eindeutig zu prüfen.

Im PoC-Fragestunde kann die Übernahme nach AIS mit einem unabhängigen RecordFinder und über die Resolver-Auflösung überprüft werden.

Szene 10 · Früher steuern statt später retten

Archive können Anforderungen an die Erzeugungsumgebung prüfbar machen.

Nicht jede einzelne Information muss nach Jahren manuell rekonstruiert werden. Ebenso entscheidend ist, ob nachvollziehbar ist, wie und womit sie erzeugt wurde.

SchemaRecord

Beschreibt die Struktur und Regeln eines Record-Typs. Er ist selbst ein versionierter, revisionsfähiger Record.

Konformität
prüfbar
ConformanceRecord

Hält fest, was gegen welche Vorgaben geprüft wurde. Etwa Anwendung, Produktversion und durchgeführte Kontrollen.

Steuerungsinstrument: Das Archiv kann Anforderungen und Prüfungen früher ansetzen (bei Anwendungen und ihren Erzeugungsregeln) und nicht erst im Ablieferungsprojekt.

RecordWeb · Archivische Perspektive

Ein Record muss nicht gerettet werden,
wenn sein Übergang begleitet wird.

Finalisierung macht ihn bereit. Solange die Anwendung läuft, bleibt er auflösbar. Beim End of Life wird er kontrolliert in eine Nachfolgeanwendung oder ins AIS überführt.

Nicht erst retten, wenn das System verschwindet.
Den Übergang von Anfang an begleiten.
Tastatur: ← → · Pos1/Ende · N: Sprechertext