Benjamin Admin
98d616d82b
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.
77 lines
6.4 KiB
YAML
77 lines
6.4 KiB
YAML
# 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 is NOT stored on the hypothesis — it is COMPUTED from a SEPARATE, reviewed observation
|
|
# stream (observations.py): each answer is a richer Observation (confirmed/partial/refuted/n.a./unknown
|
|
# + scope note), and a raw answer NEVER changes a hypothesis directly (review gate). 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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|
|
# ── 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]}
|
|
- {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]}
|
|
- {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]}
|
|
- {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]}
|