Ein System kann die richtigen Bedingungen durchsetzen und trotzdem bei der Verantwortlichkeit scheitern, wenn es später nicht nachweisen kann, dass diese Bedingungen tatsächlich erfüllt waren. Deshalb darf Provenance nicht von einer nachträglichen Rekonstruktion abhängen. Eine generierte Erklärung reicht nicht aus. Eine nachträgliche Zusammenfassung reicht nicht aus. Und auch ein allgemeines Aktivitätsprotokoll reicht nicht aus, wenn daraus nicht hervorgeht, welche Governance-Bedingungen galten, als das System weiterlief. Die relevanten Nachweise müssen als Teil des regulierten Pfads selbst entstehen. Welcher institutionelle Zustand war verbindlich? Auf welche Evidenz wurde zurückgegriffen? Welche Autorität war gültig? Welche Prüfungen wurden bestanden? Welcher Zustand galt bei Freigabe oder Commit? Wichtig ist dabei die Unterscheidung zwischen dem Erzeugen von Governance-Nachweisen und ihrer dauerhaften Speicherung. Die erforderliche Provenance muss während des regulierten Ausführungspfads entstehen. Ihre dauerhafte Speicherung kann auch asynchron erfolgen. Aber wenn diese Nachweise verloren gehen oder nicht dauerhaft gespeichert werden können, darf das nicht stillschweigend verschwinden. Es muss als erkannter Governance-Fehler bestehen bleiben. Damit ist Provenance mehr als Logging. Sie wird Teil der Architektur der Verantwortlichkeit. Die architektonische Unterscheidung lautet: Freigabe oder Ausführung erzeugt ein reguliertes Ergebnis. Provenance erzeugt den Nachweis über die Bedingungen, unter denen dieses Ergebnis zulässig war. Die eigentliche Frage lautet deshalb nicht: Kann das System später rekonstruieren, was passiert ist? Sondern: Kann ein folgenreicher Zustandsübergang abgeschlossen werden, ohne die Provenance zu erzeugen, die notwendig ist, um dafür Rechenschaft abzulegen? Wenn ja, ist Verantwortlichkeit optional.