ADR-0001: Erster produktiver Rollout — eigene DB-App als Senke UND Datenquelle

Status: accepted
Datum: 2026-10-25
Entscheider: CEO (A. Leinen), CTO
Betroffene Dokumente: docs/architecture/v1.1.md Abschnitte 7.2, 10 (Phase 4), 12

Kontext und Problemstellung

ProofedMesh soll in einem ersten produktiven Durchlauf einen vollständig attestierten Reisekostenprozess abbilden: Benutzer wählt im Chat ein Projekt, Agenten holen Vorab-Infos und bauen eine Buchungsnutzlast, eine Senke übernimmt. Der Trust-Core (Approval, Signing, Verification, OPA, Trillian) muss sich dabei einmal end-to-end gegen echte Komponenten beweisen.

Zwei Fragen sind zu entscheiden: (1) Welche Senke ist die erste produktive? (2) Wo holen Agenten ihre Vorab-Lesedaten?

Entscheidungsoptionen

Option A — SAP S/4HANA zuerst (Senke + evtl. OData als Datenquelle).
Option B — eigene kleine Go-DB-App als Senke sink:expense-db-app und Datenquelle ds:expense-db-app im selben Prozess.
Option C — HTTP-Webhook an einen externen Dritt-Dienst als Senke, kein eigener Datenquellen-Dienst.

Entscheidung

Option B. Wir bauen eine kleine Go-DB-App (expense-db-adapter + expense-db-postgres), die zugleich Senke und Datenquelle ist, und nutzen sie für den ersten produktiven Rollout.

Begründung

Kleinster Blast Radius. Fehler im Trust-Core gefährden hier nur unsere eigene Instanz, keinen produktiven SAP-Mandanten.
Schema-Hoheit bei uns. Wir können expense.canonical, ds.expense.project_assignment und sink.db.expense so modellieren, wie es für den sauberen Durchlauf gebraucht wird; keine Rücksicht auf vorhandene ERP-Felder in Runde 1.
Deckt beide Pfade in einem Adapter. Lesepfad (project_assignments, account_assignments, cost_centers) und Schreibpfad (expenses) teilen Postgres-Instanz und Sitzungskontext — der Adapter kann in einer Transaktion gegenlesen, was er geschrieben hat, und die Testabdeckung wird trivial.
Kein externer Vertrauensanker. Keine externen Tokens, keine externe Replay-Tabelle, keine SM59-Rotation in Runde 1. Jede Komponente läuft in unserem Cluster.
Lieferbar in Wochen, nicht Monaten. SAP-Integration (Option A) hat eigene Produktentscheidungen offen (Travel Management vs. Concur vs. kundeneigener FI-Prozess, siehe docs/architecture/v1.1.md 7.1). Diese Entscheidung können wir treffen, nachdem der Trust-Kern bewiesen ist.

Option C scheidet aus: ohne Datenquellen-Komponente in Runde 1 bleibt der parallele Lesepfad ungetestet, und Attestierungen mit read_materials sind der kryptografisch anspruchsvollere Teil.

Konsequenzen

Positive

Phase 4 im Phasenplan hat einen klaren Scope mit einem einzigen Deployment (expense-db-adapter).
Wir können den Adapter-Vertrag aus docs/architecture/v1.1.md 7.0 und 7a.0 an einer realen Komponente härten, bevor wir SAP (sap_abap) oder generische Webhooks angehen.
Das Datenmodell der DB-App ist klein und publishable — es dient später als Referenz für Partner, die eine ähnliche Senke anbinden wollen.

Negative / Trade-offs

SAP-Buchung schiebt sich auf Phase 6. Bis dahin müssen Reisekosten entweder im Zweistromverfahren (DB-App parallel zu SAP, keine Freigabe-Automatisierung in SAP) oder manuell nachgebucht werden.
Wir bauen ein Business-Datenmodell neben SAP auf, das wir später konsolidieren müssen. Risiko eines Doppelstammdatens; wird in späterer ADR adressiert.

Folgearbeiten / Open Points

ADR zur Rolle der DB-App gegenüber SAP (Spiegelung vs. zweite autoritative Quelle).
ADR zur SAP-Buchungsschnittstelle (Travel Management vs. Concur vs. kundeneigener FI-Prozess), spätestens vor Phase-6-Start.

3.8 KiB Raw Blame History