Tutorial: Vom Finding zum Verdict

In diesem Tutorial nimmst du ein Signal Finding, schreibst eine Thesis um zu testen ob das Muster real ist, und schreibst ein Verdict um zu erklaeren warum es passiert. Das ist der analytische Kern-Workflow — der Weg von “etwas stimmt nicht” zu “deshalb ist es so und das sollten wir tun.”

Zeit: 20 Minuten Voraussetzungen: Tutorial: Dein erster Build abgeschlossen (du hast einen funktionierenden Tenant mit probe_unbilled_cases)

1. Wo wir aufgehoert haben

Nach Tutorial #1 hast du:

• Einen Tenant mit Fall- und Abrechnungsdaten
• Ein Signal (probe_unbilled_cases), das Faelle ohne Abrechnungsereignisse findet
• Findings fuer CASE_002 und CASE_004

Jetzt ist die Frage: Ist das ein systemisches Problem oder nur Rauschen?

2. Eine Thesis schreiben

Eine Thesis (frueher Hypothesis genannt) ist eine testbare Geschaeftsfrage. Erstelle afs/theses/thesis_billing_gap.yaml:

thesis_id: thesis_billing_gap
version: "1.0.0"
short_code: BGAP

statement:
  en: "Are cases systematically left unbilled, indicating a broken billing workflow?"
  de: "Werden Faelle systematisch nicht abgerechnet, was auf einen fehlerhaften Abrechnungsprozess hindeutet?"
  fr: "Les cas sont-ils systematiquement non factures, indiquant un processus de facturation defaillant?"

category: financial_anomaly

evidence:
  - probe_id: probe_unbilled_cases
    role: primary
    weight: 3

verdict:
  thresholds:
    confirmed: 0.6
    plausible: 0.3

interpretation:
  confirmed:
    en: "Multiple cases have no billing events. This indicates a systematic gap in the billing workflow — cases are being closed without triggering the billing process."
    de: "Mehrere Faelle haben keine Abrechnungsereignisse. Dies deutet auf eine systematische Luecke im Abrechnungsprozess hin."
    fr: "Plusieurs cas n'ont pas d'evenements de facturation. Cela indique une lacune systematique dans le processus de facturation."
  plausible:
    en: "Some unbilled cases exist but the pattern is not conclusive. Could be delayed billing or manual exceptions."
    de: "Einige nicht abgerechnete Faelle existieren, aber das Muster ist nicht schluessig."
    fr: "Certains cas non factures existent mais le schema n'est pas concluant."
  not_observed:
    en: "All cases have corresponding billing events. No billing gap detected."
    de: "Alle Faelle haben entsprechende Abrechnungsereignisse. Keine Abrechnungsluecke erkannt."
    fr: "Tous les cas ont des evenements de facturation correspondants. Aucune lacune detectee."
  insufficient:
    en: "Not enough case and billing data to evaluate the billing gap thesis."
    de: "Nicht genuegend Fall- und Abrechnungsdaten, um die These zu bewerten."
    fr: "Pas assez de donnees pour evaluer la these de lacune de facturation."

Wichtige Punkte:

• evidence referenziert dein bestehendes Signal mit Rolle primary (Gewicht 3)
• verdict.thresholds setzen die Messlatte: Score >= 0.6 = confirmed, >= 0.3 = plausible
• interpretation liefert menschenlesbaren Text fuer alle 4 moeglichen Ergebnisse
• Aller Text ist dreisprachig (en/de/fr)

3. Bauen und Thesis-Status pruefen

jinflow make

Oeffne den Explorer:

jinflow explore

Navigiere zu Theses (druecke H). Du solltest thesis_billing_gap mit einem Status sehen. Mit 2 von 5 nicht abgerechneten Faellen (40%) und einem primaeren Signal mit Findings sollte der Evidence Score dies auf confirmed oder plausible bringen.

Klicke auf die Thesis-Karte um die Detailseite zu sehen: den Interpretationstext, die Evidenzkette zu probe_unbilled_cases und die Findings des Signals.

4. Ein Verdict schreiben

Jetzt erklaere warum das passiert. Erstelle afs/verdicts/verdict_billing_process_gap.yaml:

verdict_id: verdict_billing_process_gap
version: "1.0.0"

thesis_id: thesis_billing_gap

root_cause_category: process_failure
root_cause_id: missing_billing_trigger

conditions:
  - probe_id: probe_unbilled_cases
    field: finding_count
    above: 1

confidence:
  base: 0.7
  boost_if:
    - probe_id: probe_unbilled_cases
      field: finding_count
      above: 3
      boost: 0.2

explanation:
  en: "The billing system does not automatically trigger invoicing when a case is closed. Cases closed outside of normal hours or via the fast-track discharge path bypass the billing trigger entirely."
  de: "Das Abrechnungssystem loest bei Fallabschluss nicht automatisch eine Rechnungsstellung aus. Faelle, die ausserhalb der normalen Geschaeftszeiten oder ueber den Schnellentlassungspfad abgeschlossen werden, umgehen den Abrechnungsausloeser vollstaendig."
  fr: "Le systeme de facturation ne declenche pas automatiquement la facturation lors de la cloture d'un cas. Les cas clotures en dehors des heures normales ou via le parcours de sortie rapide contournent entierement le declencheur de facturation."

recommendation:
  en: "Implement an automated billing check that runs on case closure. Flag any case closed without a corresponding billing event within 24 hours. Audit the fast-track discharge pathway for billing integration."
  de: "Implementieren Sie eine automatische Abrechnungspruefung bei Fallabschluss. Markieren Sie jeden Fall, der ohne entsprechendes Abrechnungsereignis innerhalb von 24 Stunden abgeschlossen wird."
  fr: "Mettre en place une verification automatique de facturation a la cloture du cas. Signaler tout cas cloture sans evenement de facturation correspondant dans les 24 heures."

Wichtige Punkte:

• thesis_id verlinkt zur gerade geschriebenen Thesis
• conditions definieren wann dieses Verdict ausloest (mindestens 2 nicht abgerechnete Faelle)
• confidence.base ist 0.7, gesteigert auf 0.9 wenn mehr als 3 Findings
• explanation sagt warum (Prozessversagen: fehlender Abrechnungsausloeser)
• recommendation sagt was zu tun ist (Check automatisieren)

5. Bauen und das vollstaendige Bild sehen

jinflow make
jinflow explore

Navigiere zu Theses → klicke thesis_billing_gap. Unter der Interpretation solltest du jetzt den Verdict-Abschnitt sehen mit:

• Root Cause Badge: process_failure
• Konfidenz-Balken
• Erklaerungstext
• Empfehlungstext

6. Die analytische Pyramide in Aktion

Du hast gerade eine vollstaendige analytische Kette gebaut:

Das ist die jinflow-Methode: erkennen → bewerten → erklaeren → empfehlen. Jede Ebene ist YAML, zu SQL kompiliert, deterministisch und reproduzierbar.

Was du gelernt hast

• Eine Thesis (frueher Hypothesis) aggregiert Evidenz aus Signals und produziert einen Status (confirmed/plausible/not_observed/insufficient)
• Ein Verdict (frueher Diagnosis) erklaert warum eine bestaetigte Thesis wahr ist, mit Root Cause und Empfehlung
• Die Evidenzkette ist im Explorer sichtbar: Finding → Thesis → Verdict
• Aller Text ist dreisprachig — jede Interpretation, Erklaerung und Empfehlung hat en/de/fr

Naechste Schritte

• Tutorial: Expertenwissen erfassen — schreibe SMEbits und BitBundles
• Thesis Referenz — alle Thesis-Felder
• Verdict Referenz — alle Verdict-Felder
• Glossar — jeder Begriff erklaert