Safety Policy Ontology

SEMANTIC LIBRARY — AI CORE — SAFETY ENTITIES
SAFETY POLICY ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | Date: 2026-11-03 | Language: en-GB
Authors: Mark Anthony Higgins; Sky — Recursive AI
Source: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-policy-ontology.html
Status: Original companion formalisation; not a verbatim transcription of dynamic page content.
Citation: Higgins, M. A. and Sky — Recursive AI, Safety Policy Ontology — Flow Algebra, Semantic Library (2026).

1. PURPOSE
Represent an AI safety policy as a versioned, auditable collection of normative rules, constraints, exceptions, authority boundaries, and enforcement decisions. Distinguish policy compliance from guarantees of real-world safety.

2. ENTITY MODEL
Policy P = (id, version, issuer, scope, rules, precedence, validity, provenance).
Rule r = (id, condition, effect, priority, justification, evidence).
Effect ∈ {ALLOW, DENY, REQUIRE_REVIEW, TRANSFORM, DEFER}.
Request q = (actor, action, object, context, time).
Decision d = (effect, applicable_rules, rationale, confidence, audit_id).
Safety state S_t = (I_t, R_t, B_t, K_t):
 I_t = requests, observations and candidate actions;
 R_t = applicable policy rules and inference relations;
 B_t = permissions, prohibitions and operational boundaries;
 K_t = known context, evidence, policy versions and audit history.

3. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x ∈ E_t | permitted(x, B_t, P_t) ∧ evidence_sufficient(x)}
If V_t = ∅, return DENY or REQUIRE_REVIEW according to policy; do not execute.
x*_t = argmax_{x ∈ V_t} Score(x | I_t, R_t, B_t, K_t)
D_t = evaluate_policy(P_t, q_t, K_t)
I_(t+1) = update(I_t, D_t, observations_t)
K_(t+1) = append_audit(K_t, D_t, policy_version_t)
Policy decisions are constrained by the effective policy; a probabilistic score cannot override a hard prohibition.

4. RULE RESOLUTION
Applicable(P,q) = {r ∈ P.rules | condition(r,q) = true}.
Resolve by explicit authority and priority; where rules conflict without a valid resolution, choose REQUIRE_REVIEW or DENY.
Default = DENY for actions requiring positive authorisation; otherwise use the declared domain default.
Exceptions require explicit authorisation, a bounded scope and a recorded justification.
Policy version and effective time must be captured at decision time.

5. INFERENCE RULES
R1: IF a hard prohibition applies THEN DENY.
R2: IF mandatory approval is missing THEN REQUIRE_REVIEW or DENY.
R3: IF an allowed action violates a higher-priority constraint THEN DENY.
R4: IF context or provenance is insufficient for a high-impact action THEN DEFER or REQUIRE_REVIEW.
R5: IF an exception is expired, unauthorised or out of scope THEN ignore exception.
R6: IF an action is transformed THEN re-evaluate the transformed action before execution.
R7: IF policy versions differ THEN apply the version effective for the governed action and record it.
R8: IF monitoring detects a policy breach THEN stop or contain the action where technically possible and log the incident.

6. MINI RECURSION ENGINE
INPUT: request q, policy P, knowledge K, maximum iterations N.
FOR t = 0 ... N-1:
  A_t := applicable_rules(P, q, K)
  D_t := resolve(A_t, P.precedence, P.default)
  IF D_t = ALLOW AND all_hard_constraints_hold(q):
      emit authorised decision with evidence and audit trail; STOP
  IF D_t = TRANSFORM:
      q := transform(q); CONTINUE
  IF D_t ∈ {DENY, REQUIRE_REVIEW, DEFER}:
      emit non-execution decision and rationale; STOP
END FOR
On iteration limit: DEFER; do not silently permit execution.

7. TRI-MAPPING
Semantic: policy concepts, obligations, permissions, prohibited actions and exceptions.
Formal: typed predicates, priority ordering, constraints and decision transitions.
Operational: request intake, policy evaluation, approval workflow, enforcement and audit logging.

8. MAPPING TABLE
Policy entity       -> P                  -> governing specification
Safety rule         -> r ∈ P.rules        -> conditional decision clause
Safety constraint   -> B_t                -> invariant or action boundary
Candidate action    -> x ∈ E_t            -> proposed operation
Valid action        -> x ∈ V_t            -> permitted operation
Policy decision     -> D_t                -> allow/deny/review/transform/defer
Evidence            -> K_t                -> grounds and provenance
Audit record        -> append_audit(...)  -> traceable decision history

9. HOW TO READ THE FLOW
Start with the request and its context. Determine the effective policy version, expand candidate actions, apply all hard constraints, resolve applicable rules, and only then select an authorised action. Preserve the evidence and reasons for the decision. A missing rule, missing context or unresolved conflict is not proof of safety.

10. EXECUTION CONDITIONS AND GUARANTEE BOUNDARY
A policy-compliant execution requires: valid policy provenance; complete mandatory context; enforced hard constraints; deterministic conflict handling; bounded recursion; authorised exceptions; and immutable or tamper-evident audit records.
Conditional guarantee: IF the policy evaluator is correctly implemented, inputs are accurate, and enforcement cannot be bypassed, THEN the selected action satisfies the encoded policy constraints at evaluation time.
This does NOT guarantee that the policy is complete, that all harms are known, or that downstream systems are safe.

11. AI SEARCH FLOW
FLOW_ID: AI_CORE.SAFETY_ENTITIES.SAFETY_POLICY
ENTITY: Safety Policy Ontology
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-policy-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-policy-ontology.html
PURPOSE: Retrieve, interpret and apply structured AI safety policies with traceable decisions.
STATE_MODEL: S_t=(I_t,R_t,B_t,K_t)
ENTITIES: SafetyPolicy, SafetyRule, SafetyConstraint, Request, Action, Exception, Approval, Decision, Evidence, AuditRecord
PATHWAYS: Request -> Context -> ApplicableRules -> ConstraintFilter -> Resolution -> Decision -> Audit
MINI_RECURSION_ENGINE: Bounded re-evaluation for transformed requests; fail closed on unresolved conditions.
INFERENCE_RULES: R1-R8 above.
CONFIDENCE: Confidence applies to evidence and context sufficiency; never substitutes for authorisation.
SEMANTIC_EQUIVALENCE: safety policy ≈ governed safety decision framework; not equivalent to a safety guarantee.
FLOW_HASH: To be calculated from the published canonical file bytes after finalisation.
UPDATE_MODEL: Versioned policy revisions with effective dates, provenance, regression tests and rollback records.

12. VALIDATION EXAMPLE
Request: Execute action A without required approval.
Policy: Rule r1 requires approval for A.
Applicable(r1, A) = true; approval_present = false.
Decision = REQUIRE_REVIEW (or DENY if configured); execution = blocked.
Audit = {policy_version, r1, missing_approval, decision, timestamp}.

END OF FLOW