Werkzeug · Open Source · Apache-2.0

DeltaRecon

Zwischen zwei Ständen eines Berechnungsprogramms führt DeltaRecon die Differenzen im Ergebnis auf die Änderungen zurück, die sie verursachen – je Größe und deterministisch.

Selbst ausprobieren Quellcode auf GitHub →

Referenzzuordnung · v0.2.0 350 Modellpunkte

$ uv run deltarecon walk runs/oracle-n/run-record.json \    runs/oracle-n1/run-record.json \    --tolerance profiles/tolerance-bruttobeitrag.json \    --output runs/oracle-walkwalk: every revision attributed; 33 states run, 32 stepsstate 0 against the older record: reproducedstate 32 against the newer record: reproducedremainder: none⋮step 3 to 4: 2d05ecfae6aeb0100eeecbf860debb2ce42e79b2  Bruttobeitrag: sum 960253.583993, absolute sum 960253.583993⋮$ cd runs/oracle-walk && sha256sum -c ../../oracle/SHA256SUMSwalk.result.json: OKstep-02.compare.signature-table.json: OK⋮

Auszug aus einem Lauf vom 11.11.2026 mit dem Release v0.2.0, gekürzt an den Stellen mit ⋮. Alle 25 Prüfsummen des Orakels stimmen.

Die Differenz ist bekannt. Die Ursache nicht.

Nach einem Release verändern viele gleichzeitige Änderungen an Daten, Parametern und Code die Ergebnisse eines Berechnungsprogramms. Der Vergleich der beiden Stände zeigt, wie groß die Differenz ist. Welche Änderung die einzelnen Abweichungen verursacht hat, zeigt er nicht. DeltaRecon beantwortet diese zweite Frage.

Analysis of Change mit Revisionen als Schritten

Die Bewegungsanalyse kennen Sie aus Bilanz und Solvency II: eine Überleitung vom Vorjahr auf den aktuellen Stand, Schritt für Schritt. DeltaRecon analysiert hierbei die Modelländerungen, es nimmt als Schritte die Revisionen des versionierten Berechnungsprogramms. Jede Revision ist ein Schritt. Zwischen Stand N und Stand N+1 entsteht eine Überleitung mit einem Beitrag je Revision und Größe.

Durchlauf: Rechnet jeden Stand zwischen N und N+1 und vergleicht ihn mit dem Stand davor.
Suche: Halbiert die Historie und teilt nur Intervalle weiter, deren Endstände sich unterscheiden. Sie braucht weniger Läufe als der Durchlauf. Im Schnellstart des Release rechnet sie 17 Stände, der Durchlauf bräuchte 33.
Beleg: Jeder Lauf hinterlässt einen Laufbeleg mit Hashes und lässt sich wiederholen. Jedes Ergebnis stammt aus deterministischen Läufen und Vergleichen.

Wo DeltaRecon sitzt

DeltaRecon wird per Adapter an die Berechnungsprogramme (Engines), die ein Haus schon betreibt, angeschlossen. Die Engines bleiben unverändert. Nur der Adapter kennt die Engine und liest ihr Repository; Vergleich, Durchlauf und Suche kennen keine Engine.

Eine weitere Engine kommt mit einem eigenen Adapter hinzu, DeltaRecon selbst bleibt gleich. Umgesetzt ist dies mittels Verträgen für verschiedene Berechnungsstufen. Eine Stufe ist eine definierte Liste von Ergebnisgrößen, zum Beispiel die Projektion der Passiv-Cashflows. Für sie legen drei Verträge Lauf, Änderungen und Vergleich fest, für jede Engine gleich.

Abgleiche zwischen den Läufen

① Stand N ↔ Stand N+1 derselben Engine

→ Überleitung je Revision und Größe (Durchlauf, Suche)

② Engine A ↔ Engine B, gleiche Stufe (vorgesehen, nicht gebaut)

→ Abweichung je Modellpunkt, keine Überleitung (keine gemeinsame Historie)

DeltaRecon

Vergleich je Modellpunkt und Periode · Toleranzprofile
Durchlauf · Suche (nur ①)
Laufbelege · Wiederholung (Replay) · Hashes

Stufen-Verträge, offen und engine-neutral: run · changes · compare

Adapter

Referenzmodell (heute gebaut)

RLV_DE_S unter modelx

Adapter

Projektionsmodell des Hauses (vorgesehen, nicht gebaut)

Adapter

Bestandsführung (vorgesehen, nicht gebaut)

Adapter

Referenzrechner (vorgesehen, nicht gebaut)

z. B. Excel

vorbestehende Berechnungsengines, unverändert

Versionsverwaltung je Engine (Git, SVN …): Revisionen = Stände

Ausgaben

Überleitung je Revision und Größe (nur ①)
Abweichungen je Modellpunkt und Periode
Signaturtabelle
Befunde: Stände, die nicht laufen
Laufbelege, Hashes
Excel-Sicht (später) (vorgesehen, nicht gebaut)

Durchgezogen ist heute gebaut und öffentlich, gestrichelt ist durch die Verträge vorgesehen, aber nicht gebaut. Heute: eine Engine (das Referenzmodell RLV_DE_S unter modelx), ein Adapter, Abgleich ① auf der Stufe Passiv-Cashflows. Vorgesehen: weitere Engines mit eigenem Adapter, Abgleich ② (Vergleich ohne Überleitung), die Excel-Sicht.

Abgleich ② ist ein Vergleich, keine Überleitung

Der Vergleich braucht keine Historie. Er verlangt dieselbe Stufe, dieselbe Zeitbasis, dieselben Größen in derselben Reihenfolge mit denselben Einheiten und gleiche Modellpunkt-IDs. Durchlauf und Suche brauchen dagegen eine Historie zwischen den beiden Ständen. Zwei Engines haben keine gemeinsame Historie. Deshalb liefert ② die Abweichungen je Modellpunkt und die Signaturtabelle, aber keine Zuordnung zu Revisionen.

Zusammen ergänzen sich die beiden: ② zeigt, wo zwei Engines auseinanderliegen. ① auf jeder Seite zeigt, welche Revision eine bestehende Übereinstimmung gebrochen hat.

② ist durch die Verträge angelegt, nicht getestet. Es gibt heute keinen zweiten Adapter.

Eine Differenz, neun Revisionen.

Am Referenzmodell liegen zwischen Stand N (fa36857) und Stand N+1 (887b718) 32 Revisionen der Hauptlinie von delib-history. Der vollständige Durchlauf über alle 33 Stände und 350 Modellpunkte ordnet die Differenz des Bruttobeitrags neun Revisionen zu. Die Summen laufen über alle Modellpunkte und Monate.

Bruttobeitrag · Stand N → N+1 · Differenz in €

Änderungen unter einem Cent je Modellpunkt und Monat zählen nicht als Beitrag. Diese Schwelle lässt sich durch ein Toleranzprofil je Größe definieren. Gesamtdifferenz 1.048.262,17 €, Summe der Beiträge 1.048.212,28 €: Den Rest von 49,90 € tragen die Schritte 25 und 27 mit je 24,95 €, in jeder Zelle unter einem Cent. Die Paare 17/18 und 19/20 heben sich auf. Liegt ein solches Paar in einem Intervall, sieht die Suche es nicht (Grenzen). Im Bild: Die Balken sind die Beiträge, die Linie ist der laufende Stand, der schraffierte Balken ist die Summe.

Die Werte zur Grafik (32 Revisionen, 350 Modellpunkte)
Schritt	Änderung und Revision	Revision	Beitrag in €
2	Stornowahrscheinlichkeit im 1. Versicherungsjahr 6 % → 5 % 936e50d	936e50d	+81.969,46
4	Bestand: größter Faktor der Versicherungssumme der generierten Modellpunkte 2 → 2,5 2d05ecf	2d05ecf	+960.253,58
6	Merge der Ratenzuschläge: monatlich 5 % → 4 %, vierteljährlich 3 % → 2,5 % 8f81933	8f81933	−43.462,35
12	Ratenzuschlag halbjährlich 2 % → 1,5 % 83f01cf	83f01cf	−12.063,71
17	Summenbezogener γ-Kostenzuschlag 0,30 ‰ → 0,35 ‰ e23137a	e23137a	+70.674,60
18	Revert von Schritt 17 29c4a03	29c4a03	−70.674,60
19	Ratenzuschlag monatlich 4 % → 4,5 % 88cdde3	88cdde3	+15.920,81
20	Ratenzuschlag monatlich wieder 4 % c82b72b	c82b72b	−15.920,81
30	Beitragsbezogener β-Kostenzuschlag 5 % → 5,5 % 7f1dc64	7f1dc64	+61.515,29
Summe der Beiträge			1.048.212,28
Rest: Schritte 25 und 27, je unter einem Cent je Zelle			+49,90
Gesamtdifferenz N → N+1			1.048.262,17

Die Beiträge sind einzeln auf Cent gerundet. Die Summen sind aus den ungerundeten Werten gebildet, deshalb kann die Summe der gerundeten Zeilen um einen Cent abweichen.

Die Zuordnung ist über SHA-256 nachprüfbar: Das Verzeichnis oracle/ im Release enthält die beiden Lauf-Anfragen und die Prüfsummen des Durchlaufs. Die Befehle zum Nachrechnen stehen im README unter „Reproduce the reference attribution“.

Auf Ihrem Rechner, ohne Installation.

Für Windows gibt es ein Paket, das ohne Installation läuft: entpacken und quickstart.cmd doppelklicken. Die geführte Demo erklärt jeden Schritt und wartet vor jedem auf Enter. Eine deutsche Kurzanleitung liegt als LIESMICH.txt im Paket. Für Linux gibt es ein eigenes Paket, für macOS den Weg über den Quellcode.

Das Paket ist nicht signiert. Browser oder SmartScreen können warnen, und am Firmenrechner braucht es eventuell eine Freigabe der IT. Die Prüfsummen stehen in SHA256SUMS beim Release.

quickstart.cmdgeführte Demo
LIESMICH.txtKurzanleitung
delib-history/Referenzmodell
profiles/Toleranzprofile

Windows-Paket herunterladen · v0.2.0 Alle Dateien des Release →

Grenzen

Eine Stufe, ein offenes Lehrmodell. Was DeltaRecon heute nicht leistet, steht hier und im README.

Paare im Intervall: Die Suche sieht keine Beiträge, die sich innerhalb eines Intervalls aufheben, etwa eine Änderung und ihren Revert. Nur der vollständige Durchlauf sieht sie; eine gegen den Durchlauf geprüfte Suche nennt sie als verpasst.
Reihenfolge: Die Zuordnung folgt der Reihenfolge der Historie: Eine Wechselwirkung zweier Revisionen landet bei der späteren. Eine andere Reihenfolge könnte anders zuordnen.
Eine Stufe: Heute ist eine Stufe abgedeckt: die Projektion der Passiv-Cashflows.
Lehrmodell: Das Referenzmodell RLV_DE_S aus der lifelib-Bibliothek delib ist ein Lehrmodell, keine Bewertung. Die biometrischen Tafeln sind Platzhalter, die Cashflows brutto und undiskontiert, der Bestand ist synthetisch und enthält keine Kundendaten.

Ausblick: Geplant ist eine Weiterentwicklung, in der Agenten vorab die Revisionen eingrenzen, die für eine Abweichung in Frage kommen. Gerechnet und zugeordnet wird auch dann deterministisch, und jede Zuordnung bleibt gegen den vollständigen Durchlauf prüfbar.

Open Source, und wer dahinter steht

DeltaRecon steht unter der Apache-Lizenz 2.0, das Repository des Referenzmodells delib-history unter der MIT-Lizenz. Es ist ein offenes Werkzeug; Support ist nicht zugesagt. Entwickelt wird DeltaRecon von Degelmann Solutions.

Fragen zum Adapter für eine eigene Engine beantworten wir gerne.

Kontakt aufnehmen →

Repository deltarecon → Repository delib-history →