Tutorial: Expertenwissen erfassen

In diesem Tutorial erfasst du ein Stueck Expertenwissen als SMEbit, fuegst einen testbaren Check hinzu, der es gegen Daten validiert, und gruppierst es in ein BitBundle-Narrativ. So gelangt institutionelles Wissen ins System — zugeschrieben, versioniert und verifizierbar.

Zeit: 10 Minuten Voraussetzungen: Tutorial: Dein erster Build abgeschlossen

1. Das Szenario

Beim Erkunden deiner Findings in Tutorial #1 faellt dir auf, dass CASE_002 ein ambulanter Fall ist. Du sprichst mit einem Fachexperten, der dir sagt:

“Ambulante Faelle werden oft nicht abgerechnet, weil der Abrechnungsausloeser nur bei stationaeren Entlassungen feuert. Das ist eine bekannte Systemlimitierung.”

Das ist Expertenwissen. Kein Datenmodell kann es ableiten. Aber es erklaert deine Findings.

2. Ein SMEbit schreiben (Level 0 — Beobachtung)

Erstelle afs/smebits/smebit_outpatient_billing_gap.yaml:

smebit_id: smebit_outpatient_billing_gap
version: "1.0.0"

provider:
  name: "Domain Expert"
  role: "Operations Manager"
  date: "2026-03-24"

scope:
  tenant_id: "*"
  source_system: null
  time_range:
    from: null
    until: null

category: system
tags: [billing, outpatient, known-limitation]
status: active

subject:
  en: "Outpatient billing trigger does not fire automatically"
  de: "Ambulante Abrechnungsausloesung erfolgt nicht automatisch"
  fr: "Le declencheur de facturation ambulatoire ne se declenche pas automatiquement"

content:
  en: |
    The billing system only triggers automatic invoicing on inpatient
    discharge events. Outpatient cases (day_case, outpatient) must be
    billed manually or through a separate batch process. This explains
    why outpatient cases frequently appear as unbilled in signal findings.
  de: |
    Das Abrechnungssystem loest die automatische Rechnungsstellung nur
    bei stationaeren Entlassungen aus. Ambulante Faelle muessen manuell
    oder ueber einen separaten Batch-Prozess abgerechnet werden.
  fr: |
    Le systeme de facturation ne declenche la facturation automatique
    que lors des clotures de dossiers stationnaires. Les cas ambulatoires
    doivent etre factures manuellement ou via un processus batch separe.

why:
  en: "Legacy system design — the billing interface was built for inpatient workflows only."
  de: "Legacy-Systemdesign — die Abrechnungsschnittstelle wurde nur fuer stationaere Workflows entwickelt."
  fr: "Conception systeme heritee — l'interface de facturation a ete concue uniquement pour les flux stationnaires."

anchors:
  - probe_id: probe_unbilled_cases
    hypothesis_id: null
    entity_type: Case

Dies ist ein Level 0 SMEbit — eine Beobachtung. Kein SQL, kein Verdict. Es lebt in der Registry und ist im Explorer sichtbar.

3. Bauen und erkunden

jinflow make
jinflow explore

Navigiere zu SMEbits (druecke S). Du siehst dein SMEbit mit der Provider-Zuschreibung, Kategorie-Badge und der vollstaendigen Erklaerung.

4. Einen testbaren Check hinzufuegen (Level 1)

Mache es jetzt verifizierbar. Fuege einen check-Block zum selben YAML hinzu:

check:
  description:
    en: "Verify that unbilled cases are predominantly outpatient"
    de: "Ueberpruefen, dass nicht abgerechnete Faelle ueberwiegend ambulant sind"
    fr: "Verifier que les cas non factures sont principalement ambulatoires"
  entity_type: Case
  query: |
    SELECT
      CASE WHEN outpatient_ratio > 0.5 THEN 'confirmed' ELSE 'violated' END AS status,
      outpatient_ratio,
      unbilled_outpatient,
      unbilled_total
    FROM (
      SELECT
        COUNT(*) FILTER (WHERE case_type != 'inpatient') AS unbilled_outpatient,
        COUNT(*) AS unbilled_total,
        ROUND(COUNT(*) FILTER (WHERE case_type != 'inpatient')::DECIMAL / NULLIF(COUNT(*), 0), 2) AS outpatient_ratio
      FROM {{ ref('gold_cases') }} c
      WHERE NOT EXISTS (
        SELECT 1 FROM {{ ref('gold_billing_events') }} b
        WHERE b.case_id = c.case_id
      )
    )
  expect: confirmed

Jetzt ist das SMEbit Level 1 — es kompiliert zu einem dbt-Modell und produziert ein Verdict: confirmed (ja, nicht abgerechnete Faelle sind meistens ambulant) oder violated (die Behauptung des Experten trifft nicht zu).

5. Neu bauen und Verdict sehen

jinflow make
jinflow explore

Die SMEbit-Detailseite zeigt jetzt ein Verdict-Badge — confirmed oder violated. Das Wissen des Experten ist jetzt bei jedem Build, ueber jeden Tenant hinweg testbar.

6. In ein Narrativ buendeln (BitBundle)

Erstelle afs/bitbundles/bb_billing_system_limitations.yaml:

bitbundle_id: bb_billing_system_limitations
version: "1.0.0"

curator:
  name: "Analyst"
  role: "Data Engineering"
  date: "2026-03-24"

scope:
  tenant_id: "*"

title:
  en: "Billing System Limitations"
  de: "Einschraenkungen des Abrechnungssystems"
  fr: "Limitations du systeme de facturation"

narrative:
  en: |
    The organization's billing system has known limitations that explain
    recurring patterns in signal findings. These are not data quality
    issues — they are system behaviors documented by domain experts.
    Understanding them prevents false alarms and guides process
    improvement priorities.
  de: |
    Das Abrechnungssystem der Organisation hat bekannte Einschraenkungen,
    die wiederkehrende Muster in den Signal-Befunden erklaeren.
  fr: |
    Le systeme de facturation de l'organisation a des limitations connues
    qui expliquent les schemas recurrents dans les resultats des sondes.

smebits:
  - smebit_id: smebit_outpatient_billing_gap
    note:
      en: "The primary limitation — outpatient cases bypass the automatic billing trigger."
      de: "Die Haupteinschraenkung — ambulante Faelle umgehen den automatischen Abrechnungsausloeser."
      fr: "La limitation principale — les cas ambulatoires contournent le declencheur automatique."

status: active
tags: [billing, system-limitations]

7. Bauen und das Bundle sehen

jinflow make
jinflow explore

Navigiere zu Use Cases (druecke U). Dein BitBundle erscheint mit dem Narrativ und seinem verknuepften SMEbit darunter.

Was du gelernt hast

• SMEbits erfassen atomares Expertenwissen — zugeschrieben an einen benannten Provider, mit Umfang und Lebenszyklus
• Level 0 (Beobachtung) ist nur Dokumentation — kein SQL, kein Verdict
• Level 1 (Check) fuegt eine testbare Behauptung hinzu, die bei jedem Build confirmed/violated/no_data produziert
• Das why-Feld unterscheidet Daten von Wissen — es erfasst den Grund hinter der Beobachtung
• BitBundles gruppieren verwandte SMEbits in ein Narrativ — die “Story”-Ebene
• Anker verlinken SMEbits mit Signals, Theses und Entities fuer Auffindbarkeit

Naechste Schritte

• Tutorial: Neuen Tenant onboarden — Daten empfangen, init, bauen, Snapshot
• SMEbit Referenz — alle SMEbit-Felder
• BitBundle Referenz — alle BitBundle-Felder
• Glossar — jeder Begriff erklaert