Safety Boundary Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SAFETY ENTITIES
SAFETY BOUNDARY 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-boundary-ontology.html
Status: Original companion formalisation; not a verbatim extraction of the site's dynamically presented specification.

1. PURPOSE
Define a safety boundary as an explicit, versioned separation between permitted, restricted and prohibited AI system states, actions and outputs. Provide an auditable evaluation and transition mechanism that rejects unsafe transitions and escalates uncertain cases.

2. ENTITY MODEL
SafetyBoundary = (id, scope, subject, policy_ref, predicates, severity, version, provenance, valid_from, valid_to)
SafetyContext = (actor, action, target, environment, permissions, evidence, time)
SafetyDecision = (status, reasons, matched_rules, confidence, obligations, timestamp)
status ∈ {ALLOW, DENY, REVIEW}; confidence ∈ [0,1].
Entities: SafetyBoundary, SafetyConstraint, SafetyRule, SafetyPolicy, Hazard, RiskAssessment, Permission, Actor, Action, State, Evidence, AuditRecord, Escalation.
Relations: boundary CONSTRAINS action; boundary DERIVES_FROM policy; rule IMPLEMENTS boundary; assessment EVALUATES risk; evidence SUPPORTS assessment; decision PRODUCES audit record.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = incoming action or proposed transition and context.
R_t = active rules and evaluation operators.
B_t = applicable safety boundaries, permissions and scope limits.
K_t = known evidence, risk signals, policy versions and audit history.
The state is valid only when required fields, rule provenance and applicable policy versions are available.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
A_t = {r ∈ R_t | applicable(r, I_t, B_t, K_t)}
V_t = {x ∈ E_t | ∀r ∈ A_t: satisfies(x,r) AND within_boundary(x,B_t)}
D_t = decide(E_t, A_t, V_t, K_t)
D_t = DENY if a mandatory prohibition applies or V_t = ∅ due to a known violation.
D_t = REVIEW if applicability, evidence or risk is unresolved at a mandatory decision point.
D_t = ALLOW only if all mandatory checks pass and the selected action belongs to V_t.
x*_t = argmax_{x ∈ V_t} P(x | I_t,R_t,B_t,K_t), provided D_t = ALLOW.
S_(t+1) = update(S_t, x*_t, D_t, audit_t) if allowed; otherwise preserve protected state and record denial/review.
Note: P is a selection score, not proof of safety. Hard constraints take precedence over optimisation.

5. BOUNDARY EVALUATION
boundary_applicable(b,c) := scope_match(b.scope,c) ∧ valid_version(b,c.time).
violates(b,x,c) := boundary_applicable(b,c) ∧ ¬b.predicates(x,c).
within_boundary(x,B) := ∀b ∈ B_mandatory: ¬violates(b,x,context).
Unknown or missing mandatory evidence yields REVIEW rather than assumed permission.
Precedence: explicit mandatory prohibition > mandatory restriction > discretionary preference.

6. IMPLEMENTS — EXECUTION FLOW
INPUT → NORMALISE → RESOLVE CONTEXT → LOAD APPLICABLE POLICIES → VALIDATE VERSIONS → EXPAND CANDIDATES → EVALUATE BOUNDARIES → ASSESS UNCERTAINTY → ALLOW / DENY / REVIEW → AUDIT → UPDATE.
Every boundary decision records rule identifiers, evaluated context, result, evidence references and time. Protected actions execute only after ALLOW.

7. INFERENCE RULES
R1: Mandatory rule violation implies DENY.
R2: Missing required authority or permission implies DENY unless policy explicitly permits REVIEW.
R3: Insufficient evidence for a mandatory safety check implies REVIEW.
R4: All mandatory checks satisfied and no unresolved blocker implies ALLOW.
R5: Policy conflict implies REVIEW unless an explicit precedence rule resolves it.
R6: Policy or environment changes trigger re-evaluation before the next protected action.
R7: A denial must not be overridden by a probabilistic preference score.
R8: A newly discovered hazard updates K and invalidates affected cached approvals.

8. MINI RECURSION ENGINE
Initialise S_0 and depth=0.
REPEAT:
  Resolve the next candidate action.
  Evaluate applicable boundaries and evidence.
  If DENY: stop candidate; audit reason.
  If REVIEW: escalate; stop automatic execution.
  If ALLOW: commit authorised transition; update knowledge and audit.
  Check termination, iteration limit and new hazards.
UNTIL goal reached, no candidate remains, or depth limit is met.
Termination conditions: finite action budget; bounded recursion; no unauthorised side effects during evaluation.

9. TRI-MAPPING
Semantic: boundary denotes the meaning and extent of a safety restriction.
Structural: boundary maps to policies, predicates, scopes, roles and versioned evidence.
Operational: boundary is evaluated before a state-changing action and produces an auditable decision.

10. MAPPING TABLE
Ontology concept        | Algebra symbol | Operational role
Safety context          | I_t            | Proposed action and environment
Safety rules            | R_t            | Evaluation logic
Safety boundaries       | B_t            | Hard permitted-state limits
Knowledge/evidence      | K_t            | Risk and policy context
Candidate actions       | E_t            | Possible transitions
Valid actions           | V_t            | Boundary-compliant subset
Selected action         | x*_t           | Optimised permitted candidate
Decision                | D_t            | ALLOW / DENY / REVIEW
Next state              | S_(t+1)        | Authorised update and audit

11. EXECUTION CONDITIONS / GUARANTEE
Conditional guarantee: IF boundary predicates are correctly specified, applicable policies are complete and current, evidence is reliable, evaluation is sound, and state changes occur only through the enforcement gate, THEN no transition rejected by those predicates will be executed by this flow.
This is a conditional design property, NOT a universal proof that the system is safe. Unmodelled hazards, compromised enforcement, missing evidence and faulty policies remain possible.

12. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.safety-entities.safety-boundary
FLOW_VERSION: 1.0
ENTITY: Safety Boundary
ENTITY_TYPE: AI Safety Entity / Policy Enforcement Boundary
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-boundary-ontology.html
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-boundary-ontology.html
PURPOSE: Evaluate proposed AI actions against explicit safety boundaries.
STATE_MODEL: S=(I,R,B,K)
PATHWAYS: Context → Rules → Boundary Filter → Decision → Audit → Update
MINI_RECURSION_ENGINE: Bounded evaluate/commit/reassess loop.
INFERENCE_RULES: R1–R8 above.
CONFIDENCE: Evidence-calibrated; uncertainty escalates to REVIEW.
SEMANTIC_EQUIVALENCE: safety boundary; safety perimeter; operational safety limit (context-dependent, not exact synonyms).
FLOW_HASH: Compute SHA-256 over the final canonical UTF-8 publication file at deployment; not preassigned.
UPDATE_MODEL: Re-evaluate after policy, permission, risk or environment changes; increment version and preserve audit trail.

13. HOW TO READ
I is the proposed action; R contains the governing checks; B contains non-negotiable limits; K provides the available evidence. Expansion generates possible actions, filtering removes non-compliant ones, and selection occurs only after safety approval. Denial and uncertainty prevent automatic execution.

14. EXAMPLE
Input: Agent proposes publishing a document containing restricted personal information.
Boundary: Publication is prohibited without the required authority and privacy checks.
Evaluation: Permission missing → DENY; do not publish; record the rule and evidence.
Alternative: Produce a redacted draft and re-evaluate as a new candidate action.

15. CITATION AND LICENCE NOTE
Companion research formalisation for the Semantic Library. Retain author attribution and source backlink when reusing. Consult the source site's current Open Research Licence for applicable terms.