Ein Beleg. Eine klare Beweislage.

Für CDS^™ können vollständige Texte als {"source_texts":{"raw_input":"…","screened_text":"…"}} beigefügt werden. Keine automatische Textänderung. Negative Assurance^™: gespeicherten Export mit run und material als Hauptdatei laden. Alles bleibt lokal.

Verglichen werden ausdrücklich eingegebene Felder. Ohne Zielhandlung gibt es keine Bestätigung, dass der Beleg zu Ihrem Vorgang passt.

Für kanonische P-256-Proofs: keys-Liste mit issuer, public_key_hex (SPKI) und optional key_id/status. Für portable signed_payload-Signaturen: öffentlicher JWK/JWKS oder keys-Liste mit issuer und jwk. Herkunft selbst bestätigen. Kein HMAC-Geheimnis und keinen privaten Schlüssel eingeben.

Die Referenzzeit wird im Bericht ausgewiesen. Sie ist keine unabhängige Zeitbestätigung. Ein historischer Prüfzeitpunkt bestätigt keinen aktuellen Zustand.

Kanonische portable P-256-Proofs: signierte Feldmenge neu hashen, Signatur prüfen, Aussteller gegen bereitgestelltes Material abgleichen, Gültigkeitsfenster und erwartete Handlung vergleichen. Portable signed_payload-Blöcke: Signatur über den exakten Text prüfen; äußere Felder bleiben unbestätigt.

Ältere Hybrid-Belege: Ed25519 und Verknüpfung der Signaturwerte prüfen. ML-DSA und vollständige Inhaltskanonisierung sind hier noch offen. HMAC: keine öffentliche Authentizitätsprüfung. Core^™ CIPP: erkannte Altprofil-Hüllprüfsumme untersuchen, aber weder vollständige verschachtelte Inhaltsbindung noch Core-Signatur oder Assurance bestätigen. Keine TEE- oder Enclave-Attestierungsprüfung.

Kein Live-Widerruf, keine Ausführungsfreigabe, keine unabhängige Feststellung der tatsächlichen Wirkung, keine Rechtsberatung. Ein report_digest schützt nicht gegen eine vollständige Neuberechnung durch Dritte und ist keine Signatur des Prüfberichts.

Core-Testmodus-Belege und GG0-CDS-Belege: bekannte Prüfsummen nachrechnen. Übereinstimmende Prüfsummen bestätigen die rechnerische Konsistenz, keine öffentlich bestätigte Herkunft. Vollständige Quelltexte werden durch Auszüge nicht ersetzt. Bei diesen Prüfbelegen ist Ausführung nicht Gegenstand.

Zusätzliche Konsistenzprüfungen: bekannte Versionen, Pflichtreferenzen, Schlüsselstatus und Schlüsselzeitfenster, gültige Kalenderdaten und gebundene Ausführungszeiten. CDS^™: Befund-, Abdeckungs- und Segmentierungszähler sowie beigefügte Volltexte. Negative Assurance^™: Blatt-Hashes, Ereignis- und Klassen-Roots, Snapshot- und Profilbindung, Nachbarpfade, Gegenereignisse und deklarierte Abdeckung. CertifiedReceipt- und TZero-Exporte: Verknüpfung des gelieferten Kettensegments. Fehlende ursprüngliche Erfassung oder öffentliche Signaturen werden dadurch nicht ersetzt.

Die Prüfung läuft isoliert mit einer Abbruchgrenze von 15 Sekunden. Abbruch und technische Fehler ergeben keine Bestätigung. Ein vollständiger JSON-Bericht enthält alle Einzelprüfungen; wiederholte gleichartige Prüfpunkte werden zur Übersicht gruppiert.