RecordWeb · Vertrauensperspektive

Vertrauen ist prüfbar.

Wie Records über Organisations- und Systemgrenzen hinweg verlinkt werden können, ohne blindes Vertrauen zu verlangen.

Nicht: „Vertrau uns.“
Sondern: „Prüfe, unter welchen Regeln dieser Record entstanden ist.“

Szene 1 · Verlinken statt replizieren

Ein Netz aus Records verlangt Vertrauen zwischen Organisationen.

Parlament

Führt das Geschäft zur parlamentarischen Frage.

Frage
eigener Record, eigener Kontext

Vertraut darauf, dass die Regierung ihre Antwort nicht mehr verändert.

↔

Regierung

Führt das Geschäft zur Beantwortung.

Antwort
eigener Record, eigener Kontext

Vertraut darauf, dass das Parlament seine Frage nicht mehr verändert.

Die Alternative wäre Replikation: Jede Seite kopiert die Records der anderen. RecordWeb setzt stattdessen auf eigenständige Records und explizite Beziehungen.

Szene 2 · Vertrauen darf nicht blind sein

Eine Zusicherung allein ist kein Nachweis.

?

Parlament an Regierung

Warum soll die Antwort nach der Finalisierung nicht verändert werden?

?

Regierung an Parlament

Warum soll die Frage dauerhaft auflösbar bleiben, wenn wir nur darauf verlinken?

?

Archiv an Anwendung

Warum soll die Anwendung Records über Jahre zuverlässig führen und sie erst beim EoL übergeben?

Self-Custody bedeutet nicht: „Die Anwendung kann tun, was sie will.“
Es bedeutet: Verantwortung wird einer Anwendung nur in einem klaren, überprüfbaren Rahmen übertragen.

Szene 3 · Was prüfbar sein muss

Verantwortung für Records lässt sich in konkrete Prüfbereiche übersetzen.

1Identität

Erhält jeder Record einen stabilen, auflösbaren Bezugspunkt?

2Integrität

Ist die Fassung eindeutig erkennbar und nach der Finalisierung geschützt?

3Beziehungen

Bleiben Beziehungen zu Case und weiteren Records nachvollziehbar?

4Verfügbarkeit

Ist klar, wer den Record bereitstellt und wo er aktuell aufgelöst wird?

5Übergang

Ist für ein End of Life ein kontrollierter custodyTransfer vorgesehen?

Szene 4 · Vom Regelwerk zum Nachweis

Regeln werden beschrieben. Anwendungen werden geprüft. Das Ergebnis bleibt nachvollziehbar.

SchemaRecord

Definiert die Regeln für einen RecordType: Struktur, Pflichtfelder, zulässige Zustände und Übergänge.

→

Konformitätsprüfung

Eine zuständige oder unabhängige Prüfstelle beurteilt eine konkrete Anwendung und Produktversion.

→

ConformanceRecord

Hält Anspruch, Gegenstand, Evidenz, Methode, Ergebnisse und Gültigkeitsdauer als eigenen Record fest.

Nicht ein PDF-Zertifikat neben dem System, sondern ein selbst identifizierbarer, versionierbarer und prüfbarer Konformitätsnachweis.

Szene 5 · Der SchemaRecord im PoC

Das Schema beschreibt, wie eine parlamentarische Antwort erzeugt und finalisiert wird.

Im PoC-Fragestunde ist der SchemaRecord für den RecordType Fragestunde - Antwort ebenfalls finalisiert und versioniert. Er legt unter anderem Pflichtfelder sowie den Übergang von draft zu finalized fest.

SchemaRecord · gekürzter AuszugAntwortmanagement

{
  "did": "did:rwp:b7d4c810:schema:fragestunde-antwort",
  "type": "SchemaRecord",
  "payload": {
    "displayName": "Fragestunde - Antwort",
    "allowedStates": ["draft", "finalized"],
    "stateTransitions": [{
      "from": "draft",
      "to": "finalized",
      "requiresOwnerSignature": true
    }],
    "required": ["antworttext", "bundesrat_did", "beantwortet_am"],
    "conformanceRecords": [ … ]
  },
  "metadata": {
    "state": "finalized",
    "schemaVersion": "sha256:b03e4ff…"
  }
}

Szene 6 · Der Conformance Record im PoC

Die Konformität bezieht sich auf eine konkrete Anwendung und Produktversion.

Im PoC-Nachweis attestiert das Archiv (mit dem Tool BAR Conformance Authority) die Anwendung Antwortmanagement in der Version 0.1.0 für die Rollen producer und custodian.

Conformance Record · gekürzter AuszugBAR Conformance Authority

{
  "did": "did:rwp:ba31d45f:records:986c4769-0713-4cb6-8292-e7412df3ebd5",
  "type": "ConformanceRecord",
  "payload": {
    "claims": [{
      "roles": ["producer", "custodian"],
      "profiles": ["RWP Information Record Conformant"]
    }],
    "subject": {
      "productName": "Antwortmanagement",
      "productVersion": "0.1.0",
      "implementationDid": "did:rwp:b7d4c810:antwortmanagement"
    },
    "attester": "did:rwp:ba31d45f:agents:bar-user:nik:…",
    "issuedAt": "2026-08-24T17:04:50.544Z",
    "expiresAt": "2026-11-01T17:04:00.000Z",
    "assessment": {
      "tool": "BAR Conformance Authority",
      "method": "independently-assessed"
    },
    "assessmentResults": [
      "did-resolution: passed",
      "schema-binding: passed",
      "payload-validation: passed",
      "snapshot-integrity: passed",
      "immutable-finalisation: passed"
    ]
  },
  "metadata": { "state": "finalized", "snapshotHash": "sha256:aad9654…" }
}

Szene 7 · Die Vertrauenskette

Der Antwort-Record verweist auf sein Schema. Das Schema bindet den Konformitätsnachweis ein.

AntwortRecord

Fragestunde-Antwort
state: finalized
record_type: fragestunde-antwort
schema_version: sha256:b03e4ff…

konform erzeugt?

→

SchemaRecord

Beschreibt RecordType und Finalisierungsregeln.

Bindet den Conformance Record per DID und snapshotHash ein.

Regeln

→

Conformance Record

Attestiert Antwortmanagement 0.1.0 als producer und custodian nach unabhängiger Prüfung.

Nachweis

Technische Präzisierung: Der AntwortRecord verwendet die schema_version sha256:b03e4ff…. Diese entspricht dem schemaHash einer bestimmten Version des SchemaRecords. Der ConformanceRecord ist im SchemaRecord dieser Version per DID und seinem snapshotHash ebenfalls gebunden.

Szene 8 · Gegenseitige Prüfbarkeit

Konformität schafft keinen Vertrauensvorschuss. Sie ermöglicht Kontrolle in beide Richtungen.

✓

Verantwortliche der Anwendung

Kann prüfen, ob die im verwendeten Schema eingebundene Konformitätsreferenz gültig und passend ist.

Stimmt die ConformanceRecord-DID?
Stimmt der gebundene Snapshot?
Gilt der Nachweis noch?
Bezieht er sich auf die laufende Produktversion?

✓

Attestierende Stelle, zB ein Archiv

Kann prüfen, ob ihr Konformitätsnachweis im SchemaRecord korrekt referenziert und unverändert gebunden wurde.

Wird der eigene ConformanceRecord verwendet?
Stimmt dessen SnapshotHash?
Welche Anwendung und Version waren Gegenstand?
Welche Tests und Evidenzen liegen vor?

Vertrauen wird nicht einmal ausgestellt und dann vergessen. Es bleibt als Beziehung zwischen Regeln, Prüfung und Anwendung überprüfbar.

Szene 9 · Vertrauen bis zum Übergang

Wenn keine Nachfolge-Fachanwendung übernimmt, kommt AIS zum Zug.

Der Konformitätsrahmen stärkt Vertrauen in die zuständige Anwendung, solange sie betrieben wird. Beim End of Life ist ein kontrollierter custodyTransfer erforderlich.

RWP-konforme Anwendung

Führt und stellt den finalisierten Record bereit, unter definierten und prüfbaren Regeln.

→

End of Life

Keine Nachfolge-Fachanwendung übernimmt den Record und seine Bereitstellung.

→

AIS

Übernimmt den bestehenden Record in einem kontrollierten Übergaberahmen.

Die Konformität ersetzt den Übergang nicht. Sie macht glaubwürdiger, dass die Anwendung den Record bis zu diesem Übergang verlässlich führen kann.

Szene 10 · Steuerung durch prüfbare Anforderungen

Konformität wird zum Instrument für Governance und Architektur.

Für Archive

Anforderungen an die Führung und spätere Überführbarkeit von Records können früher ansetzen, bei Regeln und Erzeugungsumgebung.

Für Organisationen

Sie können Records verlinken statt replizieren, wenn Verantwortlichkeit und Konformität nachvollziehbar sind.

Für Beschaffung und Architektur

Konformitätsprofile können schrittweise zu überprüfbaren Anforderungen bei neuen oder erneuerten Anwendungen werden.

Perspektive: Aus einer abstrakten Pflicht zur ordentlichen Informationsverwaltung wird eine konkrete, testbare und dokumentierte Eigenschaft von Anwendungen.

Die Diskussion um Self-Custodian kann daran anschliessen. RecordWeb nimmt sie nicht vorweg, bietet jedoch eine Grundlage, Verantwortung nicht blind, sondern anhand überprüfbarer Konformität zu delegieren.