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.
This commit is contained in:
Benjamin Admin
@@ -0,0 +1,92 @@
|
||||
# Certification Capability Hypotheses — CAPABILITY-CENTRIC, shared core first.
|
||||
#
|
||||
# Proprietary norms (ISO/TISAX/PCI…) are NOT ingested. Instead each hypothesis is its own knowledge
|
||||
# object: "IF a company holds these certifications, we EXPECT this capability with some probability —
|
||||
# verification required". NOT "ISO 27001 HAS X" (Welt-2) but "ISO 27001 SUGGESTS X" (Welt-1).
|
||||
#
|
||||
# THE TRICK (reuse, not redundancy): a capability is written ONCE with `supported_by: [certs]`. Most
|
||||
# management-system capabilities (document control, incident, supplier, audit, risk, asset, access,
|
||||
# training, monitoring) recur across many certs, so ~40-60 hypotheses cover everything instead of ~300.
|
||||
# Multi-certification then merges AUTOMATICALLY (a company's inferred caps = every hypothesis whose
|
||||
# supported_by intersects its certs). capability ids match the existing transition patterns.
|
||||
#
|
||||
# `confidence.empirical` stays NULL until calibrated from REAL onboardings (observations.confirmed /
|
||||
# refuted) — never an LLM/expert score. Capabilities a cert does NOT suggest (SBOM, CVD, support period,
|
||||
# signed updates) simply have NO hypothesis -> they always stay in the delta and get asked. AI first
|
||||
# draft (~95%), expert review + customer calibration follow. No norm text reproduced. No real names.
|
||||
|
||||
hypotheses:
|
||||
# ── SHARED CORE — management-system capabilities that recur across certifications ───────────
|
||||
- {id: HYP-document_control, capability: document_and_change_control, relationship: supports, kind: shared,
|
||||
supported_by: [ISO9001, ISO13485, ISO27001, TISAX, ASPICE, IATF16949],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [document_control_procedure],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-incident_management, capability: incident_management, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX, IEC62443, ISO13485],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [incident_procedure],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-supplier_security, capability: supplier_security, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX, IEC62443],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [supplier_security_records],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-supplier_evaluation, capability: supplier_evaluation, relationship: supports, kind: shared,
|
||||
supported_by: [ISO9001, IATF16949, ISO13485],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [supplier_evaluation_records],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-access_control, capability: access_control_and_authentication, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX, IEC62443],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [access_control_policy],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-logging_monitoring, capability: security_logging_and_monitoring, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX, IEC62443],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [logging_configuration],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-asset_config, capability: asset_and_configuration_management, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX, IEC62443],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [asset_inventory],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-vuln_management, capability: technical_vulnerability_management, relationship: partially_supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX, IEC62443],
|
||||
verification_required: true, question_intent: confirm_product_scope, expected_evidence: [vulnerability_management_process],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-isms, capability: information_security_management, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [isms_scope],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-cryptography, capability: cryptography, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX, IEC62443],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [crypto_policy],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-training, capability: security_awareness_training, relationship: supports, kind: shared,
|
||||
supported_by: [ISO27001, TISAX],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [training_records],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-prototype_protection, capability: protect_prototypes, relationship: supports, kind: shared,
|
||||
supported_by: [TISAX],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [prototype_protection_policy],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-release_approval, capability: release_and_approval_process, relationship: supports, kind: shared,
|
||||
supported_by: [ISO9001, IATF16949, ISO13485],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [release_procedure],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-ce_conformity, capability: ce_conformity_assessment_and_technical_documentation, relationship: partially_supports, kind: shared,
|
||||
supported_by: [ISO9001, IATF16949],
|
||||
verification_required: true, question_intent: request_evidence, expected_evidence: [technical_documentation],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
# ── CERT-SPECIFIC — capabilities a single domain's certificate suggests ─────────────────────
|
||||
- {id: HYP-secure_dev, capability: secure_development_lifecycle, relationship: partially_supports, kind: specific,
|
||||
supported_by: [IEC62443, ASPICE],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [secure_development_policy],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-csms, capability: cybersecurity_management_system, relationship: supports, kind: specific,
|
||||
supported_by: [IEC62443],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [csms_records],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-environmental_docs, capability: environmental_management_documentation, relationship: supports, kind: specific,
|
||||
supported_by: [ISO14001],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [environmental_aspects_register],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
- {id: HYP-software_process, capability: assess_software_process_capability, relationship: supports, kind: specific,
|
||||
supported_by: [ASPICE],
|
||||
verification_required: true, question_intent: verify_existence, expected_evidence: [aspice_assessment],
|
||||
confidence: {empirical: null}, observations: {confirmed: 0, refuted: 0}}
|
||||
Reference in New Issue
Block a user