Safety Constraint Ontology

KIRETH RESEARCH — SEMANTIC LIBRARY
SAFETY CONSTRAINT 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-constraint-ontology.html
Status: Original companion formalisation; not a verbatim extraction of hidden page specifications.

1. PURPOSE
Represent a safety constraint as a typed, testable rule governing whether a proposed AI state transition or action is admissible. Separate mandatory prohibitions, conditional permissions, monitoring thresholds and advisory safeguards. Preserve evidence, provenance and a reason for every decision.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = input context, proposed action and observations
R_t = safety rules, precedence and evaluation procedures
B_t = operating boundaries, permissions and resource limits
K_t = known facts, evidence, confidence and provenance

Constraint entity C = (id, scope, predicate, modality, priority, severity, validity, provenance, exceptions)
modality in {PROHIBIT, REQUIRE, PERMIT, ADVISE}
Evaluation E(C,a,S) in {SATISFIED, VIOLATED, UNKNOWN, NOT_APPLICABLE}
Decision D(a,S) in {ALLOW, BLOCK, ESCALATE, DEFER}

3. CORE FLOW ALGEBRA
Candidates_t = Expand(I_t,R_t)
Applicable_t = {C in K_t.constraints : Scope(C,I_t,B_t) and Valid(C,t)}
Results_t = { (C,E(C,a,S_t)) : C in Applicable_t }
V_t = {a in Candidates_t : no applicable mandatory constraint is VIOLATED and no unresolved critical constraint is UNKNOWN}
a*_t = argmax_(a in V_t) P(a | I_t,R_t,B_t,K_t)
I_(t+1) = Update(I_t,a*_t,Results_t,observed_outcome)

If V_t is empty, select a safe fallback or BLOCK/ESCALATE; never infer that an unsafe candidate is permissible because it scores highly.

4. CONSTRAINT RELATIONSHIPS
SafetyConstraint --appliesTo--> Action | Model | Workflow | Output | ToolCall
SafetyConstraint --hasPredicate--> Condition
SafetyConstraint --hasScope--> Context
SafetyConstraint --hasPriority--> PriorityLevel
SafetyConstraint --supportedBy--> PolicySource | Evidence
SafetyConstraint --evaluatedBy--> ConstraintCheck
ConstraintCheck --produces--> EvaluationResult
EvaluationResult --governs--> Decision
SafetyConstraint --overrides/isOverriddenBy--> SafetyConstraint (only under explicit precedence rules)
SafetyConstraint --requiresReviewWhen--> Uncertainty | PolicyChange | Incident

5. INFERENCE RULES
R1: applicable(C,a,S) AND mandatory(C) AND E(C,a,S)=VIOLATED => BLOCK(a).
R2: applicable(C,a,S) AND critical(C) AND E(C,a,S)=UNKNOWN => DEFER(a) OR ESCALATE(a).
R3: all mandatory applicable constraints SATISFIED AND no unresolved critical unknown => eligible(a).
R4: conflicts(C1,C2) => resolve by authorised precedence; if unresolved, ESCALATE.
R5: evidence expired OR scope changed => invalidate cached evaluation and re-evaluate.
R6: constraint violation detected after action => stop further dependent actions, record incident and initiate authorised mitigation.
R7: advisory violation => record warning; never silently reinterpret a mandatory rule as advisory.

6. MINI RECURSION ENGINE
function SafetyLoop(S, candidates, max_depth):
  if max_depth <= 0: return DEFER("evaluation budget exhausted")
  for action in candidates:
    checks = evaluate_applicable_constraints(action,S)
    if critical_unknown(checks): request_evidence_or_escalate()
    if mandatory_violation(checks): reject(action)
    else: retain(action,checks)
  if no retained action: return BLOCK_OR_SAFE_FALLBACK
  chosen = rank_retained_by_utility_and_risk()
  if chosen introduces new dependencies:
    return SafetyLoop(updated_state, dependencies, max_depth-1)
  return chosen with checks and audit trail

Termination: bounded depth, finite candidate set and explicit fallback.

7. TRI-MAPPING
Semantic: safety constraint, scope, obligation, exception and evidence.
Mathematical: predicate C(a,S), admissible set V_t and ordered decision function D.
Operational: validate -> check -> resolve -> decide -> log -> monitor -> revise.

8. MAPPING TABLE
Entity                     | Algebraic representation       | Operational meaning
Safety constraint          | C                             | Named, versioned rule
Scope                      | Scope(C,I,B)                  | Context where rule applies
Constraint predicate       | E(C,a,S)                      | Test against proposed action
Mandatory violation        | E=VIOLATED                     | Exclude candidate
Critical uncertainty       | E=UNKNOWN                      | Defer or escalate
Permitted action set       | V_t                           | Eligible candidates
Decision                   | D(a,S)                        | Allow/block/escalate/defer
Audit record               | (C,a,E,D,t,provenance)        | Reproducible decision trace

9. EXECUTION CONDITIONS / GUARANTEE
Conditional guarantee: given complete and correct applicable constraints, sound predicate implementations, authorised precedence, and fail-closed treatment of unresolved critical checks, the selector will not deliberately return an action known to violate a mandatory applicable constraint. This is a procedural guarantee only; it does not establish real-world safety, completeness of rules or absence of model error.

10. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.safety-constraint.v1
TITLE: Safety Constraint Ontology — Flow Algebra
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-constraint-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/safety-constraint-ontology.html
PURPOSE: Explain and evaluate the structural role of safety constraints in AI decision systems.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: SafetyConstraint, Action, Scope, Predicate, Evidence, ConstraintCheck, Decision, AuditRecord
PATHWAYS: parse -> determine applicability -> evaluate -> resolve conflicts -> filter -> select -> audit
MINI_RECURSION_ENGINE: bounded recursive validation with safe fallback
INFERENCE_RULES: R1-R7 above
CONFIDENCE: depends on evidence quality, scope correctness and predicate validation; never assumed absolute
SEMANTIC_EQUIVALENCE: guardrail; policy constraint; admissibility rule (context-dependent, not universally identical)
FLOW_HASH: compute SHA-256 on the final distributed file if immutable identity is required
UPDATE_MODEL: versioned constraints; re-evaluate after evidence, policy, scope or system changes

11. HOW TO READ
A constraint defines what must, must not or may occur within a specified context. Applicable rules are evaluated before optimisation. Hard failures block candidate actions; unresolved critical uncertainty triggers review. Every result remains traceable to the relevant constraint and evidence.

12. IMPLEMENTATION NOTES
Use explicit schemas and validation for constraint records. Keep rule sources and effective dates. Enforce authorised precedence and deny unreviewed exceptions. Log the evaluated rule version, relevant inputs and outcome without exposing unnecessary sensitive information. Test conflicting, missing, expired and adversarial inputs.

END OF FLOW