1703 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Benjamin Admin	f2d445b891	fix(ucca): Cross-Reg 0070 — beide Regelwerk-Domaenen im Router-Top-K (Known Defects 0) ... Der einzige offene Retrieval-Haertefall: eine Query mit >=2 genannten Regelwerken ("CRA und Maschinenverordnung") lieferte nur die keyword-dominante Domaene (CRA), MaschVO fiel raus. Drei zusammenwirkende Ursachen, alle behoben: 1. CodeValues-Mismatch: MaschVO heisst je Collection anders (Slice MASCHVO · gesetze MVO · ce MACHINERY/MASCHINENVO), der Catalog hatte nur ["MASCHVO","MaschVO"] → Filter fand MaschVO nur in der Slice. Jetzt alle Varianten als CodeValues. 2. Per-Collection-Truncation: der Router gab perColl=3 → searchMultiRegulation holte 3+3=6, schnitt auf 3 → konnte eine Domaene je Collection verlieren. Multi-Reg-Queries bekommen jetzt perColl = 3*len(regs). 3. Router-Score-Merge starvte die nicht-dominante Domaene. Neue balanceByRegulation() gruppiert den gemergten Pool per Regelwerk (exakter regulation_code-Match) und nimmt round-robin ueber die genannten Domaenen → jede Domaene mit Treffern ist im Top-K. Generisch ueber jede genannte Menge; Single-Domain-Pfad unveraendert. Validierung: Go-Unit (balanceByRegulation: dominante CRA verdraengt MaschVO NICHT mehr); 0070-e2e gegen dev (Retrieve() → [CRA MVO CRA MVO CRA MVO CRA MASCHINENVO] = beide Domaenen, vorher nur CRA); CB-100-Stichprobe REGR 0 (Gain-Profil unveraendert). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 15:08:18 +02:00
Benjamin_Boenisch	08086ee75f	feat: Authority Router — Advisor collection-agnostisch, KB-2026.1 live (#46)	2026-06-30 12:26:53 +00:00
Benjamin Admin	1e5aaf7103	feat(advisor): Authority Router — Advisor collection-agnostisch, KB-2026.1-Gewinn im Produktpfad ... Der Advisor fan-outete bisher selbst ueber eine feste Liste expliziter Collections (advisor-rag.ts) und umging damit das #61-Scope-Routing (das nur den Default-Pfad routet) → der gemessene +28-Retrieval-Gewinn (CB-100: 53→81, 0 Regr) kam nie beim Antwort-LLM an. Dieser Router zieht den Fan-out in die Retriever-Schicht: - SDK: LegalRAGClient.Retrieve() + POST /sdk/v1/rag/retrieve {query, top_k} — fan-outet server-seitig ueber die Broad-Authority-Base + die KB-2026.1-Slice bei inKBScope, merge+dedup, sortiert nach Authority-Score (rerankByAuthority je Collection), top-K. Index-Warmup vor dem nebenlaeufigen Fan-out (Map-Race-frei). Per-Env via RAG_ROUTER_COLLECTIONS. - admin: advisor-rag.ts ruft EINMAL /retrieve statt 6-fach expliziter Collections. Advisor ist collection-agnostisch (Vertrag Compiler→Collections→Retriever→Advisor); COMPLIANCE_COLLECTIONS/searchCollection entfernt. Validierung: Go-Unit (Router-Selektion, dedup); e2e gegen dev-Qdrant (echter Retrieve(), CB-100-Stichprobe stride 5): OLD-hit 11/20 → NEW-hit 15/20, GAIN 4 (alle DS-Guidance), REGR 0 — reproduziert den +28/0-Regr durch den Produktionscode. TS-Tests auf den Single-/retrieve-Call angepasst. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 14:13:09 +02:00
Benjamin_Boenisch	af11d21f6e	feat(ucca): Blue-Green KB-2026.1 Scope-Routing (authoritative slice) (#45)	2026-06-30 10:01:59 +00:00
Benjamin Admin	e2c74fd243	feat(ucca): Blue-Green „authoritative slice promotion" — KB-2026.1 Scope-Routing ... Additiv (KEIN CE-Ersatz): faellt eine Query in den KB-2026.1-Scope (DP/CRA/MaschVO/ NIS2/DataAct/DORA/AIAct + EDPB/DSK-Guidance), wird die hochwertige Slice-Collection `kb_2026_1_build` abgefragt; sonst bleibt der breite Default `bp_compliance_ce`. Damit werden die Guidance-Intent- + Multi-Reg-Fixes (PR #42/#43) fuer den Slice LIVE, Broad-Corpus (OWASP/NIST/ENISA/IFRS/ISO) unangetastet -> 0 Regressionen by construction. - resolveCollection(query, requested): explizit angefragte Collection unveraendert; Default-Request -> Slice bei inKBScope, sonst CE. Env RAG_KB_SCOPE_ROUTING=false = Rollback ohne Redeploy; RAG_KB_SLICE_COLLECTION ueberschreibt den Slice-Namen. - inKBScope: detectRegulations (in-Slice-Regelwerke) + DP-Guidance-Marker (edpb/dsk/wp/gl) + DP/Compliance-Topics. Bewusst NICHT die generischen Verben aus guidanceIntentSignals (sagt/laut) und NICHT enisa/bsi/nist/owasp (die liegen in CE) -> konservativ, in-scope->Slice. Validierung: Unit (Scoping + resolveCollection); dev-e2e (RUN_E2E, geroutetes Search() gegen dev): WP248/MaschVO/CRA+MaschVO -> Slice (Treffer da, fehlen in dev-ce); NIST -> CE (NIST-Treffer). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 11:49:34 +02:00
Benjamin_Boenisch	8ed99c255d	Merge pull request 'fix(api): F821-Regression (Extract-Service-Halb-Refactor) — 7 Route-Dateien' (#44) from fix/api-f821-extract-service-regression into main	2026-06-30 09:06:08 +00:00
Benjamin Admin	3389fa3e7a	fix(api): F821-Regression in 6 weiteren Route-Dateien beheben ... Gleiche Wurzel wie evidence_routes (Extract-Service-Refactor a638d0e5 ff.): Signaturen/Imports halb umgestellt → undefined names → NameError beim Aufruf. - routes.py: db-Param in get_control/update_control/review_control + EvidenceDB-Import - dsfa_routes.py: db-Param in create_dsfa + HTTPException/text-Import - dashboard_routes.py: timezone-Import - canonical_control_routes.py: logger-Definition - ai_routes.py: timezone in den lokalen datetime-Imports - vvt_routes.py: HTTPException-Import Verifiziert: ruff F821 0 über das gesamte compliance/api/, alle 6 py_compile, 294 Tests grün auf den betroffenen Modulen (die 2 dsfa-invalid-status/risk-Failures sind vorbestehend = 400-vs-422, unabhängig von diesem Fix). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 10:51:00 +02:00
Benjamin Admin	79abf23ea8	fix(api): evidence_routes F821-Regression beheben (Extract-Service-Halb-Refactor) ... a638d0e5 ("extract EvidenceService") stellte Signaturen auf service=Depends um, ließ aber Bodies + Imports auf dem alten Stand → 43 F821 (NameError zur Laufzeit). - gelöschte stdlib-Imports restauriert (os/json/hashlib/uuid/datetime/timedelta) - db: Session = Depends(get_db) an den betroffenen Endpoints restauriert - translate_domain_errors + _update_risks_impl (=evidence_service._update_risks) importiert - unerreichbaren toten Block (alte get_ci_evidence_status-Impl nach dem return) entfernt - dsms_cid=None no-op in create/review/reject (DSMS-Commit-Copy-Paste) Verifiziert: ruff F821 0, py_compile, test_evidence_routes.py 35 passed. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 10:19:28 +02:00
Benjamin Admin	d5925e57af	feat(ai-sdk): pin accepted proposer decisions into the GT gate (P3) ... When a human accepts a proposer proposal, an AcceptedPin records a machine-scoped invariant — a pattern MUST fire (coverage/vocab→tag) or must NOT fire (dedup/framing) — that a test re-checks on every run. This makes the library's growth COMPOUND into the gate instead of eroding it: a change that re-introduces a dropped duplicate, un-gates a foreign pattern, or removes a coverage hazard breaks a pin and fails CI. One boolean covers all four proposal types. Seeded testdata/accepted_pins_warewashing.json with the accepted P1 supersessions (HP016/HP018/HP013 must NOT fire; their clean equivalents HP2201/HP144 must fire). TestWarewashing_AcceptedPins re-checks 5/5 against the live engine output; GenerateDedupPin turns an accepted dedup verdict into its pin. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 09:42:31 +02:00
Benjamin Admin	1877829b1d	Merge remote-tracking branch 'gitea/main' into reconcile-dev	2026-06-30 09:04:58 +02:00
Benjamin_Boenisch	866889b453	Merge pull request 'feat(ucca): Multi-Regulation-Retrieval (Cross-Regulation-Fragen)' (#43) from fix/multi-regulation-retrieval into main	2026-06-30 06:46:21 +00:00
Benjamin Admin	9760dca443	feat(ucca): Multi-Regulation-Retrieval für Cross-Regulation-Fragen ... Nennt eine Query EXPLIZIT >=2 Regelwerke ("Wie greifen CRA und Maschinen- verordnung ineinander?"), retrievt searchInternal pro Regelwerk separat (regulation_code/regulation_id-Filter) und merged — damit BEIDE Domänen im Prompt landen statt nur der keyword-dominanten. Generisch (Query->Regelwerke, KEINE doc-spezifische Logik), gegated auf >=2 erkannte Regelwerke; sonst unveränderter Single-Domain-Pfad. Behebt GQ-0070: vorher CRA x8 / null MaschVO -> Modell halluzinierte MaschVO=2019/2144 + falsche "CRA ausgenommen"-Konklusion. Nachher CRA + MaschVO im Prompt -> korrekt "beide gleichzeitig anwendbar" + Art. 20(9) Konformitätsvermutung, gegroundet. Validierung (Build-Collection, echtes SearchCollection): - Unit: detectRegulations-Scoping (>=2 -> multi, 1/0 -> single) - 5 Cross-Reg-Fälle (0070 + DSGVO+TDDDG/CRA+NIS2/DORA+NIS2/AI Act+DSGVO): beide Regelwerke in Top-8 - CB-100 Freeze-Regression: NUR GQ-0070 + GQ-0095 geändert (beide echte Cross-Reg, beide verbessert), 98/100 byte-identisch - 10 Hard Cases: 9 Single-Domain unverändert, 0070 behält CRA Rang 1 Filter erweitert auf regulation_id UND regulation_code (rückwärtskompatibel, aktiviert die re-ingestierte Build-Collection). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 08:18:06 +02:00
Benjamin_Boenisch	e5e7b825af	Merge pull request 'fix(ucca): Guidance-Intent für direkt benannte WP/GL-Dokumente' (#42) from fix/legal-rag-guidance-intent into main	2026-06-29 18:42:27 +00:00
Benjamin Admin	4818fc51c2	fix(ucca): guidance-intent erkennt direkt benannte Guidance-Dokumente ... queryWantsGuidance verfehlte rein dokument-namige Fragen ("Welche Kriterien nennt WP248 ...", "Was sagt GL 07/2020 ..."): guidanceIntentSignals enthielt zwar Herausgeber (edpb/dsk/enisa) und Verben (empfiehlt/laut), aber keine Working-Paper-/Guideline-Identifier. Dadurch loeste der Authority-Lift nicht aus -> binding_law (bzw. im homogenen Korpus sogar off-domain MaschVO/CRA) verdraengte die Guidance aus den Top-K. Fix: WP2xx / GL 0x / "working paper" als Guidance-Signal ergaenzt. Generisch ueber alle WP-/GL-Dokumente, KEINE doc-spezifische Regel (Query->Intent, nicht Query->konkretes Dokument). Validierung (homogener Build-Korpus, bge-m3 + Qdrant Cosine): - 10 Hard Cases: 8/10 -> 10/10 (WP248/WP260 zurueck in Top-8) - ComplianceBench-100: 0/100 Norm-Fragen veraendert (Freeze-Regression gruen), 18/18 Guidance-Intent-Fragen verbessert (binding -> korrekte Guidance-Klasse) - Hybrid == Dense (Keyword-RRF war NICHT die Ursache, der Lift-Gate war es) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-29 20:22:27 +02:00
pilotadmin	f0da86ca19	Merge pull request 'feat(onboarding): advisor responsiveness — moving headline + auto-recompute' (#54) from feat/advisor-ux-responsiveness into main	2026-06-28 19:31:20 +02:00
Benjamin Admin	867f8c3854	feat(onboarding): make the advisor visibly responsive — headline leads with the moving number + auto-recompute ... Testing surfaced that toggling certifications appeared to "do nothing": the headline led with the TOTAL requirement count (constant per target, e.g. 17 for CRA), and the page only recomputed on an explicit button click. Both fixed: - engine.py headline now leads with the number that actually moves: "11 von 17 Anforderungen offen · 6 wahrscheinlich (Zertifikate) · 5 zu klären" (was "17 Anforderungen erkannt · …"). Keeps the "automatisch erkannt (Intake)" substring. - frontend auto-recomputes on certifications / target / scanner-signal change (no button needed). Now ISO27001 alone -> "13 von 17 offen · 4 wahrscheinlich"; + ISO9001+TISAX+IEC62443 -> "11 von 17 offen · 6 wahrscheinlich". (Domain truth stays visible: CRA's product-cyber gaps barely move with management-system certs.) 28 onboarding+transition tests pass, check-loc 0.	2026-06-28 19:31:15 +02:00
pilotadmin	26a8518107	Merge pull request 'feat(onboarding): surface curated expert text + human labels' (#53) from feat/advisor-human-text into main	2026-06-28 18:47:07 +02:00
Benjamin Admin	807a7002b2	feat(onboarding): surface curated expert text + human capability labels (advisor was showing snake_case) ... 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.	2026-06-28 18:46:56 +02:00
pilotadmin	5beb5a319a	Merge pull request 'feat(admin): ETO / Onboarding-Advisor test page' (#52) from feat/onboarding-advisor-frontend into main	2026-06-28 17:12:44 +02:00
Benjamin Admin	239702fdca	feat(admin): ETO / Onboarding-Advisor test page (thin operator surface over the advisor endpoint) ... 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.	2026-06-28 17:12:40 +02:00
pilotadmin	d1a5fc7205	Merge pull request 'feat(onboarding): Observation Log — append-only JSONL calibration store (59b/c)' (#51) from feat/observation-log into main	2026-06-28 16:29:58 +02:00
Benjamin Admin	7df15010ff	feat(onboarding): Observation Log — append-only JSONL calibration store (Task 59b/c v1) ... Per the user's decision (2026-06-28): observations are CALIBRATION data for the knowledge base, NOT business data and NOT product-DB data. So they live with the other versioned knowledge artifacts as an append-only JSONL log under knowledge/observations/ — NO migration, NO DB. (A real persistence layer is only warranted once thousands of onboardings exist; not before.) - ObservationRecord = Observation + log metadata (observation_id, timestamp [caller-stamped, no hidden clock], customer_archetype [anonymised — NEVER a real name], evidence, provenance, knowledge_version). - append_observation() writes one JSON line; append-only, lines are never rewritten. A later review is a NEW line with the same observation_id; load_observations(reconcile=True) keeps the latest per id. - load_observations() reads a single .jsonl or a directory of monthly .jsonl files. - aggregate_by_hypothesis() (59c) -> per-hypothesis distribution + confidence, COMPUTED from the log (computed-not-stored); the review gate (reviewed-only) is enforced in empirical_distribution/confidence. - review_queue() -> the unreviewed worklist. Observation -> Review -> Accepted -> recompute, never Observation -> confidence++. Nothing is ever written back to a hypothesis. You can `rm` the log and recompute, `git diff` it over months, or rebuild confidence under a new policy — fully consistent with computed-not-stored and the product/knowledge data separation. Non-runtime (module + tests only, no endpoint) -> origin/main, NO dev deploy. 5 new tests (append-only, review supersession, review-gate statistics, queue, monthly-file load); 27 onboarding tests pass, mypy --strict clean (9 modules), check-loc 0. 59d (surface computed confidence at runtime) stays a later step.	2026-06-28 16:29:54 +02:00
pilotadmin	e54f3cde94	Merge pull request 'fix(onboarding): review decisions — ISO13485 + patch rationale + summary counter' (#50) from feat/review-decisions into main	2026-06-28 16:18:32 +02:00
Benjamin Admin	77459d06d6	fix(onboarding): apply hypothesis/vocabulary review decisions (ISO13485, patch-policy rationale, summary) ... Two reviewed knowledge decisions (2026-06-28) + the deferred cosmetic counter, before #59. 1. ISO13485 removed from the incident_management hypothesis. ISO 13485 CAPA / quality-safety incident handling is NOT security incident management — the mapping was too broad and would seed false hypotheses for the empirical loop. A dedicated manage_quality_and_safety_incidents capability can come later IF a target needs it; not forced now. (ISO27001/TISAX/IEC62443 keep incident_management.) 2. patch_policy_doc -> secure_signed_update_distribution stays `partial`, but the curated rationale is sharpened: "indicates update governance, does not evidence signed distribution" (a patch policy is not proof of SIGNED distribution). New optional SignalMapping.rationale field carries the curated note. (github_actions_ci -> SDL and dependency_scanning -> vuln-mgmt reviewed and APPROVED as-is.) 3. Cosmetic (folded in since we touched the file): the silent-intake summary now counts detected and indications SEPARATELY ("N automatisch erkannt, M Indikation(en)") instead of lumping partial signals into "automatisch erkannt" — consistent with the three-state model just shipped. Tests: ISO13485 no longer resolves to incident_management; summary counts split correctly. 29 onboarding tests pass, mypy --strict clean, demo runs, check-loc 0. Runtime-visible (hypothesis resolution + summary text) -> deploy + smoke.	2026-06-28 16:18:28 +02:00
pilotadmin	3202e555ab	Merge pull request 'fix(onboarding): partial != detected — indication, not auto-detect (Fix B)' (#49) from feat/partial-decouple into main	2026-06-28 16:02:55 +02:00
Benjamin Admin	978052b5a2	fix(onboarding): decouple partial/indicative signals from detected — partial no longer removes a question ... Fix B of the pre-#59 semantic correction. The Silent Pass had only TWO effective states though the data carries three: a `detected` mapping (a concrete artifact) AND a `partial` mapping (an indicative signal, e.g. a CI pipeline -> secure-development-lifecycle) both flowed through capability_ids() and were fed to the Advisor as already-present — so a weak indication silently removed a question, exactly the Welt-1/ Welt-2 transparency we want to keep. Now three distinct states: - detected -> reduces the delta immediately (auto_detected, not asked). [unchanged] - partial -> raises assumption strength but does NOT replace the question (surfaced as `indications`, the capability stays in the delta and is still asked). - requirement-> describes a target, never the present state (already handled by Fix A's kind split). Changes (data + thin wiring, no new architecture): - SilentIntakeResult.capability_ids() returns only relationship==detected; new indicative_capability_ids() returns the partial ones. - advisor_start() gains indicative_capabilities (NOT fed into the profile) and surfaces result.indications = indicative ∩ required − auto_detected. - AdvisorResult / AdvisorResponse gain `indications` (additive, contract-safe); the service passes the indicative ids through. Tests: a partial CI signal is indicative-not-detected and does NOT shrink the delta; end-to-end it appears in `indications`, not `auto_detected`, and the gap is still asked. 28 onboarding tests pass, mypy --strict clean on the onboarding modules, demo runs, check-loc 0. Runtime effect -> deploy + smoke.	2026-06-28 16:02:35 +02:00
pilotadmin	19931208a9	Merge pull request 'fix(onboarding): observation vs requirement signals — demanded ≠ present (Fix A)' (#48) from feat/signal-kind-split into main	2026-06-28 15:53:10 +02:00
Benjamin Admin	c39787ad96	fix(onboarding): separate observation vs requirement signals — a demanded SBOM is not a present SBOM ... Semantic correction of the knowledge base BEFORE the empirical loop (#59) is built — otherwise the Observation Store would learn from already-misclassified signals. The Silent Pass conflated two kinds of signal into one: an OBSERVATION ("I saw an SBOM in the repo") and a REQUIREMENT ("a tender DEMANDS an SBOM"). They were aliased to the same canonical id, so a tender clause read as "SBOM already present" and suppressed the very question that should have been asked. Fix — make the kind explicit and authoritative (no new architecture, data + thin wiring): - `kind` ∈ {observation, requirement} on ProducedSignal (producer may declare) and on the canonical SignalVocabularyEntry (AUTHORITATIVE — a mislabelled producer cannot collapse the two). - Vocabulary split: sbom_file_found → sbom_present (obs) + sbom_required (req); security_txt_or_cvd_policy → cvd_policy_present (obs) + psirt_required (req); add signed_updates_required. requirement signals are intentionally UNMAPPED in intake_signal_map (they describe a target, not state). - silent_intake() consumes ONLY kind==observation; requirement signals are preserved in `requirements_seen` (visible/auditable) but NEVER become a detected capability. - normalize_signals() stamps the vocabulary's kind onto every IntakeSignal; unknown ids still pass through. This is the same Observation-vs-Requirement split the Requirements Verification Platform rests on: observations are reality, requirements are targets, and their comparison is the delta. A tender / OEM spec / law now produces requirement signals; scanners / repos / documents produce observation signals. Tests: rewrote the two test_signal_producer cases that previously ASSERTED the bug (tender == repo) to pin the correct split; regression — `requires_sbom` yields no capability + stays in requirements_seen while `cyclonedx_found` still detects sbom_creation; endpoint-level regression that a tender requirement does not auto-detect and the gap stays asked; vocabulary-kind-overrides-mislabelled-producer. 25 onboarding tests pass, mypy --strict clean, demo runs, check-loc 0. Runtime effect → deploy + smoke. (Fix A; partial-vs- detected decoupling follows as Fix B before #59.)	2026-06-28 15:52:50 +02:00
pilotadmin	b5b6cdddb3	Merge pull request 'POST /onboarding/advisor-start — expose the Advisor at runtime (#58)' (#47) from feat/onboarding-advisor-endpoint into main	2026-06-28 15:14:05 +02:00
Benjamin Admin	a4123ace71	feat: POST /onboarding/advisor-start — expose the Smart Onboarding Advisor at runtime (#58) ... This exposes the existing Smart Onboarding Advisor through a runtime endpoint; it does not add new reasoning logic. Tightly scoped: adapter boundary + endpoint, no big frontend, no persistence, no empirical learning, no new scanners, no LLM. POST /onboarding/advisor-start : (company + certifications + target + scanner_findings[ProducedSignal]) -> Normalizer -> Silent Knowledge Pass -> Advisor -> { silent_intake_summary, inferred_assumptions, rejected_assumptions, top_5_questions, capability_delta, top_measures, evidence_requests, completeness_summary, auto_detected, headline } GET /onboarding/targets : the supported target ids (CRA, TISAX, MDR, Environmental) compliance/services/onboarding_service.py is the app-caller: it loads the curated knowledge (hypothesis library, signal vocabulary + map, the target's required capabilities) once and calls the pure, tested orchestration (normalize_signals -> silent_intake -> advisor_start). The scanner ADAPTER boundary is the ProducedSignal format the request carries — existing scanners emit it, no new scanners. Thin handler (<30 LOC), registered in the auto-load list. No DB. Additive to the OpenAPI contract (contract test is additive-friendly; baseline regenerates on CI/py3.12). First deployable runtime feature -> dev deploy + smoke. mypy --strict clean, 22 onboarding tests pass, check-loc 0.	2026-06-28 15:14:00 +02:00
pilotadmin	3bb48f2147	Merge pull request 'Signal Producer interface + Normalizer — one signal language' (#46) from feat/silent-knowledge-pass into main	2026-06-28 14:51:08 +02:00
Benjamin Admin	c2c8f7e424	feat: Signal Producer interface + Normalizer — one signal language for all sources (before #58) ... Not scanner stubs — the scanners exist. The Silent Pass needs only their UNIFIED output. This adds the small common DATA FORMAT (not a new module/framework) the user asked for, exactly the Requirement- Source / MCAP / regulation-alias pattern: many inputs, one language. Producer A / B / C -> normalize_signals (vocabulary: id + aliases) -> canonical IntakeSignal -> Silent Pass - ProducedSignal {signal_id, source_type, confidence, evidence, provenance} = what ANY source emits (website scanner, repo scanner, PDF parser, tender parser, API, the user). - knowledge/onboarding/signal_vocabulary.yaml reduces producer dialects to a canonical signal: "SBOM present" arrives as cyclonedx_found / spdx_found / sbom_uploaded / requires_sbom (tender) — all become `sbom_file_found`. The Silent Pass cannot tell where it came from -> no per-scanner special logic, ever. - Unknown signals pass through (a new producer stays visible). confidence/evidence/provenance flow to the detected capability for the audit trail. A tender that "requires SBOM" now produces the same effect as a repo that HAS one — fits Vision V2 (Requirement Source over Regulation). Endpoint (#58) then has its final shape: POST -> Producers -> Normalizer -> Silent Pass -> Profile -> Delta -> Questions -> Roadmap. Non-runtime -> no deploy. mypy --strict clean, 14 onboarding tests pass, check-loc 0.	2026-06-28 14:49:57 +02:00
pilotadmin	b70c1b7c37	Merge pull request 'Silent Knowledge Pass — recognise before asking (Phase 0)' (#45) from feat/silent-knowledge-pass into main	2026-06-28 14:34:31 +02:00
Benjamin Admin	9c33582412	feat: Silent Knowledge Pass — recognise before asking (Phase 0, before the endpoint) ... Not the endpoint yet — the bigger knowledge lever first. The Advisor can say "I need 5 answers" but does not yet decide what it can find out by ITSELF. The Silent Knowledge Pass runs in front of the Advisor and, from signals existing scanners/parsers already produce (website, repository, documents, product data), deterministically derives capabilities the company demonstrably HAS + product facts that drive scope — so every recognised item shrinks the delta and removes a question. compliance/onboarding/silent_intake.py: silent_intake(signals, signal_map) -> detected_capabilities (+ evidence already in hand) + product_facts. The signal->conclusion map is curated DATA (knowledge/onboarding/intake_signal_map.yaml), signals are injected (scanners are upstream). Pure, deterministic, no LLM. advisor_start gains detected_capabilities (folded into the profile at HIGH confidence -> covered, not asked) and an auto_detected result + headline. The experience flips from a question wall to "we already recognised 4 capabilities, 2 product facts and have 4 pieces of evidence in hand — only these few remain". Order now: Silent Pass -> #58 endpoint/frontend -> #59 empirical loop. NOT new architecture, just an orchestration step in front. Non-runtime (no app caller) -> no deploy. 15 onboarding tests pass, mypy --strict clean, check-loc 0.	2026-06-28 14:34:27 +02:00
Benjamin Admin	23d977e26b	deploy: promote macmini staging to dev — merge live dev ai-sdk fixes (ePrivacy/§25 TDDDG, national-law subsidiarity) with +86 backend-compliance commits (Phase Ω, onboarding, hypotheses). Coordinated GO from all 4 sessions.	2026-06-28 13:57:07 +02:00
pilotadmin	88b83d4daf	Merge pull request 'Observation Model — empirical learning unit (Task 59a)' (#44) from feat/observation-model into main	2026-06-28 13:34:54 +02:00
Benjamin Admin	98d616d82b	feat: Observation Model — the empirical learning unit, defined BEFORE persistence (Task 59a) ... The learning point is not the hypothesis, it is the QUESTION — and confirmed/refuted is too coarse. "partial, only critical suppliers" or "certified but not lived" are not "wrong", they are valuable knowledge. So the chain is Hypothesis -> Question -> Observation -> (Review) -> Hypothesis, and the observation model must be defined cleanly before any store/API (else thousands of too-coarse observations get migrated later). compliance/onboarding/observations.py: - ObservationType: confirmed / partial / refuted / not_applicable / unknown (richer than binary). - Observation: {hypothesis_id, capability, question, answer (free text), observation_type, scope_note ("only critical suppliers"), evidence_uploaded, reviewed, reviewed_by}. - empirical_distribution() -> a DISTRIBUTION (confirmed 61 / partial 31 / refuted 8), not one %. - empirical_confidence() -> (confirmed + 0.5*partial) / (confirmed+partial+refuted); n.a./unknown excluded; None until calibrated. - REVIEW GATE: only reviewed observations calibrate — a raw answer never changes a hypothesis (no learning from outliers). Refactor: the hypothesis is now PURE curated knowledge — the binary observations counter and any confidence are removed from CapabilityHypothesis and the YAML; confidence is COMPUTED from the separate reviewed observation stream. Pure, mypy --strict clean. Persistence/aggregation/calibration are 59b/c/d. Non-runtime -> no deploy. 12 tests pass, check-loc 0.	2026-06-28 13:31:43 +02:00
pilotadmin	59b7006e5a	Merge pull request 'Certification Capability Hypotheses — capability-centric + empirical confidence' (#42) from feat/certification-hypotheses into main	2026-06-28 13:17:20 +02:00
Benjamin Admin	2d2cb2a244	feat: Certification Capability Hypotheses — capability-centric library + empirical confidence ... The bottleneck is knowledge, not the endpoint. This builds the knowledge the Onboarding Advisor needs, restructured per the user's key insight: NOT "ISO27001 -> 30 capabilities" but each hypothesis as its own object "capability -> supported_by: [certs]". A capability is written ONCE with all supporting certs, so the shared management-system core (document control, incident, supplier, audit, access, asset, monitoring, training, crypto, release, risk) covers most certifications with ~18 hypotheses instead of ~300 — and multi-certification merges AUTOMATICALLY (a company's inferred caps = every hypothesis whose supported_by intersects its certs). Welt-1 throughout: "IF cert present, EXPECT capability (verification required)", never "erfüllt". Capabilities NO cert suggests (SBOM, signed updates, CVD, support period) have no hypothesis -> they stay in the delta and get asked. confidence is EMPIRICAL: computed from real-onboarding observations (confirmed/(confirmed+refuted)), None until calibrated — never an LLM/expert score (record_observation + empirical_confidence). The long-term moat: knowledge that learns from reality, not from a norm. compliance/onboarding/hypotheses.py (resolve_for_certifications / inferred_hypotheses / empirical_ confidence / record_observation) feeds the existing advisor_start unchanged; the demo now runs on the curated library. Pure, mypy --strict clean, library is DATA (no norm text, no real names). Non-runtime -> no deploy. 12 tests pass, check-loc 0.	2026-06-28 13:16:45 +02:00
pilotadmin	02c9fdb18e	Merge pull request 'Smart Onboarding Advisor (ADR-012) — orchestration over existing engines' (#41) from feat/smart-onboarding-advisor into main	2026-06-28 12:46:23 +02:00
Benjamin Admin	3ba90f49cf	feat: Smart Onboarding Advisor — make the knowledge usable in onboarding (ADR-012) ... The user-named "right next runtime step": stop building knowledge, start using it automatically in onboarding — no sales training, no regulation picking. compliance/onboarding/ is an ORCHESTRATOR (not a new engine) wiring Company 2A -> RS-005 -> optimization -> completeness: advisor_start(input, cert_hypotheses, target_requirements, ...) -> AdvisorResult From (company + products + certifications + target) it returns inferred_assumptions, rejected_ assumptions, next_best_questions (<=5, ranked by information_gain + leverage + unknown_high_risk + evidence_missing, each self-explaining), capability_delta, top_measures, evidence_requests, unsupported_domains, completeness_summary. apply_answer() updates the profile (delta shrinks). Welt-1 throughout: certificates REDUCE questions but satisfy nothing automatically (verification_ required); relevance(evidence,target) keeps ISO 14001 out of the CRA result. Certificate->capability hypotheses + target requirements are INJECTED (curated knowledge, outsourced; not in code). All 7 acceptance criteria pass; mypy --strict clean. First app-caller wiring the engines into a product flow — still no endpoint/persistence, so 0 runtime effect -> no deploy yet (deploys when POST /onboarding/advisor-start + frontend are wired). check-loc 0.	2026-06-28 12:45:49 +02:00
pilotadmin	009083882a	Merge pull request 'Capability Convergence Explanation + Core/Domain (Phase Omega)' (#40) from feat/capability-families-and-core-domain into main	2026-06-28 12:26:53 +02:00
Benjamin Admin	a98076196b	feat: Capability Convergence Explanation — why the registry converges + Core/Domain (Phase Ω) ... The mature step after Medical is not the next domain but understanding WHY the registry converges. Three derived views over existing data (no ML, no new architecture): 1. Why converge? — a domain matrix per cross-domain MCAP + a curated REASON (the moat: not "MCAP-X exists" but "why MCAP-X must exist": software product / supply chain / product operation / universal process). 2. Capability Families — ~75 MCAPs collapse to ~15 curated families (knowledge/capability_families/ families.yaml), each with the reason it is universal or domain-specific. 3. Core vs Domain — a COMPUTED property (not a new class): Core recurs across >=2 independent domains AND source types; Domain stays in one. Medical made it obvious (new medical caps are nearly all Domain; update/SBOM/access/logging are Core). Non-runtime -> no deploy. 4 tests pass, check-loc 0.	2026-06-28 12:26:22 +02:00
pilotadmin	afe5a98474	Merge pull request 'Medical stress test + Missing Convergence report (Phase Omega #3)' (#39) from feat/medical-stress-test-and-missing-convergence into main	2026-06-28 12:10:38 +02:00
Benjamin Admin	80f2e2f619	feat: Medical stress test (safety+security coupled) + Missing Convergence report (Phase Ω #3) ... Medical before Payment: the harder scientific test (safety AND security coupled, full lifecycle, deep risk/evidence demands). ISO 13485 runs through the SAME engine as ISO 27001 -> CRA, only new data, 0 runtime. The key result: IEC 81001-5-1 (health-software security) pulls in the SAME security MCAPs as the CRA, so Medical REUSES cyber capabilities (the safety/security coupling appears as capability reuse) while adding 7 genuinely new medical caps (clinical evaluation, software safety classification, ISO 14971 risk file, benefit-risk). rejected_assumptions intact. Effect on the convergence core: secure_signed_update_distribution 18 -> 24 and technical_vulnerability_management 17 -> 23, now spanning 3 domains (cyber + industrial + medical) — the core visibly GROWS, exactly the convergence signal. New 5th report: MISSING CONVERGENCE — deterministic (no ML) token-cluster detector for potential structural duplications: a name token shared by >=3 MCAPs across >=2 distinct sources is flagged for EXPERT REVIEW (never auto-merged). Surfaces e.g. the `risk` cluster (6 risk MCAPs across 6 sources) and `security`/`software`; single-source decompositions are filtered out. Complements Suspicious by looking at cross-source duplication, not single MCAPs. Also records the durable modelling rule extracted from the frequency fix: evidence is attributed to its ORIGIN; its value against a target is computed later (relevance(evidence,target)). Ledger now 8 sources, Architecture Stability 8/8 = 100%. Non-runtime -> no deploy. 29 tests pass, check-loc 0.	2026-06-28 12:09:52 +02:00
pilotadmin	897e9464a7	Merge pull request 'Cross-Domain MCAP Convergence Analysis (Phase Omega pause)' (#38) from feat/mcap-convergence-analysis into main	2026-06-28 11:48:30 +02:00
Benjamin Admin	c160bb8291	feat: Cross-Domain MCAP Convergence Analysis — which capabilities carry the system (Phase Ω pause) ... After Automotive, pause on domains and ask the deeper question: not "which MCAPs occur most often?" (frequency deceives) but "which MCAPs CARRY the largest part of the system?". A deterministic MCAP Impact Score (no AI) aggregates over the EXISTING data only: Impact = distinct Sources + Target Types + Domains + Journeys + Regulatory + Business Leverage Critically anti-frequency-deception: a `likely_covered` cap is attributed to its source CERT (one source), not to every target regulation — otherwise generic management caps win on raw frequency. With that fix the Core surfaces the true cross-cutting nodes: secure_signed_update_distribution (18), technical_vulnerability_management (17), access_control, incident_management, sbom_creation, product_cyber_risk_assessment — exactly the bridges the user predicted; the high-frequency single- domain environmental management caps correctly drop out. Four reports, pure aggregation (no runtime, no new architecture): Core (highest impact), Emerging (>=2 domains), Isolated (1 source/journey — specialised or convergence-not-yet-seen), Suspicious (too coarse: generic verbs; too fine: hyper-specific isolated names) — an abstraction-level review tool for domain experts. 11/62 caps already reach impact >=8; the method is ready to reveal whether a 30-50 MCAP core forms as Medical/Payment arrive. Non-runtime -> no deploy. 5 tests pass, check-loc 0.	2026-06-28 11:48:04 +02:00
pilotadmin	a2332fb13d	Merge pull request 'Automotive convergence stress test (Phase Omega #2)' (#37) from feat/automotive-convergence-stress-test into main	2026-06-28 11:31:03 +02:00
Benjamin Admin	90c3fe16b5	feat: Automotive convergence stress test — same capability from many sources (Phase Ω #2) ... Not another domain to prove agnosticism (Environmental did that) but a DIFFERENT property: can the SAME capability be fed by many overlapping Requirement Sources at once without the model becoming unstable? Realistic setup — a supplier with ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS developing an ECU for OEM X. Seven sources (CRA, UNECE R155/CSMS, R156/SUMS, IATF, TISAX, ASPICE, OEM X) with deliberate overlap, run through the SAME engine (0 runtime code, data only). Three new measurements (user-requested): - Capability Convergence: technical_vulnerability_management = 4 sources across 3 source TYPES (regulation + certification + contract); secure_signed_update_distribution = 4 sources. The overlap is where the economic value lives ("one capability replaces five evidence worlds"). - Existing-vs-New: 13/27 required caps reuse existing cyber/environmental MCAPs (48%) -> the registry is starting to converge; the automotive-specific rest (CSMS/SUMS/ASPICE/functional safety) is expectedly new (a maturity hint, not an architecture break). - Business Leverage: a convergent capability satisfies N regulations AND unlocks the OEM market — more convincing to a GF than "satisfies five laws". (Regulatory Leverage counts regulations; Business Leverage counts regulations + markets/customers.) Ledger gains the automotive row (0/0, 14 new types, data_only); stability stays 7/7 = 100%. The verdict recommends the user's next step: NOT a new domain but PAUSE and analyse the registry for the cross-domain high-convergence core MCAPs. Non-runtime -> no deploy. 12 tests pass, check-loc 0.	2026-06-28 11:30:30 +02:00
pilotadmin	e0d9816c99	Merge pull request 'Environmental stress test — architecture works outside cyber (Phase Omega)' (#36) from feat/environmental-stress-test into main	2026-06-28 11:10:36 +02:00