Brainversum · tuxametrics Graph Admin

adr vertraulich owner: matus

ADR-0003: Der Pilot-Betriebsmodus ist UNGEKLÄRT — und darf nicht dadurch entschieden werden, dass jemand anfängt zu arbeiten

ADR-0003: Der Pilot-Betriebsmodus ist UNGEKLÄRT — und darf nicht dadurch entschieden werden, dass jemand anfängt zu arbeiten

Status

Angenommen (2026-08-09) · Vom Nutzer ausdrücklich als sichtbarer Platzhalter statt einer Annahme gesetzt.

Kontext

Die Frage

tuxamed, Bearbeitet/00-bericht.md, offene Frage OF-B2 (im Material zugleich Entscheidung E-1): Arbeitet der Pilot

Eingestuft als über den Prototypen hinaus blockierend, extern abzusichern, Adressat Product Owner + klinischer Fachexperte. Die Frage berührt eine juristische Bewertung außerhalb der fachlich-medizinischen Verantwortung und ändert FACH-101 (Onboarding), FACH-118 (Einschränkungsdokumentation) und den Datenschutzumfang des gesamten Pilotbetriebs.

Der eine Satz, um den es geht

quelle-02.md, Zeile 86, zitiert im Bericht:

„Diese Entscheidung sollte nicht implizit dadurch getroffen werden, dass die erste Praxis anfängt zu arbeiten."

Das ist keine Mahnung, sondern eine Beschreibung des wahrscheinlichsten Verlaufs. Ein System, das echte Fälle technisch entgegennimmt, hat die Frage beantwortet — unabhängig davon, was in einem Protokoll steht. Ein Default-Wert in einer Konfigurationsdatei wäre genau diese implizite Entscheidung, nur früher und schriftlich.

Was zusätzlich fehlt

Das Lückenprotokoll des Berichts führt Kategorie 1 (Rohdaten und Beispieldatensätze) als vollständig leer und nennt sie „die schwerwiegendste Lücke des Durchlaufs" (OF-45): kein Laborbefund, kein Patientendatensatz, kein Export, kein Beispiel-PDF. Ohne echtes Material misst ein Prototyp nur die eigene Fantasie — und beim ersten Realimport fällt erfahrungsgemäß ein erheblicher Teil raus.

Solange beides gilt (Modus offen, kein echtes Material), gibt es keinen Zustand, in dem echte Fälle in diesem System richtig aufgehoben wären.

Entscheidung

  1. Der Betriebsmodus ist UNGEKLAERT. Das Enum PilotBetriebsmodus benennt die drei Antwortmöglichkeiten aus dem Material — damit die Frage ihre echten Optionen trägt, nicht damit eine davon gewählt wird.

  2. Zur Laufzeit ist ausschließlich UNGEKLAERT zulässig; jeder andere Wert bricht den Start ab (RegulatorikGuard, analog zu ADR-0002). Die Fehlermeldung zitiert den Satz oben.

  3. Jede Auswertung trägt synthetisch = true — gesetzt vom Service, nicht vom Aufrufer. AuswertungCreate hat bewusst kein entsprechendes Feld: ein Client soll den Wert nicht wegargumentieren können. Das Flag steht an der Entität, in jeder API-Antwort, im Berichtsabschnitt „Rahmen der Auswertung" und als Badge im UI.

    Das ist die Umsetzung von GG-META-0005 §9 („synthetische Daten explizit als solche kennzeichnen") an dem Ort, an dem sie wirkt: am Datensatz, nicht in einer README.

  4. Der einzige mitgelieferte Datensatz ist der synthetische Referenzfall unter init-bundle/praxis01-referenzfall-02.json. Er trägt "synthetisch": true, den Suffix SYNTH001 in Bundle-Schlüssel und interner Patientenreferenz, und einen eigenen Warnhinweis im Klartext: dass jede Zahl erfunden ist und insbesondere die Laborreferenzbereiche keine validierten Bereiche eines realen Labors sind.

  5. Die MCP-Tools sind ausschließlich lesend — und dieses ADR ist der Grund, warum das eine fachliche und keine technische Entscheidung ist. Solange der Modus offen ist, sehen Agenten ausschließlich synthetische Fälle. Wird OF-B2 jemals mit „echte Fälle" beantwortet, ist vor dem ersten echten Fall zu entscheiden, ob diese Tools bestehen bleiben dürfen. Der Hinweis steht im Javadoc von AuswertungMcpTools, weil er dann gelesen wird.

  6. Auflösung nur durch ein Nachfolge-ADR, das die getroffene Entscheidung, ihren Urheber und die daran hängenden Folgeanpassungen benennt (Onboarding, Einschränkungsdokumentation, Datenschutzumfang, MCP-Tools, .gitignore für Falldaten). Im Zug desselben ADR fällt das Startgate und synthetisch wird zu einem Feld, das ein Aufrufer setzen darf.

Konsequenzen