Beweiskraft des Evidence Package

Ehrliche Einordnung: was ein Evidence Package heute technisch leistet - und was ihm fuer eine gesetzliche Beweisvermutung vor einem deutschen Gericht noch fehlt.

Was heute gilt

• Jede protokollierte Aktion wird als Ereignis in eine fortlaufende Hash-Kette aufgenommen; die nachtraegliche Aenderung eines einzelnen Ereignisses bricht die Kette erkennbar.
• Das fertige Paket wird mit dem privaten ALEX-Signierschluessel (Ed25519) signiert.
• Der oeffentliche Schluessel liegt unter /.well-known/alex-pubkey.json - unabhaengig vom Bundle selbst abrufbar.
• Ein von der Bundle-Erzeugung getrennt gepflegter Pruefcode kann Signatur und Hash-Kette eigenstaendig nachrechnen, ohne ALEX dafuer laufen zu lassen.
• Zeitpunkte werden zusaetzlich ueber einen RFC-3161-Zeitstempeldienst (FreeTSA) bestaetigt.
• Menschliche Freigaben werden als eigenes, referenziertes Ereignis protokolliert. Gibt der Systembetreiber selbst frei, wird zusaetzlich eine von Telegram bestaetigte Kennung referenziert (telegram_callback_query:<id>) - extern nachpruefbar. Gibt ein Pilotkunde ueber seinen eigenen Zugang frei (kein Telegram im Kundenpfad), wird nur ein selbst gewaehlter Anzeigename gebunden an den Besitz des Zugangs-Tokens erfasst (dev_tasks.approved_by) - schwaecher, aber im Bundle als solches erkennbar, nicht verschleiert.
• Der urspruengliche Auftragstext (Ziel, Grenzen, Abnahmekriterien) wird vor der ersten Agent-Aktion eingefroren und gehasht; dieser Hash ist Teil der signierten Nutzlast. Der Klartext-Auftrag wird zusaetzlich mitgeliefert und beim Pruefen exakt gegen diesen Hash nachgerechnet - weicht auch nur ein Byte ab, lehnt die Pruefung das Bundle ab. Eine nachtraegliche Umformulierung des Auftrags ist damit erkennbar, nicht nur behauptet.
• Das Bundle haelt auch fest, was nachweislich nicht geschehen ist (z. B. kein Netzwerkzugriff ausserhalb des Auftrags, keine gelesenen Zugangsdaten) - jeweils mit einem ehrlich ausgewiesenen Haertegrad: aus der Konfiguration abgeleitet, aus echtem Laufzeitverhalten beobachtet, oder unabhaengig bestaetigt. Nur die staerkeren zwei Stufen werden als belastbar gewertet, die schwaechste bleibt rein informativ.
• Widerspricht ein neuer Lauf einer fruehereren, gleichwertig protokollierten Behauptung zum selben Sachverhalt, wird das als eigenes Ereignis festgehalten - keiner der beiden Stände wird automatisch fuer gueltig erklaert oder stillschweigend ueberschrieben, eine Aufloesung erfordert eine ausdrueckliche menschliche Entscheidung.
• Seit dem Receipt-System v1 (16.09.2026) trennt ALEX drei Ebenen sauber: was passiert ist (Execution status), was davon geprueft wurde (Verification status), und die geschaeftliche Richtigkeit der Loesung (Business truth) - Letzteres ist ausdruecklich nicht Gegenstand des Nachweises. Jeder Lauf bekommt zusaetzlich ein Verdict-Objekt (VERIFIED oder PARTIAL) mit bis zu sechs einzeln geprueften Punkten, jeweils in einem von vier Zustaenden (passed/failed/not_run/not_applicable) - eine nicht durchgefuehrte Pruefung wird nie stillschweigend als bestanden gezaehlt.

Rechtlich ist das ein starkes technisches Indiz im Rahmen der freien Beweiswuerdigung (§ 286 ZPO). Ein Gericht kann es beruecksichtigen - es muss es aber nicht als echt anerkennen.

Was heute fehlt

• Keine qualifizierte elektronische Signatur/kein qualifiziertes Siegel nach eIDAS (Art. 3 Nr. 12/27 eIDAS-VO). Die Ed25519-Signatur ist kryptografisch gleichwertig stark, aber keine QES - deshalb greift keine gesetzliche Echtheitsvermutung nach § 371a Abs. 1 S. 2 ZPO.
• Kein qualifizierter elektronischer Zeitstempel eines eIDAS-zugelassenen Vertrauensdiensteanbieters (QTSP). FreeTSA bestaetigt den Zeitpunkt technisch, aber ohne die gesetzliche Vermutung von Zeit und Unversehrtheit aus Art. 41 eIDAS.
• Der Vertrauensanker liegt bei Bewusst.Ki selbst. Es gibt keine von einem unabhaengigen Dritten identitaetsgepruefte Bindung zwischen Signierschluessel und Unternehmen/Person - anders als bei einem QTSP-ausgestellten Zertifikat.
• Keine externe, von ALEX unabhaengige Ereignisquelle. Erzeugung der Arbeit und Erzeugung der Beweisereignisse laufen im selben System.
• Keine zusaetzliche Identitaetspruefung fuer Kundenfreigaben. Ueber den Zugangs-Token hinaus (z. B. per E-Mail-Bestaetigung) wird die Identitaet eines freigebenden Pilotkunden aktuell nicht geprueft.
• Das Verdict-/Checks-Objekt des Receipt-System v1 ist noch nicht durch ein unabhaengiges Drittwerkzeug nachrechenbar. Unabhaengig einsehbar ist der GitHub-Check am Pull Request (bei GitHub gehostet, nicht bei uns) und das zugrundeliegende, signierte Evidence Bundle (pruefbar mit dem bestehenden Pruefcode) - die Projektion auf Policy-Profil und Verdict passiert aktuell nur serverseitig bei ALEX.

Einordnung

Ohne qualifizierte Signatur und qualifizierten Zeitstempel bleibt ein Evidence Package ein starkes technisches Indiz, kein Urkundenersatz mit gesetzlicher Vermutungswirkung. Die Ergaenzung um eIDAS-qualifizierte Vertrauensdienste ist ein moeglicher spaeterer Ausbauschritt und aktuell nicht umgesetzt.

Selbst pruefen

Schritt-fuer-Schritt-Anleitung mit echten Beispielen: nachweis-selbst-pruefen.html.

Der Pruefcode ist unabhaengig von ALEX lauffaehig (Node.js ab Version 20; fuer die ASN.1/CMS-Pruefung ist einmalig npm install noetig):

• verify.js — das Pruefprogramm
• package.json — notwendig, damit Node das Pruefprogramm laden kann
• ANLEITUNG.md — Kurzanleitung
• sample-bundle.json und invalid-tampered-bundle.json — Beispiele zum Ausprobieren

Alle Dateien in denselben Ordner legen, dann: node verify.js dein-beweispaket.json. Die Ausgabe (VERIFIED/FAILED/INCONCLUSIVE) ist unabhaengig von jeder Angabe auf dieser Seite.