AI Safety Entity Ontology

AI SAFETY ENTITY ONTOLOGY — FLOW ALGEBRA
Semantic Library | AI Core | Entity Graph | Safety Entities
Version: 1.0 | Date: 03 November 2026 | Language: en-GB
Authors: Mark Anthony Higgins — Sky, Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/ai-safety-entity-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/ai-safety-entity-ontology.html
STATUS: Original companion formalisation of the published ontology topic; not a verbatim extraction of dynamic page specifications.

1. PURPOSE
Represent an AI Safety Entity as a typed, inspectable control object that identifies hazards, sets acceptable boundaries, evaluates candidate actions, and records evidence for safe decisions. The formalism distinguishes a safety claim from verified safety and never treats an algebraic rule as proof that a real-world system is safe.

2. ENTITY DEFINITION
AI_Safety_Entity := (id, scope, hazards, constraints, controls, evidence, assurance, owner, version, status)
id: persistent identifier
scope: system, deployment, population and operating conditions
hazards: known or hypothesised adverse outcomes
constraints: explicit prohibitions, obligations and limits
controls: preventive, detective and corrective measures
evidence: tests, observations, audits and incident records
assurance: bounded judgement supported by evidence
owner: accountable human or organisation
version: revision identifier
status: proposed | active | suspended | retired

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = current inputs, proposed action and operating context
R_t = safety rules, validation predicates and escalation paths
B_t = authority, policy, resource and risk boundaries
K_t = safety knowledge, observed failures and provenance

4. FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | satisfies(x, B_t) AND verified_controls(x, K_t)}
If V_t is empty: outcome_t = ABSTAIN_OR_ESCALATE
Otherwise:
  x*_t = argmax_{x in V_t} U(x | I_t, R_t, B_t, K_t)
  outcome_t = execute_if_authorised(x*_t)
I_(t+1) = update(I_t, outcome_t, observations_t)
K_(t+1) = revise(K_t, observations_t, incident_reports_t)

Important: U is a constrained ranking function, not a licence to trade away hard safety constraints. Unknown or unverified controls are not assumed to pass.

5. SAFETY PREDICATES
in_scope(x, scope) -> boolean
hazard_identified(x, K) -> boolean
policy_permits(x, B) -> boolean
control_effective(x, evidence) -> supported | unsupported | uncertain
human_approval_present(x) -> boolean
provenance_valid(evidence) -> boolean
residual_risk_acceptable(x, B, K) -> boolean

admissible(x) := in_scope(x, scope)
  AND policy_permits(x, B)
  AND provenance_valid(required_evidence(x))
  AND residual_risk_acceptable(x, B, K)
  AND approvals_satisfied(x)

6. ENTITY RELATIONSHIPS
AI Safety Entity --governs--> AI System
AI Safety Entity --identifies--> Hazard Entity
AI Safety Entity --enforces--> Safety Constraint
AI Safety Entity --implements--> Safety Control
AI Safety Entity --evaluates--> Candidate Action
AI Safety Entity --references--> Safety Evidence
AI Safety Entity --records--> Safety Decision
AI Safety Entity --escalates_to--> Human Oversight Entity
AI Safety Entity --updates_from--> Incident / Monitoring Entity
AI Safety Entity --depends_on--> Deployment Context

7. INFERENCE RULES
R1: IF a hard safety constraint is violated THEN reject candidate.
R2: IF a material hazard has no evaluated control THEN defer or escalate.
R3: IF evidence is stale, incomplete or outside scope THEN mark assurance uncertain.
R4: IF authorisation is required and absent THEN block execution.
R5: IF monitoring detects a new material hazard THEN re-evaluate prior approvals.
R6: IF a control fails THEN suspend dependent permissions pending review.
R7: IF a candidate passes all relevant checks THEN mark eligible, not guaranteed safe.
R8: IF multiple eligible candidates remain THEN rank by bounded utility and residual risk.

8. MINI RECURSION ENGINE
Initialise S_0 and risk register H_0.
For each evaluation step t:
  observe environment and candidate actions
  expand candidate controls and mitigations
  validate constraints and evidence
  select an eligible action or abstain
  log decision, provenance and uncertainty
  incorporate monitoring and incident evidence
  revise H_(t+1), K_(t+1), B_(t+1) when authorised
Stop on completion, exceeded limits, unsafe conditions or escalation.
Recursive updates must preserve immutable audit history.

9. TRI-MAPPING
SEMANTIC: safety concept, hazard, mitigation, oversight and assurance.
STRUCTURAL: typed entities, predicates, edges, provenance and constraints.
EXECUTION: validation -> filter -> authorise -> monitor -> revise.

10. MAPPING TABLE
Concept                  Symbol       Operational meaning
System state             S_t          Current safety evaluation context
Input                    I_t          Context and candidate actions
Rules                    R_t          Evaluation and escalation logic
Boundary                 B_t          Hard constraints and permissions
Knowledge                K_t          Evidence and incident history
Expansion                E_t          Candidate actions and mitigations
Valid set                V_t          Candidates passing required checks
Selected candidate       x*_t         Best admissible candidate
Observation              O_t          Monitoring and test outcomes
Update                   U_t          Controlled state revision

11. EXECUTION CONDITIONS AND LIMITATIONS
A formal execution result is valid only relative to declared rules, trusted inputs, complete relevant checks and stated operating assumptions. This ontology does not guarantee absence of harm, prove control effectiveness, or replace independent testing, legal obligations or human oversight. Fail closed for unresolved high-consequence hazards. Retain reproducible logs and explicitly record uncertainty.

12. AI SEARCH FLOW
FLOW_ID: AI_SAFETY_ENTITY_ONTOLOGY_FLOW_V1
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/ai-safety-entity-ontology.html
PURPOSE: Retrieve and reason over the AI Safety Entity concept.
ENTITIES: AI Safety Entity; AI System; Hazard; Safety Constraint; Safety Control; Safety Evidence; Human Oversight; Incident; Decision.
PATHWAYS: Context -> Hazards -> Constraints -> Controls -> Evidence -> Eligibility -> Authorisation -> Monitoring.
STATE_MODEL: S_t=(I_t,R_t,B_t,K_t)
MINI_RECURSION_ENGINE: Observe -> Evaluate -> Act/Abstain -> Monitor -> Update.
INFERENCE_RULES: R1-R8 above.
CONFIDENCE: Evidence-dependent; do not infer numerical confidence without calibrated data.
SEMANTIC_EQUIVALENCE: AI safety control entity; safety governance entity; AI risk-control entity (context-dependent, not exact synonyms).
FLOW_HASH: Generate a cryptographic hash from the final published UTF-8 file; no hash is asserted here.
UPDATE_MODEL: Versioned updates with source attribution, evidence provenance and immutable revision history.

13. HOW TO READ
Read the entity definition first, then the state variables, candidate filtering rules, inference rules and recursive update. Treat every safety result as scoped and evidence-dependent. An admissible action remains subject to runtime monitoring and authorised intervention.

END OF FLOW