The advisor was structurally correct but unusable: every question showed a snake_case capability id plus a
single generic fallback reason ("Keine Anhaltspunkte im Unternehmensprofil — klären"). The expert text
already EXISTED in the transition patterns (why_asked / reviewable_claim) — the pipeline just dropped it.
- transition_reasoning: TargetRequirement gains `rationale`; assess_transition uses it as the request
reason when present, else the generic fallback (additive, backward-compatible for all consumers).
- onboarding_service._target carries the pattern's why_asked (delta) and reviewable_claim (likely_covered)
into the requirement rationale -> the question's `why`.
- knowledge/onboarding/capability_labels.yaml: curated DE labels (id -> human), reusable across targets;
labels_for() + response.capability_labels expose them; the frontend renders label || prettified id.
Now ISO27001->TISAX reads "Auftragsverarbeitung (Art. 28 DSGVO) — If a TISAX data label is in scope, you
must show Art. 28 GDPR processing-on-behalf controls; ISO 27001 does not establish these." instead of
"data_protection_processing_on_behalf — klären". why_asked text is still EN (existing knowledge; translation
is curation). 34 onboarding+transition tests pass, mypy --strict clean (13 modules), check-loc 0.
A focused client page at /sdk/onboarding-advisor that exercises POST /api/compliance/onboarding/
advisor-start through the existing compliance proxy: pick certifications + target + scanner findings
(observation / partial / requirement) and render the result — headline, silent-intake summary,
auto-detected (green), indications (amber), next-best questions with WHY, inferred (Welt-1) vs rejected
assumptions, capability delta, evidence requests, completeness. NOT the regulation gap engine
(/sdk/gap-analysis is a different flow). No new backend; calls only the existing endpoint. 195 lines.
Benjamin Admin