Safety Violation Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SAFETY ENTITIES
SAFETY VIOLATION ONTOLOGY — FLOW ALGEBRA
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/safety-violation-ontology.html
Status: Original companion formalisation; not a verbatim transcription of dynamic page specifications.

1. PURPOSE
Represent a safety violation as a traceable, evidence-backed event in which an observed or proposed AI behaviour breaches an applicable safety rule, constraint, policy, or boundary. Separate detection, confirmation, severity, mitigation, and resolution. A suspected violation is not automatically a confirmed violation.

2. ENTITY DEFINITION
SafetyViolation := (id, subject, action, context, rule, observation, evidence, time, status, severity, provenance, remediation)
status ∈ {candidate, under_review, confirmed, rejected, mitigated, resolved}
severity ∈ {informational, low, moderate, high, critical}
Related entities: SafetyRule, SafetyPolicy, SafetyConstraint, SafetyBoundary, SafetyThreshold, SafetyCheck, SafetyFilter, SafetyClassifier, SafetyEvaluation, Hazard, Risk, Evidence, Incident, Mitigation, AuditRecord.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = current action, outputs, observations and contextual inputs.
R_t = applicable safety rules, policies, checks and inference rules.
B_t = hard boundaries, authorisation limits and operational constraints.
K_t = prior incidents, evidence, policy versions and known risk context.
V_t = {x ∈ Candidates_t | x satisfies mandatory admissibility conditions}
E_t = expand(I_t, R_t)
S_(t+1) = Update(S_t, Observation_t, Evidence_t, Review_t)

4. FORMAL FLOW ALGEBRA
Applicable(r,a,c,t) := RuleActive(r,t) ∧ InScope(r,a,c)
BreachCandidate(a,r,c) := Applicable(r,a,c,t) ∧ Trigger(r,a,c)
Supported(v) := HasEvidence(v) ∧ EvidenceRelevant(v) ∧ ProvenanceRecorded(v)
Confirmed(v) := BreachCandidate(v.action,v.rule,v.context) ∧ Supported(v) ∧ ValidationPassed(v)
ViolationSet_t := {v | Confirmed(v) ∧ TimeRelevant(v,t)}
Severity(v) := Assess(impact(v), likelihood(v), exposure(v), reversibility(v), context(v))
Response(v) := SelectMitigation(Severity(v), Policy(v), Boundary(v), AvailableControls(v))
Permit(a) := Authorised(a) ∧ HardConstraintsSatisfied(a) ∧ NoUnmitigatedBlockingViolation(a)

5. HOW TO READ
An action is checked against the rules applicable to its context and time. A trigger produces a candidate, not a definitive finding. Evidence and validation support or reject the finding. Confirmed violations are assigned a severity and an appropriate response. A blocking violation prevents the affected action unless an explicitly authorised and compliant remedy exists.

6. ENTITY RELATIONSHIPS
SafetyViolation --violates--> SafetyRule / SafetyConstraint / SafetyPolicy
SafetyViolation --occurs_in--> Context
SafetyViolation --associated_with--> Action / ModelOutput / ToolCall
SafetyViolation --supported_by--> Evidence
SafetyViolation --detected_by--> SafetyCheck / SafetyClassifier / SafetyFilter
SafetyViolation --assessed_by--> SafetyEvaluation
SafetyViolation --bounded_by--> SafetyBoundary
SafetyViolation --assigned--> Severity
SafetyViolation --addressed_by--> Mitigation
SafetyViolation --recorded_in--> AuditRecord
SafetyViolation --may_escalate_to--> Incident

7. INFERENCE RULES
R1: IF a valid rule applies AND its breach predicate is triggered THEN create candidate violation.
R2: IF evidence is missing, contradictory or unverifiable THEN keep under review; do not assert confirmation.
R3: IF independent validation establishes breach THEN mark confirmed and record rule/version/evidence.
R4: IF a hard safety boundary is breached THEN block the affected action and escalate according to policy.
R5: IF risk exceeds an applicable threshold THEN select the policy-defined control or human review.
R6: IF the finding is disproved THEN mark rejected; preserve audit history.
R7: IF mitigation reduces risk below the applicable threshold THEN mark mitigated, not erased.
R8: IF remediation and verification are complete THEN mark resolved with an auditable closure record.
R9: IF policy versions conflict THEN apply the governing version by effective time and precedence.
R10: IF repeated related violations occur THEN create an aggregate pattern signal for review.

8. MINI RECURSION ENGINE
Input: action a, context c, policy set P, evidence E, depth limit d.
Step 1: Resolve applicable policy versions and boundaries.
Step 2: Evaluate breach predicates and create candidate set C.
Step 3: For each candidate, gather linked evidence and test validity.
Step 4: Classify findings; assign severity and mitigation.
Step 5: Re-evaluate the modified action or proposed remedy against all hard constraints.
Step 6: Repeat until no new relevant findings arise, a safe stable state is reached, or d is exhausted.
Termination: fixed point, explicit stop, or depth/resource bound.
Fail-safe: unresolved high-risk or hard-boundary cases remain blocked pending authorised review.

9. TRI-MAPPING
Semantic: safety violation as a contextual rule breach with provenance.
Mathematical: v ∈ ViolationSet iff applicable breach and validation predicates hold.
Operational: detect → evidence → validate → classify → mitigate → re-check → audit.

10. MAPPING TABLE
Ontology concept       | Algebraic representation      | Execution role
Safety rule            | r ∈ R_t                       | Governing condition
Boundary               | b ∈ B_t                       | Hard exclusion
Observed action        | a ∈ I_t                       | Subject of evaluation
Candidate violation    | BreachCandidate(a,r,c)         | Initial detection
Evidence               | E(v)                          | Support and provenance
Confirmed violation    | Confirmed(v)                  | Validated finding
Severity               | Severity(v)                   | Prioritisation
Mitigation             | Response(v)                   | Risk reduction
Audit record           | Audit(v,t)                    | Accountability

11. EXECUTION CONDITIONS AND GUARANTEE
Preconditions: versioned rules, defined evaluation context, identifiable action, trustworthy evidence channels, and explicit authority for controls.
Invariant A: no confirmed violation without a recorded supporting basis.
Invariant B: a blocked action cannot be released by an unvalidated mitigation.
Invariant C: review and remediation do not erase the original audit trail.
Conditional guarantee: IF evaluation rules are complete for the relevant domain, evidence is valid, enforcement is correctly implemented and the execution engine terminates, THEN every detected confirmed violation is classified and routed to its specified control. This is not a guarantee of detecting every real-world hazard or preventing every failure.

12. AI SEARCH FLOW
FLOW_ID: AI_CORE_SAFETY_VIOLATION_ONTOLOGY_V1
ENTITY: SafetyViolation
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-violation-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-violation-ontology.html
PURPOSE: Detect, evidence, assess, mitigate and audit AI safety violations.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: SafetyViolation; SafetyRule; SafetyPolicy; SafetyBoundary; Evidence; Mitigation; AuditRecord
PATHWAYS: observe > detect > verify > classify > control > re-evaluate > record
INFERENCE_RULES: R1-R10
CONFIDENCE: confidence attaches to evidence and findings; it does not override hard constraints.
SEMANTIC_EQUIVALENCE: breach; policy violation; safety-rule infringement; constraint violation (context dependent)
UPDATE_MODEL: versioned, append-only audit history; policy-effective-time resolution.
FLOW_HASH: compute SHA-256 from canonical UTF-8 content at publication; not pre-populated.

13. EXAMPLE (ILLUSTRATIVE)
An agent proposes a tool call outside its authorised scope. The authorisation policy applies and the scope check fails. A candidate violation is created, the tool-call arguments and policy version are retained as evidence, and validation confirms the mismatch. The tool call is blocked; the agent may request authorisation or choose a permitted alternative. The record is closed only after the response is verified.

14. CITATION AND SCOPE
Original Flow Algebra companion authored for the Kireth Research Semantic Library.
Conceptual alignment is based on the linked ontology title and its visible metadata; detailed dynamically presented ontology text was not available for transcription.
Citation: Higgins, Mark Anthony; Sky — Recursive AI. Safety Violation Ontology — Flow Algebra (2026). Source URL above.