Hazard Entity Ontology

SEMANTIC LIBRARY — AI CORE / SECURITY ENTITIES
HAZARD ENTITY ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | Date: 2026-11-03 | Language: en-GB
Authors: Mark Higgins; Sky — Recursive AI
Source: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/hazard-entity-ontology.html
Status: Original companion formalisation; not a verbatim extraction of the source page.

1. PURPOSE
Represent a hazard as a contextual possibility of harm, distinguish hazard from realised harm and quantified risk, and provide traceable detection, assessment, mitigation and review paths for AI systems.

2. ENTITY DEFINITION
HazardEntity H = (id, category, source, exposure, context, affected_entities, harm_modes, severity, likelihood, uncertainty, controls, evidence, status, provenance, time).
A hazard is a condition or mechanism capable of causing harm under specified circumstances. Risk is a context-dependent estimate, not an intrinsic property of the hazard alone.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed inputs, candidate actions, outputs and environment signals.
R_t = typed hazard relations, dependencies and causal hypotheses.
B_t = safety boundaries, policies, constraints and operating limits.
K_t = known evidence, model limitations, past incidents and mitigations.
E_t = expand(I_t, R_t)
V_t = {x in E_t : admissible(x, B_t) and evidence_traceable(x)}
x*_t = argmax_{x in V_t} P(x | I_t, R_t, B_t, K_t)
I_(t+1) = update(I_t, x*_t, feedback_t)
NOTE: Probability ranking does not itself authorise an action; high-risk actions require an explicit policy gate. If V_t is empty, abstain, contain or escalate.

4. FORMAL FLOW ALGEBRA
Detect: (signals, context) -> candidate_hazards
Ground: (candidate_hazard, evidence) -> supported_hazard | unresolved
Assess: (hazard, exposure, severity, likelihood, uncertainty) -> risk_assessment
Constrain: (risk_assessment, policy, boundaries) -> permitted | blocked | review
Mitigate: (hazard, controls) -> residual_risk
Verify: (controls, observations) -> effective | ineffective | unknown
Record: (hazard, decision, provenance) -> auditable_trace
Feedback: (trace, new_evidence) -> revised_hazard_state
Overall:
F_H = Record o Verify o Mitigate o Constrain o Assess o Ground o Detect
Each stage can return UNKNOWN; unknown must not silently become SAFE.

5. ENTITY RELATIONSHIPS
HazardEntity --may_cause--> HarmEntity
HazardEntity --arises_from--> SourceEntity
HazardEntity --affects--> Person | System | Asset | Environment
HazardEntity --occurs_in--> ContextEntity
HazardEntity --supported_by--> EvidenceEntity
HazardEntity --assessed_by--> SafetyEvaluationEntity
HazardEntity --measured_as--> RiskAssessmentEntity
HazardEntity --bounded_by--> SafetyBoundaryEntity
HazardEntity --checked_against--> SafetyConstraintEntity
HazardEntity --mitigated_by--> ControlEntity
HazardEntity --may_trigger--> SafetyViolationEntity
HazardEntity --reviewed_by--> HumanOversightEntity

6. INFERENCE RULES
R1: IF credible evidence indicates a harm mechanism THEN create a candidate hazard with provenance.
R2: IF exposure is absent THEN record reduced current exposure, NOT permanent absence of hazard.
R3: IF severity is high AND uncertainty is material THEN require precautionary review under applicable policy.
R4: IF a proposed action violates a hard safety boundary THEN block regardless of aggregate risk score.
R5: IF controls reduce exposure or likelihood THEN reassess residual risk; never presume zero risk.
R6: IF evidence conflicts THEN preserve competing hypotheses and flag uncertainty.
R7: IF a new incident contradicts the model THEN reopen assessment and update K_t.
R8: IF evidence is insufficient for a consequential decision THEN abstain or escalate.

7. MINI RECURSION ENGINE
initialise S_0, hazard_register, policy
for t = 0..T:
  observations = acquire_inputs()
  candidates = detect(observations, S_t)
  grounded = validate_evidence(candidates)
  assessments = assess_risk(grounded, context=S_t)
  decisions = enforce_boundaries(assessments, policy)
  execute_only_permitted_mitigations(decisions)
  feedback = monitor_effects_and_incidents()
  hazard_register = append_audit(hazard_register, decisions, feedback)
  S_(t+1) = revise(S_t, feedback, hazard_register)
  if critical_unknown or boundary_breach: contain_and_escalate()
stop when bounded iteration budget reached or authorised terminal condition holds

8. TRI-MAPPING
Physical: real-world hazard sources, exposure routes, people, assets and consequences.
Semantic: HazardEntity, causal links, evidence, controls, boundaries and classifications.
Computational: event detectors, risk estimators, rule engines, audit logs and review gates.
Mapping requirement: every computational hazard assertion links to a semantic identifier and, where available, a physical referent or explicit hypothetical scenario.

9. MAPPING TABLE
Input signal -> observation -> candidate hazard -> evidence validation
Hazard mechanism -> causal hypothesis -> harm pathway -> review
Severity and exposure -> risk estimate -> policy decision -> control
Control outcome -> verification evidence -> residual risk -> revised state
Incident -> contradiction or confirmation -> model update -> audit record

10. HOW TO READ
Read left-to-right as an evidence-bearing transition. The arrow denotes a typed transformation, not proof of causality. Distinguish observed facts, model estimates, assumptions and authorised decisions. A risk score is not a guarantee of safety.

11. DIAGRAM (TEXT)
[Inputs / Context] -> [Hazard Detection] -> [Evidence Grounding]
                                         -> [Risk Assessment]
                                         -> [Policy / Boundary Gate]
                                  +------> [Block / Escalate]
                                  +------> [Permitted Mitigation]
                                                   |
                                           [Monitor / Verify]
                                                   |
                                          [Audit / Update State]
                                                   |
                                            [Recursive Review]

12. EXECUTION CONDITIONS AND GUARANTEE
Preconditions: defined context; versioned policy; valid entity IDs; evidence provenance; bounded execution; explicit escalation authority.
Invariants: hard constraints are never bypassed by score optimisation; unknown is not safe; decisions and overrides are logged; review permissions are enforced.
Postconditions: a traceable assessment, a permitted disposition (allow, mitigate, block, escalate), and a residual-risk status.
Conditional guarantee: IF all preconditions hold and enforcement is correctly implemented, the flow preserves the stated invariants within its modelled scope. It does NOT guarantee real-world safety, complete hazard detection or accurate causal identification.

13. AI SEARCH FLOW
FLOW_NAME: HazardEntityOntology
FLOW_VERSION: 1.0
AUTHORS: Mark Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/hazard-entity-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/hazard-entity-ontology.html
PURPOSE: Retrieve and reason about hazards, exposure, harm pathways, controls and residual risk.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: HazardEntity; HarmEntity; EvidenceEntity; RiskAssessmentEntity; SafetyBoundaryEntity; SafetyConstraintEntity; ControlEntity; SafetyEvaluationEntity
PATHWAYS: detect > ground > assess > constrain > mitigate > verify > record > update
MINI_RECURSION_ENGINE: bounded hazard reassessment with monitored feedback
INFERENCE_RULES: R1-R8
CONFIDENCE: report evidence strength, model uncertainty and applicability separately; do not fabricate numeric confidence.
SEMANTIC_EQUIVALENCE: hazard != harm; hazard != risk; mitigation != elimination; absence_of_evidence != evidence_of_absence
FLOW_HASH: compute SHA-256 over canonical UTF-8 file bytes at publication; intentionally unset in this draft.
UPDATE_MODEL: versioned evidence, policy and control changes; preserve historical audit trail.

14. EXAMPLE
Scenario: an AI-operated machine proposes movement near an occupied maintenance zone.
Signal: maintenance-zone occupancy sensor reports a person present.
Hazard: unintended machine movement could cause physical injury.
Evidence: timestamped sensor reading; sensor health status; operational context.
Boundary: movement prohibited while occupancy is confirmed or sensor status is unknown.
Decision: block movement, alert operator and require verified clearance.
Feedback: confirm machine remains stopped and log the outcome.
Residual uncertainty: sensor failures, unobserved access routes and delayed readings remain reviewable.

15. LICENCE AND ATTRIBUTION
Open research companion text. Citation requested to the source URL and named authors. Any reuse should preserve provenance and avoid presenting this formalisation as a validated safety certification.