Failure Mode Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SAFETY ENTITIES
FAILURE MODE 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/failure-mode-ontology.html
Status: Original companion formalisation. The public page confirms the ontology title and authorship; the detailed definitions below are a constructed specification, not a verbatim extraction.
Licence: Refer to the source project's published Open Research Licence; attribution requested.

1. PURPOSE
Represent, identify, assess, monitor and mitigate ways in which an AI system, component, control or workflow may fail to meet a specified requirement. Separate the failure mode (how failure occurs), cause (why), effect (what follows), evidence (what supports the finding) and mitigation (what reduces exposure).

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed inputs, events, operating context, telemetry and test results.
R_t = applicable requirements, safety rules, dependencies and causal relationships.
B_t = operational limits, thresholds, permissions and unacceptable outcomes.
K_t = current knowledge of components, known failure modes, controls and uncertainty.
FailureMode f = (id, component, function, deviation, causes, effects, triggers, detection, severity, likelihood, detectability, controls, status, evidence, provenance).
All assessments must retain a timestamp, scope and evidence reference.

3. ENTITY GRAPH
ENTITIES: AI_System, Component, Function, Requirement, Failure_Mode, Failure_Cause, Trigger, Failure_Effect, Hazard, Risk, Safety_Constraint, Safety_Check, Safety_Threshold, Detection_Signal, Test_Case, Evidence, Mitigation, Residual_Risk, Incident, Owner.
RELATIONS:
Component --performs--> Function
Function --governed_by--> Requirement
Failure_Mode --affects--> Component
Failure_Mode --violates_or_degrades--> Requirement
Failure_Cause --contributes_to--> Failure_Mode
Trigger --activates--> Failure_Mode
Failure_Mode --produces--> Failure_Effect
Failure_Effect --may_create--> Hazard
Hazard --contributes_to--> Risk
Safety_Check --detects--> Failure_Mode
Evidence --supports_or_refutes--> Failure_Mode
Mitigation --reduces--> Likelihood_or_Impact
Residual_Risk --remains_after--> Mitigation
Owner --responsible_for--> Review

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | x satisfies B_t and applicable policy}
F_t = {f | observed_deviation(f,I_t) OR supported_prediction(f,K_t)}
C_t(f) = causal_support(f, evidence, dependencies)
D_t(f) = detection_support(f, tests, signals)
P_t(f) = likelihood_estimate(f | I_t,R_t,K_t)
H_t(f) = impact_estimate(f | affected_requirements, context)
Risk_t(f) = risk_model(P_t(f), H_t(f), exposure_t(f))
Priority_t(f) = priority_model(Risk_t(f), detectability_t(f), policy_t)
f* = argmax_{f in F_t} Priority_t(f), subject to evidence quality and B_t
I_{t+1} = update(I_t, observed_results, intervention_results)
K_{t+1} = revise(K_t, verified_evidence, outcomes, uncertainty)
NOTE: Risk and priority functions are configurable; neither is universally a calibrated probability. A simple severity × likelihood × detectability score is only an ordinal screening heuristic when scales are ordinal.

5. IMPLEMENTS / EXECUTION PATHWAY
INPUT -> NORMALISE -> IDENTIFY FUNCTION/REQUIREMENT -> DETECT DEVIATION -> ASSOCIATE FAILURE MODE -> GATHER EVIDENCE -> ESTIMATE CAUSE/EFFECT -> EVALUATE RISK -> APPLY CONSTRAINTS -> SELECT CONTROL -> TEST CONTROL -> RECORD RESIDUAL RISK -> MONITOR -> REVISE.
If evidence is insufficient, label UNCONFIRMED; do not convert a hypothesis into a verified incident.
If a safety boundary is breached, halt or isolate the affected action where the governing policy requires it, then escalate for review.

6. INFERENCE RULES
R1: IF a measurable function deviates from its requirement AND valid evidence exists THEN propose a failure mode.
R2: IF a deviation has multiple plausible causes THEN preserve competing hypotheses until discriminating evidence is available.
R3: IF a failure effect crosses a safety boundary THEN flag a safety violation and invoke the authorised containment pathway.
R4: IF a mitigation passes defined tests THEN update the control status; do not claim zero residual risk.
R5: IF telemetry contradicts a previous assessment THEN reopen the failure-mode record.
R6: IF a failure propagates through dependencies THEN create linked downstream effects without treating correlation as proven causation.
R7: IF evidence provenance or test validity is missing THEN reduce confidence and request verification.
R8: IF a risk exceeds an authorised threshold THEN require escalation or restriction before continued execution.

7. MINI RECURSION ENGINE
INITIALISE S_0 and candidate failure-mode set F_0.
FOR each authorised assessment iteration t:
  collect new observations and test results;
  expand candidate modes through dependency and cause/effect links;
  filter unsupported or out-of-scope claims;
  evaluate safety boundaries, evidence quality and residual risk;
  choose permissible mitigations and verification tests;
  update I_(t+1), K_(t+1) and the entity graph;
  STOP if stable, resource limit reached, review required or safety stop triggered.
INVARIANTS: retain provenance; preserve uncertainty; never bypass a mandatory safety constraint; do not self-authorise a prohibited action.

8. TRI-MAPPING
SEMANTIC: failure-mode terms, functions, causes, effects and requirements.
FORMAL: typed entities, relations, predicates, risk functions and constraints.
OPERATIONAL: monitoring, testing, escalation, mitigation and reassessment.
Mapping: "model emits unsupported assertion" -> Failure_Mode(unsupported_output) -> evidence checks + output restriction + retest.

9. MAPPING TABLE
Concept | Graph node | Formal role | Operational evidence
Failure mode | Failure_Mode | f in F_t | deviation record
Cause | Failure_Cause | C_t(f) | incident analysis
Effect | Failure_Effect | downstream(f) | observed impact
Detection | Safety_Check | D_t(f) | test/monitor signal
Risk | Risk | Risk_t(f) | reviewed assessment
Mitigation | Mitigation | intervention(f) | change/test record
Residual risk | Residual_Risk | risk_after_control(f) | signed review

10. EXECUTION GUARANTEE — CONDITIONAL
Given valid inputs, explicit requirements, complete applicable rules and functioning checks, the flow guarantees traceable processing and recording of each evaluated candidate under the stated procedure. It DOES NOT guarantee discovery of every failure, correctness of causal inference, prevention of all harm or safety under unmodelled conditions. Any stronger guarantee requires a separate formal proof with defined assumptions and verification scope.

11. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.safety-entities.failure-mode.v1
TITLE: Failure Mode Ontology — Flow Algebra
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/failure-mode-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/failure-mode-ontology.html
PURPOSE: Model AI failure modes, their causes, effects, detection, risk and mitigation.
STATE_MODEL: S_t=(I_t,R_t,B_t,K_t)
ENTITIES: Failure_Mode; Failure_Cause; Failure_Effect; Hazard; Risk; Safety_Check; Mitigation; Evidence.
PATHWAYS: observe -> classify -> verify -> assess -> constrain -> mitigate -> retest -> monitor.
MINI_RECURSION_ENGINE: iterative evidence-led reassessment with boundary checks.
INFERENCE_RULES: R1-R8.
CONFIDENCE: evidence-dependent; record uncertainty and calibration status.
SEMANTIC_EQUIVALENCE: failure mechanism; failure scenario; mode of failure (context-dependent, not always identical).
FLOW_HASH: compute SHA-256 on the final published UTF-8 bytes; no fabricated hash supplied.
UPDATE_MODEL: versioned revisions with source, date, rationale and change log.

12. HOW TO READ
Start with the observed deviation and affected requirement. Follow links from failure mode to cause, effect, hazard and risk. Verify each claim using provenance-bearing evidence. Apply the appropriate safety boundary, select a permissible mitigation and reassess residual risk. Repeat when new evidence changes the state.

END OF FLOW