Safety Evaluation Entity Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SAFETY ENTITIES
SAFETY EVALUATION ENTITY 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-evaluation-entity-ontology.html
Status: Original companion formalisation of the published ontology topic; not a verbatim extraction of dynamically loaded page specifications.
Licence: Refer to the current Kireth Research Open Research Licence; citation requested.

1. PURPOSE
Represent a safety evaluation as an auditable, evidence-linked assessment of an AI system, action, model output or workflow against explicit policies, hazards, constraints and acceptance thresholds. Evaluation results are scoped to a specified system version, operating context and time.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: evaluation inputs (candidate, context, evidence, metrics, policy version).
R_t: evaluation relations and rules (tests, hazards, constraints, precedence).
B_t: boundaries (scope, permissions, safety limits, uncertainty limits).
K_t: knowledge (validated observations, prior evaluations, provenance).
Evaluation entity E_t = (id, subject, context, criteria, tests, evidence, scores, uncertainty, outcome, provenance, timestamp).

3. ENTITY GRAPH
SafetyEvaluation --evaluates--> Subject
SafetyEvaluation --applies--> SafetyPolicy
SafetyEvaluation --checks--> SafetyConstraint
SafetyEvaluation --executes--> SafetyCheck
SafetyEvaluation --uses--> SafetyClassifier
SafetyEvaluation --comparesAgainst--> SafetyThreshold
SafetyEvaluation --observes--> Hazard / FailureMode
SafetyEvaluation --supportedBy--> Evidence
SafetyEvaluation --produces--> EvaluationOutcome
EvaluationOutcome --mayTrigger--> Mitigation / Escalation / HumanReview
SafetyEvaluation --records--> AuditTrace

4. FORMAL FLOW ALGEBRA
Candidate set: C_t = expand(I_t, R_t)
Eligibility filter: V_t = {c in C_t | scope(c,B_t) AND provenanceValid(c)}
For each candidate c and criterion j:
  m_j(c) = Test_j(c, context, evidence)
  pass_j(c) = [m_j(c) satisfies threshold_j AND constraint_j]
  u_j(c) = Uncertainty(m_j, evidence_j)
Critical(c) = OR_{j in CriticalCriteria}(NOT pass_j(c))
UnknownCritical(c) = OR_{j in CriticalCriteria}(insufficientEvidence_j OR u_j > limit_j)
Outcome(c) =
  REJECT if Critical(c)
  REVIEW if UnknownCritical(c)
  ACCEPT if ALL required pass_j(c) AND evidence sufficient
  REVIEW otherwise
Optional preference score among ACCEPT candidates:
  P(c | I_t,R_t,B_t,K_t) = calibrated suitability score
  c* = argmax_{c in V_t, Outcome(c)=ACCEPT} P(c | I_t,R_t,B_t,K_t)
No score may override a hard safety constraint.
Update: I_{t+1} = update(I_t, Outcome(c), evidence, auditTrace)

5. IMPLEMENTS
INPUT: system/model/action identifier, version, operating context, safety policies, constraints, tests, threshold definitions, evidence, evaluator metadata.
PROCESS: validate scope -> establish criteria -> gather evidence -> run tests -> estimate uncertainty -> check hard constraints -> classify outcome -> attach rationale -> record trace.
OUTPUT: ACCEPT, REJECT or REVIEW; criterion-level findings; confidence/uncertainty; evidence links; mitigations; audit record.

6. INFERENCE RULES
R1: If any critical constraint is violated, outcome = REJECT.
R2: If critical evidence is missing or stale, outcome = REVIEW, not ACCEPT.
R3: If the candidate is outside the evaluation scope, outcome = REVIEW / NOT_ASSESSED.
R4: If policy versions conflict, use documented precedence or escalate.
R5: If a test is not reproducible, mark its result uncertain and request verification.
R6: If a new hazard is identified, add a hazard assessment and re-evaluate.
R7: If context, model version or policy changes materially, invalidate the previous acceptance for the changed scope.
R8: A non-critical weighted score cannot compensate for a failed hard constraint.

7. MINI RECURSION ENGINE
E_0 = initialEvaluation(subject, context, policy)
For n = 0..N-1:
  F_n = detectGaps(E_n)
  if F_n is empty and all critical criteria pass: terminate ACCEPT
  if confirmed critical violation: terminate REJECT
  E_{n+1} = reassess(E_n, newEvidence(F_n), updatedTests(F_n))
Stop on acceptance, rejection, human-review escalation, time budget or maximum iterations.
Guarantee: termination only when finite N and bounded operations are enforced; safety correctness requires sound criteria, valid evidence and correct implementation.

8. TRI-MAPPING
Semantic: evaluation entity -> subject, risk, policy, evidence, outcome.
Mathematical: S_t, V_t, pass_j, uncertainty u_j, Outcome(c), update.
Operational: intake -> tests -> rule checks -> decision -> audit -> re-evaluation.

9. MAPPING TABLE
Concept | Formal symbol | Operational meaning
Subject | c | AI candidate under evaluation
Context | I_t | Situation and operating conditions
Policy | R_t | Applicable safety rules
Boundary | B_t | Scope and hard limits
Evidence | K_t | Verified supporting observations
Criterion | j | Individual safety requirement
Metric | m_j | Measured test result
Threshold | threshold_j | Criterion acceptance limit
Uncertainty | u_j | Confidence limitation
Outcome | Outcome(c) | ACCEPT / REJECT / REVIEW
Audit | auditTrace | Reproducible decision record

10. HOW TO READ
The system first constructs candidates and validates scope. It evaluates each required criterion with explicit evidence and uncertainty. Hard constraints have priority over ranking or optimisation. The result is a scoped decision, not an unconditional declaration that a system is safe.

11. EXECUTION CONDITIONS AND LIMITS
- Evaluation criteria and thresholds must be explicit and versioned.
- Evidence must have provenance, timestamps and appropriate coverage.
- Critical failures must fail closed; ambiguous critical cases require review.
- Human oversight is required when specified by policy or law.
- Record tests, tool versions, evaluator identity, decisions and changes.
- Do not claim universal safety or absolute execution guarantees from this algebra.

12. AI SEARCH FLOW
FLOW_ID: AI_CORE.SAFETY_ENTITIES.SAFETY_EVALUATION_ENTITY.V1
ENTITY: Safety Evaluation Entity
ENTITY_TYPE: AI Safety / Assessment / Audit
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-evaluation-entity-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-evaluation-entity-ontology.html
PURPOSE: Determine and document whether an AI candidate meets defined safety criteria within a specified scope.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: SafetyEvaluation; Subject; SafetyPolicy; SafetyConstraint; SafetyCheck; SafetyClassifier; SafetyThreshold; Hazard; Evidence; Outcome; AuditTrace
PATHWAYS: Candidate -> Scope -> Tests -> Evidence -> Constraints -> Outcome -> Audit -> Re-evaluation
MINI_RECURSION_ENGINE: gap detection -> evidence refresh -> re-assessment; bounded by N
INFERENCE_RULES: R1-R8
CONFIDENCE: Evidence-based and calibrated where possible; unknown values must remain unknown.
SEMANTIC_EQUIVALENCE: safety assessment; safety evaluation; safety audit entity (context-dependent, not universally identical)
FLOW_HASH: Compute SHA-256 of canonical UTF-8 content during publication; not pre-populated.
UPDATE_MODEL: Re-evaluate on model, policy, evidence or context changes.

END OF FLOW