WEXP Coverage fragt nach dem Kontrolleur der Prüfspur

Zusammenfassung

Hundert Belege bestehen die Prüfung, während ein Administratorvorgang nie im Buch stand. Mikhail Sergeevs individueller Entwurf WEXP Coverage vom 23. Oktober 2026 fragt, wer diese Lücke kontrollieren konnte. Sein PostgreSQL-Beispiel macht aus dem Buch einen fest umrissenen Prüfgegenstand.
Entscheidend ist, wer die Erfassungsvoraussetzung genehmigt: Wer darf behaupten, dass kein Vorgang am Journal vorbeiging, und auf welcher Grundlage soll der Empfänger des Prüfergebnisses das glauben?

Die Akte ist vollständig. Der Vorgang fehlt.

Nach einer umstrittenen Änderung legt der Dienstleister alle signierten Belege vor. Jede Unterschrift ist echt. Die Frage des Auftraggebers bleibt bestehen: Hatte der Administrator einen Weg, die Änderung ohne Eintrag vorzunehmen? Der Entwurf WEXP Coverage von Mikhail Sergeev zielt auf genau diesen Weg. Die Szene ist ein Gedankenbeispiel, kein Bericht über einen konkreten Angriff. Sie zeigt, warum die Echtheit der vorhandenen Belege eine andere Frage beantwortet als die Vollständigkeit des Journals.

Der Text trägt das Datum 23. Oktober 2026. Im IETF Datatracker steht er als aktiver individueller Internet-Draft ohne RFC-Stream. Er beschreibt einen Vorschlag, keinen verabschiedeten IETF-Standard und keinen dokumentierten Vorfall in einem produktiven System. Gerade deshalb lohnt die nüchterne Prüfung seiner Konstruktion: Sie macht aus einem wohlklingenden Vollständigkeitsversprechen eine Reihe enger, nachprüfbarer Behauptungen.

Die erste Hürde ist die Definition der Grundgesamtheit. A bezeichnet die tatsächlichen Handlungen im vereinbarten Bereich. C enthält alle endgültigen Handlungsbelege, die bis zum Schöpfungsstichtag entstanden sind. R umfasst die Belege, die dem benannten Empfänger bis zu einem Lieferstichtag verfügbar waren. Cv und Rv sind die dem Prüfer gelieferten Ansichten; S ist die als Handlungsnachweis gelieferte Quellenansicht. Eine fehlerfrei kopierte Quelle ist noch lange keine Quelle aller Handlungen.

Der Entwurf unterscheidet außerdem Antrag, Autorisierung, Aufruf, bestätigte Datenbanktransaktion, Belegerstellung und Zustellung. Bei einer bestätigten Transaktion kann die Antwort an den Aufrufer verlorengehen, ohne die Handlung rückgängig zu machen. Ein erneut gesendeter identischer Beleg erzeugt nicht automatisch eine zweite Handlung. Ein erstellter, aber nicht zugestellter Beleg ist ein anderes Problem als eine Handlung ohne Beleg. Die konkrete Anwendung muss festlegen, welches Ereignis sie zählt. Andernfalls gewinnt die bequemste Datenbankspalte.

Zehn benannte Anspruchstypen ersetzen den Gummibegriff „vollständig“. creation-complete verlangt einen endgültigen Beleg für jede tatsächliche Handlung. creation-sound verlangt eine zugehörige Handlung für jeden endgültigen Beleg. creation-exact verlangt eindeutige Zuordnung in beide Richtungen. Eigene Ansprüche behandeln Zustellung, Quellenabdeckung, Übereinstimmung der vorgelegten Ansichten und die Behauptung, es habe überhaupt keine Handlungen gegeben.

Zwei Exporte können Zeile für Zeile übereinstimmen und dennoch denselben blinden Fleck besitzen. Der Entwurf untersagt, eine fehlgeschlagene Abfrage der Quelle als leeres Ergebnis auszugeben. Eine vollständig gelesene, leere Quelle ist etwas anderes als eine nicht verfügbare Quelle. Ein signiertes leeres Array belegt die Integrität dieses Arrays; es bestätigt keinen erfolgreichen Zugriff auf die Wirklichkeit dahinter.

Die Annahme sitzt nicht im Hash

Voraussetzungen können geprüft, ausdrücklich angenommen, unbekannt oder widerlegt sein. Eine angenommene Voraussetzung braucht eine benannte Policy-Autorität, einen Grund und einen Geltungsbereich. „Alles wurde erfasst“ darf nicht als verkleidete Prämisse für „alles wurde erfasst“ dienen. Der Erfassungspfad muss Schreiber, Zustände, Umgehungen, Fehler und die Kontrollen beschreiben, auf die sich die Aussage stützt.

Damit bekommt die Prüftechnik eine Machtfrage. Kann ein privilegierter Administrator die Quelle ändern? Kann ein Beleg außerhalb des Journals ausgegeben werden? Kann ein Restore eine frühere Geschichte wiederherstellen, oder lässt sich bei einer Verzweigung nur ein Zweig vorlegen? Zwei passende Siegel, zwei Firmen oder zwei Schlüssel schließen solche Möglichkeiten für sich genommen nicht aus. Unabhängigkeit entsteht aus tatsächlicher Trennung der Kontrolle, nicht aus der Anzahl der Unterschriften.

Ein konstruiertes Beispiel des Entwurfs ist besonders aufschlussreich. Ein positiver Ableitungsweg stützt sich auf eine genehmigte Erfassungsannahme; ein anderer, verwertbarer Befund zeigt eine ausgelassene Handlung. Beide bleiben im Ergebnis erhalten, der Anspruch wird mit Konflikt als not-established ausgegeben. Die Policy darf nicht angepasst werden, nur um den Gegenbeleg verschwinden zu lassen. Die Genehmigung einer Annahme verleiht kein Recht auf eine bereinigte Beweisakte.

Drei Sperren, ein bewusst kleiner Anspruch

Das Profil pg-ledger/0.2.0 macht Vollständigkeit an einem engen Beispiel prüfbar. Als Handlung gilt ein bestätigtes Anhängen an ein benanntes Handlungsjournal in einem PostgreSQL-18-Batch mit einer Primärinstanz. Ob ein Geldbetrag außerhalb der Datenbank übertragen oder eine externe Aufgabe erledigt wurde, ergibt sich daraus nicht. Für solche Aussagen wäre eine gesondert beschriebene und überprüfte Kopplung nötig.

Jedes Anhängen und jedes Siegel sperrt dieselbe Epochenzeile. Drei bestätigte Barrieren schließen in Reihenfolge die Aufnahme von Handlungen, die Erstellung endgültiger Belege und die Aufnahme beim Empfänger. Die Belegfinalisierung beginnt erst nach dem ersten Abschluss, die externe Ausgabe erst nach dem zweiten. Ein vollständig gelesener Snapshot nach allen drei Abschlüssen liefert Quellen-, Finalisierungs- und Eingangssichten. Sequenznummern und Wanduhren ersetzen keinen Nachweis der Commit-Reihenfolge.

Wiederholte Versuche und widersprechende Varianten bleiben sichtbar; nur authentifizierte, identische Belegvorkommen dürfen nach einer festgelegten Regel als Wiederholungen zusammengefasst werden.

Das ist ein ernsthafter Versuch, „alle“ innerhalb eines begrenzten Betriebsablaufs zu definieren. Er hängt an konkreten Voraussetzungen: korrekter PostgreSQL- und Hostbetrieb, unversehrter Speicher, Rollentrennung, keine Umgehung und keine vorzeitige Ausgabe, vollständig authentifizierter Export sowie stabile Schlüssel und Regeln. Ein Administrator mit umfassenden Rechten, ein Restore, ein Fork oder eine Ausgabe außerhalb des Journals kann diese Basis zerstören. Das Siegel schützt das abgeschlossene Buch, nicht die Hand, die vor dem Binden eine Seite entfernt.

Der Begleitentwurf WEXP Core bewertet inhaltliche Ansprüche über genau bestimmte Ausführungsziele. Coverage behandelt den Bestand. Ein logisches Beispiel des Coverage-Textes lässt 99 gültige Einzelbewertungen neben einer nachgewiesenen Handlung ohne Beleg in einem geschlossenen Bestand von 100 Handlungen stehen. Die 99 Einzelbewertungen bleiben gültig. Die Auslassung erfordert allerdings einen positiven Nachweis, dass die hundertste Handlung dazugehört, und eine hinreichend vollständige negative Belegsuche. Aus der Zahl 99 allein folgt sie nicht. Das Beispiel ist kein gemessener Produktionsfall.