a3053c3c86
CI / detect-changes (push) Successful in 14s
CI / branch-name (push) Has been skipped
CI / guardrail-integrity (push) Has been skipped
CI / secret-scan (push) Has been skipped
CI / dep-audit (push) Has been skipped
CI / sbom-scan (push) Has been skipped
CI / build-sha-integrity (push) Successful in 9s
CI / validate-canonical-controls (push) Successful in 19s
CI / loc-budget (push) Successful in 23s
CI / go-lint (push) Has been skipped
CI / python-lint (push) Has been skipped
CI / nodejs-lint (push) Has been skipped
CI / nodejs-build (push) Has been skipped
CI / test-go (push) Has been skipped
CI / iace-gt-coverage (push) Has been skipped
CI / test-python-backend (push) Has been skipped
CI / test-python-document-crawler (push) Has been skipped
CI / test-python-dsms-gateway (push) Has been skipped
9 docs + index in docs-src/architecture/ documenting the deterministic retrieval engine: retrieval pipeline, authority rerank, source_class, source_role, control-intent + diversity, assessment, confidence, explainability + supersede, framework_* layer. Each doc carries the exact constants, the rationale behind them, code refs, and the failure class it addresses. Audit/onboarding reference. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
61 lines
3.6 KiB
Markdown
61 lines
3.6 KiB
Markdown
# 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)).
|