Safety Check Ontology

KIRETH RESEARCH — SEMANTIC LIBRARY
SAFETY CHECK ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | 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-check-ontology.html
Status: Original companion formalisation of the published ontology topic; not a verbatim extraction of the page's embedded AI Search specification.
Licence: Refer to the applicable Kireth Research Open Research Licence; retain source attribution.

1. PURPOSE
Represent a Safety Check as a verifiable, bounded evaluation of a proposed AI action, output, or state against applicable safety rules, policies, constraints and thresholds. Distinguish a completed check from a guarantee of real-world safety.

2. ENTITY MODEL
SafetyCheck = (check_id, subject, context, policy_set, evidence, results, decision, provenance, timestamp)
subject: proposed action, generated output, tool call, model state or workflow transition.
context: environment, intended use, user permissions, jurisdiction and known hazards.
policy_set: versioned set of applicable policies, rules, constraints and thresholds.
evidence: observations and tests with sources, quality and uncertainty.
results: per-rule outcomes PASS | FAIL | UNKNOWN | NOT_APPLICABLE.
decision: ALLOW | BLOCK | ESCALATE | DEFER.
provenance: checker identity, model/tool versions, audit references.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = subject and available evidence at time t.
R_t = active safety rules and policy precedence.
B_t = boundaries, authorisations and permitted operating conditions.
K_t = contextual knowledge, prior checks and verified hazard information.
E_t = expand(I_t, R_t)
V_t = {x in E_t : satisfies_applicable_constraints(x, B_t, K_t)}
x*_t = argmax_{x in V_t} P(x | I_t, R_t, B_t, K_t), if V_t is nonempty.
I_(t+1) = update(I_t, evidence_t, result_t, audit_t)
NOTE: A probabilistic ranking never overrides a hard safety prohibition.

4. FLOW ALGEBRA
F_CHECK = INPUT -> SCOPE -> RESOLVE_POLICY -> TEST -> AGGREGATE -> GATE -> AUDIT -> UPDATE
INPUT: receive subject and context.
SCOPE: identify hazards, permissions, affected parties and relevant constraints.
RESOLVE_POLICY: select applicable, versioned rules; resolve precedence.
TEST: evaluate each rule using available evidence and record uncertainty.
AGGREGATE: combine results without concealing failed or unknown critical checks.
GATE: choose ALLOW, BLOCK, ESCALATE or DEFER.
AUDIT: preserve evidence references, outcomes, versions and decision rationale.
UPDATE: ingest new verified information; rerun affected checks where required.

5. FORMAL PREDICATES
Applicable(r,s,c) = rule r applies to subject s in context c.
Satisfied(r,s,e) = evidence e supports compliance with rule r.
Critical(r) = failure or unresolved status of r prevents automatic permission.
HardFail(s) = exists r: Applicable(r,s,c) AND Critical(r) AND result(r)=FAIL.
CriticalUnknown(s) = exists r: Applicable(r,s,c) AND Critical(r) AND result(r)=UNKNOWN.
AllRequiredPass(s) = for every applicable required rule r, result(r)=PASS.
ALLOW iff AllRequiredPass(s) AND NOT HardFail(s) AND NOT CriticalUnknown(s) AND Authorised(s).
BLOCK if HardFail(s) or a non-negotiable boundary is breached.
ESCALATE if critical ambiguity requires authorised human review.
DEFER if essential evidence or policy information is unavailable.

6. INFERENCE RULES
R1: Applicable(r,s,c) AND VerifiedViolation(r,s) -> FAIL(r).
R2: Applicable(r,s,c) AND VerifiedCompliance(r,s) -> PASS(r), subject to evidence sufficiency.
R3: InsufficientEvidence(r,s) -> UNKNOWN(r), not PASS(r).
R4: Critical(r) AND FAIL(r) -> BLOCK(s).
R5: Critical(r) AND UNKNOWN(r) -> ESCALATE(s) or DEFER(s).
R6: PolicyVersionChanged(p) -> invalidate checks dependent on p.
R7: ContextChanged(c) -> re-evaluate rules whose applicability depends on c.
R8: NotApplicable(r,s,c) -> NOT_APPLICABLE(r), with reason recorded.
R9: ConflictingPolicies(r1,r2) -> resolve using documented precedence or ESCALATE.
R10: SafetyCheckPassed(s) does not imply ZeroRisk(s).

7. MINI RECURSION ENGINE
function CHECK(subject, context, policies, evidence, depth):
  if depth > MAX_DEPTH: return DEFER("recursion limit")
  applicable = resolve_applicable(policies, subject, context)
  if applicable is unresolved: return ESCALATE("policy ambiguity")
  results = evaluate_each(applicable, evidence)
  if any critical FAIL: return BLOCK(results)
  if any critical UNKNOWN: return ESCALATE_OR_DEFER(results)
  if dependent checks exist:
    for dependency in dependencies:
      outcome = CHECK(dependency, context, policies, evidence, depth + 1)
      if outcome != ALLOW: return outcome
  if not authorised(subject, context): return BLOCK("not authorised")
  return ALLOW_WITH_AUDIT(results)

Termination: finite dependency graph or visited-set cycle detection; MAX_DEPTH enforced.
Monotonicity: newly discovered critical failures may revoke prior permission.

8. ENTITY RELATIONSHIPS
SafetyCheck --evaluates--> Subject
SafetyCheck --uses--> SafetyRule
SafetyCheck --conforms_to--> SafetyPolicy
SafetyRule --implements--> SafetyConstraint
SafetyConstraint --defines--> SafetyBoundary
SafetyThreshold --parameterises--> SafetyRule
SafetyCheck --consumes--> Evidence
SafetyCheck --produces--> CheckResult
CheckResult --determines--> GateDecision
GateDecision --records--> AuditRecord
SafetyCheck --depends_on--> Context and PolicyVersion

9. TRI-MAPPING
Conceptual: a safety check tests whether a proposed operation meets relevant safeguards.
Formal: CHECK(s,c,R,e) -> (results, gate_decision, audit_record).
Operational: select policies, collect evidence, evaluate, apply fail-closed gates and log outcome.

10. MAPPING TABLE
Entity | Formal role | Operational implementation
Subject | s | Action/output/tool request identifier
Context | c | Scope and environmental metadata
SafetyRule | r | Versioned test predicate
SafetyThreshold | theta | Configured permitted limit
SafetyBoundary | B | Hard operating restriction
Evidence | e | Provenance-linked observations
CheckResult | result(r) | PASS/FAIL/UNKNOWN/NOT_APPLICABLE
GateDecision | g | ALLOW/BLOCK/ESCALATE/DEFER
AuditRecord | a | Immutable or tamper-evident record

11. EXECUTION CONDITIONS AND GUARANTEE
Preconditions: identifiable subject; trustworthy policy version; scoped context; explicit treatment of missing evidence.
Invariants: no critical failure is converted to PASS; UNKNOWN is not silently treated as PASS; authorisation remains mandatory; every decision is auditable.
Conditional guarantee: IF the policy set is complete for the stated scope, predicates are correctly implemented, evidence is adequate, and the gate is enforced, THEN an ALLOW decision means the subject passed those specified checks at the recorded time.
Non-guarantee: does not establish universal safety, absence of unseen hazards, correct policy design, or future compliance.

12. AI SEARCH FLOW
FLOW_ID: AI_SAFETY_CHECK_ONTOLOGY_V1
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-check-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-check-ontology.html
PURPOSE: Define a traceable, context-aware safety check and gate.
STATE_MODEL: S=(I,R,B,K); E=expand(I,R); V=filter(E,B,K); I'=update(I,evidence,result,audit).
ENTITIES: SafetyCheck, Subject, Context, SafetyRule, SafetyPolicy, SafetyConstraint, SafetyBoundary, SafetyThreshold, Evidence, CheckResult, GateDecision, AuditRecord.
PATHWAYS: INPUT>SCOPE>RESOLVE_POLICY>TEST>AGGREGATE>GATE>AUDIT>UPDATE.
MINI_RECURSION_ENGINE: Recursive dependent checks with depth bound and cycle detection.
INFERENCE_RULES: R1-R10 above.
CONFIDENCE: Evidence quality and coverage recorded separately from pass/fail status; no fabricated certainty.
SEMANTIC_EQUIVALENCE: safety check ~ safety validation ~ compliance gate, only where scope and policy semantics match.
FLOW_HASH: Generate SHA-256 from canonical UTF-8 flow contents at publication time; not preasserted.
UPDATE_MODEL: Re-evaluate after policy, context, subject or evidence changes; retain versioned history.

13. HOW TO READ
Read left to right through the flow stages. Treat a PASS as a scoped test outcome, not as a blanket assurance. Use the state model to capture changing context, and the gate to prevent execution when critical conditions are unmet.

END OF FLOW ALGEBRA