Jede Transformation ist Code mit Version und Test.

Eine Transformation ist eine Funktion von Eingabe-Datensätzen auf einen Ausgabe-Datensatz. Sie ist in SQL oder in Python geschrieben und deklariert, was sie liest und was sie schreibt. Seiteneffekte hat sie nicht; Wirkungen nach außen gibt es nur über Handlungen. Dieselbe Eingabe und derselbe Code ergeben darum dasselbe Ergebnis.

Der Quelltext liegt in einem Git-Repository. Jede Änderung ist ein Commit mit Autor, Zeit und Begründung. Ein Lauf nennt den Commit, mit dem er gebaut wurde, und die Stände der Eingaben, die er las. Was im Betrieb läuft, ist damit eine bestimmte Version von Code und nicht der Stand, den jemand zuletzt in einer Oberfläche eingestellt hat.

Parameter wie Schwellwerte, Zuordnungstabellen und Umrechnungsfaktoren stehen als versionierte Daten neben dem Code, nicht in ihn eingebettet. Die Änderung eines Schwellwerts ist so eine Änderung im Repository und durchläuft dieselbe Prüfung wie jede andere.

Aus den deklarierten Ein- und Ausgaben leitet FORGE einen gerichteten Graphen ohne Kreise ab (DAG): Knoten sind Datensätze, Kanten sind Transformationen. Die Reihenfolge der Läufe steht in keinem Zeitplan, sie folgt aus dem Graphen. Ein Kreis wird beim Einchecken abgewiesen und nicht erst zur Laufzeit entdeckt.

Gebaut wird, was veraltet ist. Hat sich eine Eingabe nicht geändert, bleibt die Ausgabe stehen. Ändert sie sich, werden genau die Datensätze neu gebaut, die von ihr abhängen, in der Reihenfolge des Graphen. Das Ende eines Laufs ist ein Commit der Ausgabe: Sie wird als Ganzes sichtbar oder gar nicht, nie halb.

Große Datensätze verarbeitet FORGE inkrementell. Die Transformation sieht nur Zeilen, die seit dem letzten Lauf hinzukamen oder sich änderten, und führt ihren Zustand fort. Derselbe Code kann den ganzen Bestand neu rechnen, etwa nach einem Fehler; beide Wege müssen dasselbe Ergebnis liefern, und ein Test prüft das an einem kleinen Bestand.

Zwei Arten von Prüfung hängen an jeder Transformation. Modultests rufen sie mit kleinen, von Hand geschriebenen Eingaben auf und vergleichen das Ergebnis mit dem erwarteten, einschließlich der Grenzfälle: leere Eingabe, doppelte Schlüssel, fehlende Werte, Wechsel der Zeitzone. Sie laufen bei jedem Commit.

Erwartungen an Daten sind Bedingungen am Ausgabe-Datensatz, die bei jedem Lauf gegen die echten Daten geprüft werden: Schlüssel eindeutig, Pflichtfelder gefüllt, Werte im Bereich, jeder Verweis zeigt auf ein vorhandenes Objekt, die jüngste Zeile ist nicht älter als eine festgelegte Frist. Jede Erwartung ist als Warnung oder als Abbruch eingestuft.

Bricht ein Lauf ab, bleibt die vorige Version der Ausgabe stehen, und alles, was von ihr abhängt, liest weiter den letzten gültigen Stand. Ein Fehler in der Mitte der Kette erzeugt so keine halb gerechneten Objekte.

Eine Änderung kommt über einen Merge Request in die Hauptlinie. Zuerst laufen die Modultests. Dann baut FORGE die betroffenen Datensätze auf einem Zweig, getrennt vom Betrieb, und vergleicht das Ergebnis mit der Hauptlinie: welche Zeilen hinzukommen, wegfallen oder sich ändern, ob sich das Schema ändert, welche abhängigen Datensätze und Handlungen betroffen sind.

Der Vergleich gehört zur Prüfung durch Menschen. Wer freigibt, sieht nicht nur die Zeilen des Quelltexts, sondern die Wirkung auf die Daten. Wer eine Änderung schreibt, gibt sie nicht selbst frei; das Recht, in die Hauptlinie zu führen, ist ein eigenes Recht.

Erst nach der Freigabe wird die neue Version gebaut. Verletzt sie im ersten Lauf eine Erwartung, bleibt die vorige in Kraft. Eine Rücknahme danach ist das Zurücksetzen des Zeigers auf die vorige Version von Code und Daten.

Jede Ausgabe führt den Lauf mit, der sie erzeugte: Commit der Transformation, Stand jeder Eingabe, Zeit und Ergebnis der Erwartungen. Ein Objekt der Ontologie trägt damit nicht nur die Herkunft seiner Werte, also Quelle und Zeile, sondern auch den Weg: welche Transformationen in welcher Version aus der Rohzeile den Wert gemacht haben.

Die Spur ist bis auf die Spalte aufgelöst. Aus der Deklaration der Transformation weiß FORGE, welche Eingabespalten in welche Ausgabespalte einfließen. Ändert sich eine Quellspalte, ist sofort bekannt, welche Eigenschaften, Regeln und Handlungen betroffen sind. Für den Austausch mit anderen Werkzeugen ist OpenLineage vorgesehen.

Findet jemand einen Fehler in einer Transformation, wird sie korrigiert, und die abhängigen Datensätze werden aus der Rohzone neu gebaut. Die Rohzone ist nur anhängend und enthält alles, was je ankam; die Neuberechnung ist deshalb vollständig. Die fehlerhaften Stände bleiben als frühere Erfassungsstände erhalten. Wer eine alte Entscheidung prüft, sieht, was damals gerechnet war.