# 04 — `source_role` (Funktionale Rolle)

**Zweck:** Die zu `source_class` **orthogonale** Achse: *Was tut die Quelle im Dokument?* Sie bestimmt die **Control-Pool-Zugehörigkeit** bei Umsetzungsfragen — unabhängig von der Rechtsnatur. Deterministisch aus Markern abgeleitet, kein Re-Tagging des Bestands.

## Die 7 Rollen

| Konstante | Wert | Definition |
|-----------|------|-----------|
| `roleObligation` | `obligation` | die abstrakte Pflicht (das WAS) |
| `roleOperationalReq` | `operational_requirement` | konkrete bindende Anforderung (z.B. CRA Anhang I) |
| `roleProceduralReq` | `procedural_requirement` | Prozess: Meldung/Registrierung/DSFA/Incident |
| `roleControlStandard` | `control_standard` | Best-Practice-Katalog (NIST/OWASP/ISO/CIS) |
| `roleImplGuidance` | `implementation_guidance` | Umsetzungs-How-to (ENISA Good Practices, BSI) |
| `roleInterpretation` | `interpretation` | interpretiert die *Bedeutung* der Norm (EDPB-Leitlinie) |
| `roleDefinition` | `definition` | Definitionen / Scope / Recitals |

**Control-Pool** = `{operational_requirement, procedural_requirement, control_standard, implementation_guidance}` (die vier „wie umsetzen"-Rollen, `isControlPoolRole()`).

## Mechanik

`classifyRole()` (`control_role.go`) — Entscheidungsreihenfolge:

1. `IsRecital` → `definition`
2. `source_class == technical_standard` → `control_standard`
3. `source_class == supervisory_guidance`:
   - enthält `implMarker` → `implementation_guidance`
   - sonst → `interpretation`
4. `source_class == binding_law`:
   - `definitionMarker` → `definition`
   - `proceduralMarker` → `procedural_requirement`
   - `annexMarker` **oder** `operationalMarker` → `operational_requirement`
   - sonst → `obligation`
5. default → `obligation`

`controlRoleOf(payload)` klassifiziert die rohe Qdrant-Payload **vor** dem Mapping — so kann `searchControls` ([01](01-retrieval.md)) seinen tiefen dense-Pull filtern, ohne jeden Treffer voll zu materialisieren.

## Marker-Listen

| Liste | Einträge (Auszug) | → Rolle |
|-------|-------------------|---------|
| `proceduralMarkers` | Meldung, Meldepflicht, Notification, Registrierung, Konformitätserklärung, Incident, Reporting, Folgenabschätzung, DSFA, DPIA, Anzeigepflicht | `procedural_requirement` |
| `annexMarkers` | Anhang, Annex, Appendix, Anlage | `operational_requirement` |
| `operationalMarkers` | Anforderung, Requirement, essential, wesentliche | `operational_requirement` |
| `implMarkers` | Good Practice, Best Practice, Standards Mapping, Umsetzung, Implementation, Handreichung, Maßnahmenkatalog, ICS, SCADA, Technical Guideline, TIG | `implementation_guidance` |
| `definitionMarkers` | Begriffsbestimmung, Definition | `definition` |

## Warum orthogonal zu `source_class`

`source_class` (Rechtsnatur) und `source_role` (Funktion) sind **zwei Achsen**, nicht eine. ENISA bleibt `supervisory_guidance` (Rechtsnatur) **und** `implementation_guidance` (Funktion) — sie wird **nicht** umgetaggt (fachlich falsch), darf aber bei Umsetzungsfragen in den Control-Pool. So muss der Bestand nicht angefasst werden: `source_role` ist wie `source_class` aus Markern ableitbar.

`source_role` ist die **Wirbelsäule der Langzeit-Architektur** Regulation → Obligation → Operational Requirement → Control → Evidence ([09](09-framework-layer.md), Prio 4).

## Code

- `control_role.go` → `classifyRole()`, `controlRoleOf()`, `isControlPoolRole()`

## Adressierte Fehlerklassen

- **„Controls = nur technical_standard"** → vier Control-Pool-Rollen statt einer.
- **„abstrakte Pflicht dominiert Umsetzungsfrage"** → `obligation` ist *nicht* im Control-Pool (siehe [05](05-control-intent.md)).