diff --git a/docs-src/development/session_ownership_model_v1.md b/docs-src/development/session_ownership_model_v1.md index c47abc88..932fdf41 100644 --- a/docs-src/development/session_ownership_model_v1.md +++ b/docs-src/development/session_ownership_model_v1.md @@ -124,3 +124,27 @@ Regulierungen → Procedures → Controls → Evidence. Das beginnt das Gespräc Procedures), bis Domäne 3 zeigt, WELCHE Capabilities real gebraucht werden (sonst modelliert man 30, von denen 12 genutzt werden). 4. **Domäne 1:** Re-Ingest abschließen, Span-Anker, Citation-API stabilisieren. + +### Domäne 2 — Wake-up-Trigger (statt vagem „pausiert") + +Domäne 2 ruht NICHT unbestimmt — sie wird wieder aktiv, sobald EINER dieser Trigger feuert: +``` +Feature Graph (Domäne 3) >= 200 Features → Feature Coverage Report (erster Auftrag, s.u.) +ODER Span-Anker verfügbar (Domäne 1) → pending_span_anchor auflösen (citation_pending → echte Spans) +ODER neue Regulierung ingestiert → Discovery-Cut + Reuse-Metrik +ODER Runtime (Branch B) kennt neue Evidence-Typen → required_procedures/evidence_patterns endgültig füllen +``` +Bis dahin steht überall `citation_pending` / `required_procedures: []` — bewusst, kein Defekt. + +### Erster Folgeauftrag von Domäne 2 (sobald Feature Library v1 steht): FEATURE COVERAGE REPORT + +NICHT „neue CRA-Domäne". Sondern die **Wissenslücken-Analyse**, die diese Architektur erstmals ermöglicht: +pro Feature die Kette `Feature → cap.* → realizes_obligations → Procedures → Evidence` traversieren und +**Coverage % je Feature** berechnen — wie vollständig ist die Modellierungskette? +``` +Fernwartung → 100 % · USB → 94 % · Bluetooth → 83 % · Cloud → 71 % +``` +Output: je Feature die Lücken — fehlende Capability · fehlende Procedure · fehlender Evidence-Typ. +Zeigt sofort, was schon vollständig modelliert ist und wo Domäne 2 als Nächstes nacharbeiten muss. +Traversal-Logik gehört Domäne 2 (cap.*→Obligation→Procedure→Evidence); der Feature→cap.*-Input kommt +read-only von Domäne 3. Gated auf Feature Library v1.