Der Nachweis, der sich selbst beschreibt

Ein Importfehler ist behoben, der neue Nettobeitrag stimmt. Offen bleibt, warum die vorige Rechnung einen anderen Betrag ausgewiesen hat. Ein Trace – das Ausführungsprotokoll der Rechnung – verbindet die damals verwendeten Eingaben mit den ausgeführten Modulen und dem Ergebnis. Damit lässt sich der alte Betrag prüfen, auch nachdem der Import korrigiert wurde. Zusammen mit dem zugeordneten Archiv bildet der Trace den Rechen-Nachweis: das Protokoll des konkreten Laufs und die Unterlagen, auf die es verweist.

In Den Rechenkern komponiert man endet die Prüfung bei den tatsächlich ausgeführten Modulen, Parametern und Referenzdaten. Ihre dauerhafte Aufbewahrung bleibt dort als weitere Aufgabe offen. Hier beginnt sie: Was muss vom konkreten Lauf erhalten bleiben, damit ein Dritter seine Grundlage später noch beurteilen kann?

Die DAV-Richtlinie zu den allgemeinen Grundsätzen aktuarieller Tätigkeiten behandelt Reproduzierbarkeit, Änderungskontrollen und den Vergleich von Modellergebnissen ausdrücklich [1]. Sie schreibt dafür kein Dateiformat vor. Der folgende Vorschlag übersetzt diese Prüfaufgaben in eine Architektur für deterministische Referenzrechner.

1 · Eine Datenkorrektur braucht eine neue Kennung

Im Beispiel ändert sich keine tarifliche Rechnungsgrundlage, sondern ihre Übernahme in den Rechner. T-17 bezeichnet den fehlerhaften Import, T-18 den korrigierten. Es gilt dieselbe Regel wie für Quellen in Ein Beleg ohne Stichtag ist kein Nachweis: Unter einer vergebenen Kennung darf kein anderer Inhalt erscheinen. Das W3C trennt bei veröffentlichten Daten entsprechend zwischen einer Kennung für die einzelne Fassung und einer Kennung für die Serie, die auf die jeweils neueste Fassung zeigen darf [2]. Auf einen Referenzrechner übertragen: „aktueller Import“ kann eine Auswahlhilfe sein, aber keine dauerhafte Grundlage eines Rechennachweises.

Die Datenhaltung muss das Überschreiben verhindern und alte Fassungen für die vorgesehene Aufbewahrungsdauer erhalten. Vor einer Rechnung werden alle Datenverweise auf konkrete Fassungen festgelegt; sie gelten für jeden folgenden Rechenschritt. Sonst könnte eine laufende Rechnung bei einer zwischenzeitlichen Korrektur beide Importe vermischen.

2 · Der Trace verbindet Eingaben, Modulaufrufe und Ergebnis

Der Einwand liegt nahe: Wenn T-17 unveränderlich archiviert ist und L-41 darauf verweist, wozu den Wert noch einmal speichern? Für die Nachrechnung des Beispiels reicht die Fassung zusammen mit Altersauswahl und Rechenvorschrift. Die Kennung allein belegt aber nicht, was das Rechenmodul tatsächlich erhielt. Dazwischen liegt die Auflösung: Altersbestimmung, Auswahl der Spalte und Zugriff auf die konkrete Datei. Bei einem fehlenden exakten Treffer kann eine Suchregel auf eine Dateifassung mit passendem Namenspräfix ausweichen; ein späteres Modul kann die Tafel erneut laden. Eine im Lauf benannte Fassung beweist noch nicht, dass jeder Zugriff dieselben Daten geliefert hat.

Die Auflösung muss deshalb Fassung, Auswahlmerkmale und Wert gemeinsam liefern. Dieses Objekt geht unverändert an Rechenmodul und Trace. Das Rechenmodul bezieht seine Referenzdaten ausschließlich aus diesem Objekt; weitere benötigte Werte werden vor dem Aufruf aufgelöst. Damit steht im Nachweis, ob die Rechnung den Wert für Alter 42 oder 43 erhielt. Die archivierte Datei beantwortet, was dort stand; die protokollierte Übergabe beantwortet, was davon verwendet wurde. Selbstbeschreibend heißt hier: Wert, Bedeutung, Auswahl und Verwendung bleiben zusammen lesbar. Auch ohne lauffähige alte Umgebung kann ein Prüfer diese Auswahl gegen die Unterlagen halten. Das ersetzt keinen Wiederholungslauf.

Das Provenienzmodell PROV-DM des W3C unterscheidet Datenobjekte, Verarbeitung und Verwendung [3]. Darauf baut der folgende Vorschlag mit vier Abschnitten auf:

Der Trace entsteht am tatsächlichen Modulaufruf. Die Protokollierung erfasst, welches Modul aufgerufen wird, welche Eingaben es erhält und was es zurückgibt. Die Rechenlogik steht einmal im ausgeführten Code. Eine zusätzlich gepflegte Formelbeschreibung könnte davon abweichen.

Die Protokolltiefe folgt dem Modulschnitt. Die benannten Zwischenergebnisse erscheinen als Ausgabe eines Moduls und Eingabe des nächsten im Trace. Die vom deterministischen Kern verlangte Protokollierbarkeit setzt voraus, dass fachlich benötigte Zwischenwerte an solchen Grenzen zugänglich sind. Im kleinen Beispiel genügt ein Modul für den Nettobeitrag; seine internen Hilfsgrößen werden nicht zusätzlich aufgezeichnet.

Konventionen werden vor der Ausführung zu Eingaben aufgelöst. So wird die in Mehr Korrektheit ist ein Anti-Feature geforderte Sichtbarkeit konkret: Das Modul erhält die anzuwendende Rundung und verwendet genau diese. Im folgenden Ausschnitt sind Präzision, Rundungsmodus und Stellenzahl Eingaben; gerundet wird der Endbetrag. Die Daten- und Konventionsauflösung ist hier bereits abgeschlossen.

from dataclasses import dataclass
from decimal import Decimal, ROUND_HALF_UP, localcontext
from uuid import uuid4

@dataclass(frozen=True)
class Eingabe:
    datenfassung: str
    alter: int
    qx: Decimal
    versicherungssumme: Decimal
    rechnungszins: Decimal
    praezision: int
    rundungsmodus: str
    endstellen: int

eingabe = Eingabe(
    "T-17", 42, Decimal("0.00152000"),
    Decimal("100000"), Decimal("0.02"),
    28, ROUND_HALF_UP, 2
)

def nettobeitrag(e):
    with localcontext() as kontext:
        kontext.prec = e.praezision
        kontext.rounding = e.rundungsmodus
        barwert = (e.versicherungssumme * e.qx
                   / (1 + e.rechnungszins))
        endstelle = Decimal(1).scaleb(-e.endstellen)
        return barwert.quantize(endstelle)

def mit_trace(modul, eingabe):
    ausgabe = modul(eingabe)
    return ausgabe, {
        "modul": modul.__qualname__,
        "eingabe": eingabe, "ausgabe": ausgabe,
    }

lauf_id = str(uuid4())
beitrag, aufruf = mit_trace(nettobeitrag, eingabe)

trace = {
    "lauf": lauf_id, "eingaben": eingabe,
    "aufrufe": (aufruf,), "ergebnis": beitrag,
}

Diese Tiefe kostet Speicher und Laufzeit. Für Einzelvertragsprüfungen und Testbestände sieht der Vorschlag eine vollständige Erfassung an den fachlich benannten Modulgrenzen vor. Im Bestandslauf ist der Umfang eine begründete Entscheidung nach Prüfzweck und Risiko; die DAV-Richtlinie setzt den Umfang der Modell-Governance entsprechend zum Modellrisiko ins Verhältnis [1]. Was nicht erfasst wurde, lässt sich später auch nicht als damalige Zwischenrechnung ausweisen. Die gewählte Tiefe gehört deshalb in den Laufkopf.

3 · Zum Trace gehört ein verlässlich aufbewahrtes Archiv

Der Trace zeigt, was verwendet wurde; das Archiv stellt die Grundlagen für die Wiederholung bereit; die Wiederholung prüft, ob sich damit die protokollierten Ergebnisse erneut erzeugen lassen. Das konkretisiert die Arbeitsteilung zwischen Nachweis und Wiederholung für den Rechenkern.

Der Trace enthält Werte und Verweise. Die referenzierten Dateien müssen zusätzlich erhalten bleiben: Datenfassungen, Rechenvorschriften, Feldbeschreibungen sowie für eine maschinelle Wiederholung die ausgeführten Programme, Bibliotheken und die relevante Laufzeitumgebung. Eine Versionsbezeichnung im Trace ersetzt diese Dateien nicht.

Ein Manifest – das Dateiverzeichnis des Archivpakets – verbindet Trace und Dateien über ihre Kennungen und Prüfsummen. Beim Lesen werden die Prüfsummen erneut berechnet und verglichen. Das Archivformat BagIt trennt entsprechend zwischen Vollständigkeit und geprüfter Inhaltsintegrität [4]. Einzubeziehen sind auch die Feldbeschreibungen: Eine nachträglich geänderte Einheit würde die Bedeutung eines unveränderten Zahlenwerts verändern.

Eine passende Prüfsumme garantiert keine vertrauenswürdige Herkunft. Wer Datei und Prüfsumme gemeinsam austauschen kann, kann die Prüfung unterlaufen. Auch RFC 8493 nennt diese Grenze [4]. Dafür braucht es geschützte Aufbewahrung und, je nach Anforderung, eine überprüfbare Signatur. Ob die archivierte Umgebung einen maschinellen Wiederholungslauf ermöglicht, muss wiederum durch einen solchen Lauf geprüft werden.

Der Rechen-Nachweis ersetzt schließlich keine fachliche Prüfung. Auch eine falsch ausgewählte Sterbewahrscheinlichkeit kann lückenlos dokumentiert sein; ihre Zulässigkeit entscheidet die Tarifvorschrift.

4 · Die Korrektur ergänzt die Geschichte

Zum korrigierten Import gehören Anlass, Vorgängerfassung und fachliche Freigabe. Wird eine Neuberechnung freigegeben, entsteht L-42 mit T-18, verbunden mit dem früheren Lauf L-41. Dessen Trace bleibt erhalten. Auch eine Wiederholung mit gleichen Eingaben erhält eine eigene Laufkennung. Die Ergebnisdifferenz im Beispiel lässt sich der Importkorrektur zuordnen, weil die übrigen Eingaben und Programme gleich bleiben.

War der alte Nettobeitrag ein Sollwert im Abgleich, betrifft die Korrektur auch die damit beurteilten Ergebnisse. Abweichungen, die mit L-41 erklärt oder akzeptiert wurden, müssen auf ihrer korrigierten Grundlage erneut geprüft werden. Der alte Befund bleibt dokumentiert; er wird durch eine neue Bewertung ergänzt.

Für die Auswirkungsanalyse lassen sich zunächst alle Läufe suchen, die T-17 verwendet haben. Das ist ein Suchraum, noch keine Liste geänderter Ergebnisse: Ein Lauf kann andere Zeilen der Tafel nutzen, ein korrigierter Wert nur mittelbar eingehen oder eine Änderung durch Rundung verschwinden. Die fachliche Bewertung bleibt eine eigene Prüfaufgabe; die DAV-Richtlinie behandelt entsprechend Änderungskontrolle und den Umgang mit unterschiedlichen Modellergebnissen [1].

Die Gegenprobe für diese Architektur ist konkret: Nach der Importkorrektur wird der Zugriff auf die aktuellen Importdateien gesperrt. Lässt sich der alte Lauf aus seinem Archiv weiterhin prüfen? Scheitert das Überschreiben von T-17? Protokolliert erst der gesonderte Korrekturlauf die neuen Werte? Das sind technische Prüfungen; die Richtigkeit der Korrektur braucht eine unabhängige fachliche Erwartung.

In unserer Arbeit an Referenzrechnern ist das der Maßstab: Die Korrektur verbessert die nächste Rechnung. Der Nachweis erklärt weiterhin, warum die vorige anders ausfiel.