Update README_karten.md

03_Karten/README_karten.md

@@ -43,19 +43,45 @@ oder über ein Gate zurück. Beispiele:
 ## 3. Artefaktkarten (Ergebnisse)
 
 Wird an einer Aktivität ein Artefakt erzeugt, kommt die Karte ins Spiel und wird
-mitgeführt. Mapping:
+mitgeführt. Im Blueprint tauchen ~20 Artefakt-Bezeichnungen auf (Schnittstellen,
+`umfasst`-Listen); für das Spiel sind sie hier zu **15 Kern-Artefaktkarten**
+konsolidiert. Mehrere Dokument-Varianten werden bewusst auf eine Karte gelegt
+(Spalte „fasst zusammen").
 
-| Artefakt | entsteht bei |
-|----------|--------------|
-| Projektauftrag | Eingang aus DPM → ds_01 |
-| Service-Definition / Steckbrief | ds_01 |
-| Betriebsdokumentation | tr_06 |
-| Test-Report | tr_07 |
-| Service-Qualitätsbericht | op_06 |
-| Incident Record | sp_05–sp_07 |
-| Problem Record | sp_09 / sp_10 |
-| Workaround | sp_11 |
-| Service-Review-Bericht | rv_02 / rv_03 |
+| # | Artefaktkarte | Phase | entsteht bei | fasst zusammen / Notiz |
+|----|---------------|-------|--------------|------------------------|
+| A1 | **Projektauftrag** | Eingang (DPM) | → ds_01 | „Freigegebener Demand" aus dem Demand-Lifecycle |
+| A2 | **Service-Definition** | Design | ds_01 | zentrales Artefakt; im Review fortgeschrieben (`service_review`) |
+| A3 | **Service Design Document** | Design | ds_02 | Architektur- & Lösungsdesign (das WIE) |
+| A4 | **Implementation Blueprint** | Design | ds_03 | organisatorischer Einführungsplan |
+| A5 | **Gate-/SOR-Vorlage** | Transition | tr_01, tr_09, tr_11 | Gate-Anträge inkl. Transition-Steckbrief (Gate 2) |
+| A6 | **Betriebsdokumentation** | Transition/Operation | tr_06, op_02 | Service Operation Manual + Betriebshandbuch + Betriebsrichtlinien + Standard Changes + Known Errors |
+| A7 | **Test-Report** | Transition | tr_07 | Testprotokolle & Freigaben |
+| A8 | **Aktivierter Service** | Transition → Operation | tr_12 (Go-Live) | Aufnahme ins Portfolio, Katalog-Eintrag aktiv |
+| A9 | **Service-Qualitätsbericht** | Operation | op_06 | inkl. Monitoring-/Betriebsdaten & Alerts (op_05) |
+| A10 | **Incident Record** | Support | sp_05–sp_08 | inkl. Request Record (sp_04/sp_07) |
+| A11 | **Problem Record** | Support | sp_09 / sp_10 (aktual. sp_11) | einziges im Blueprint formal definierte Artefakt |
+| A12 | **Workaround** | Support | sp_11 | wird in die Wissensdatenbank eingetragen |
+| A13 | **Wissensdatenbank-Eintrag** | Support | sp_02 | Known Errors / FAQ / Standardlösungen |
+| A14 | **Service-Review-Bericht** | Review | rv_02 / rv_03 | „Service Performance & Improvement Review" (4-Dimensionen-Ampel) |
+| A15 | **DPM-Rücklauf** | Review → DPM | rv_05 / rv_06 | Variante A: Neuer Demand (Redesign) · Variante B: Retirement-Plan / Decommissioning-Auftrag |
+
+**Ergebnis-Hinweis:** Die Review-Entscheidung erzeugt entweder eine
+**Verbesserungsmaßnahme** (rv_04, fließt zurück in die Operation — kein eigenes
+Kartendeck nötig) oder den **DPM-Rücklauf** (A15).
+
+**Konsolidierungs-Logik (für die Druckvorlage):**
+- A6 bündelt die ganze „Betriebs-/Support-Doku"-Familie (Manual, Handbuch,
+  Richtlinien, Standard Changes, Known Errors) auf **eine** Karte.
+- A9 deckt die laufenden Betriebsdaten (Monitoring/Alerts) mit ab — Live-Daten
+  sind keine eigene physische Karte.
+- A10 trägt Incident **und** Request Record (gleicher Abschluss-Workflow).
+- A15 ist **eine** Karte mit zwei Rückseiten/Varianten statt zwei Decks.
+
+> Hinweis Datenqualität: Nur der **Problem Record** ist in den YAMLs als
+> `artefakte:`-Objekt mit Inhalten/Verantwortung spezifiziert. Für saubere,
+> generierbare Karten sollten A1–A15 analog als `artefakte:`-Block in den
+> `service-lifecycle_*.yaml` definiert werden (Single Source of Truth).
 
 ## 4. Gate-Beschreibungskarten