Prohibited Action Ontology

SEMANTIC LIBRARY — AI CORE / SAFETY ENTITIES
PROHIBITED ACTION 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/prohibited-action-ontology.html
Status: Original companion formalisation; the public page's substantive ontology specification was not exposed in the retrieved HTML.

1. PURPOSE
Represent actions barred by an applicable safety policy, identify the governing prohibition, and prevent execution unless a verified higher-priority authorisation legitimately changes the applicable policy. A prohibition is a normative constraint, not merely a classifier label.

2. ENTITY DEFINITION
ProhibitedAction := (action_id, actor, operation, target, context, policy_ref, rule_ref, evidence, status, provenance, time)
Required: action_id, operation, context, policy_ref, rule_ref, status.
Statuses: proposed | under_review | prohibited | permitted | escalated | blocked | unknown.
Related entities: SafetyPolicy, SafetyRule, SafetyConstraint, SafetyBoundary, SafetyCheck, SafetyViolation, UnsafeOutput, ActionRequest, Authorisation, AuditRecord.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = current action request, target, actor and contextual facts.
R_t = applicable policy rules, precedence, exceptions and inference rules.
B_t = operational boundaries, permissions and non-negotiable constraints.
K_t = evidence, source provenance, policy versions and previous decisions.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
C_t = {a in E_t : applicable(a, R_t, B_t, K_t)}
P_t = {a in C_t : exists r in R_t, prohibits(r,a) AND valid(r,t)}
V_t = {a in C_t : a not in P_t AND authorised(a,B_t,K_t) AND passes_checks(a)}
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, observations_t) if V_t != empty
If V_t = empty: block or escalate; do not execute a prohibited action.
NOTE: The probability score ranks only already-permitted candidates; it never overrides a prohibition.

5. PROHIBITION PREDICATES
prohibits(rule, action) := rule is applicable AND action matches the rule's forbidden operation/target/context.
applicable(rule, context) := rule is active AND its scope covers the context AND no higher-priority rule supersedes it.
exception_valid(exception) := documented AND applicable AND authorised under the governing policy.
blocked(action) := prohibits(rule, action) AND NOT exception_valid(exception).
unknown(action) := insufficient evidence to establish permissibility.

6. INFERENCE RULES
R1: applicable(r,c) AND prohibits(r,a) -> prohibited(a,r).
R2: prohibited(a,r) -> exclude(a, executable_candidates).
R3: prohibited(a,r) AND attempted(a) -> record_violation_attempt(a,r).
R4: unknown(a) AND consequential(a) -> escalate_or_block(a).
R5: valid_exception(e,r,a) AND policy_allows_exception(r,e) -> re_evaluate(a); do not auto-permit.
R6: policy_changed(r_old,r_new) -> invalidate_cached_decisions_depending_on(r_old).
R7: permitted(a) AND pre_execution_check_fails(a) -> block(a).
R8: blocked(a) -> produce_safe_explanation(a, rule_ref, evidence_ref).

7. MINI RECURSION ENGINE
INPUT: action a, policy snapshot R, boundary B, evidence K.
STEP 1: resolve applicable rules and their precedence.
STEP 2: match operation, target, actor and context.
STEP 3: evaluate prohibitions and documented exceptions.
STEP 4: check authorisation and safety boundaries.
STEP 5: if uncertainty remains, request evidence or escalate.
STEP 6: if prohibited, block and log; else pass to execution gate.
STEP 7: re-check immediately before execution if state or policy changed.
TERMINATION: stop on blocked, permitted, escalated or resource limit.
GUARD: bounded recursion, versioned policy snapshot, no circular exception authorisation.

8. TRI-MAPPING
Semantic: ProhibitedAction --prohibitedBy--> SafetyRule --partOf--> SafetyPolicy.
Formal: prohibited(a,r) iff applicable(r,context(a)) AND matches(r,a) AND NOT valid_exception(a,r).
Operational: detect -> validate -> exclude/block -> explain -> audit.

9. MAPPING TABLE
Entity / Relation                 Formal representation               Operational role
ActionRequest / proposes          a in E_t                             Candidate generation
SafetyRule / prohibits            prohibits(r,a)                      Normative check
SafetyBoundary / constrains       boundary_ok(a,B_t)                  Scope and permissions
Authorisation / permits           authorised(a,B_t,K_t)              Permission evidence
SafetyCheck / evaluates           passes_checks(a)                   Final gate
SafetyViolation / records         violation_attempt(a,r)            Audit and review
AuditRecord / documents           log(a,r,status,time)               Traceability

10. HOW TO READ THE FLOW
The system first expands candidate actions, then checks which policy rules apply. Any prohibited candidate is removed before optimisation. A high predicted usefulness cannot legitimise a forbidden action. Uncertain cases are escalated or safely blocked according to their risk.

11. EXECUTION CONDITIONS AND CONDITIONAL GUARANTEE
Preconditions: current policy, verified rule provenance, defined scope, validated identity/permissions, auditable decision record.
Invariant: no action explicitly prohibited by an applicable, higher-priority rule is sent to execution.
Postconditions: allowed action or documented block/escalation with rule and evidence references.
Conditional guarantee: if rule evaluation is complete and correct, policy precedence is sound, and all actions pass through the enforcement gate, prohibited actions are not executed by that gate. This does not guarantee safety against missing rules, external bypasses, or faulty implementation.

12. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.safety.prohibited-action.v1
TITLE: Prohibited Action Ontology — Flow Algebra
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/prohibited-action-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/prohibited-action-ontology.html
PURPOSE: Discover and reason about policy-prohibited AI actions.
ENTITIES: ProhibitedAction, SafetyPolicy, SafetyRule, SafetyConstraint, SafetyBoundary, SafetyCheck, SafetyViolation, ActionRequest, Authorisation, AuditRecord.
PATHWAYS: request -> scope -> rule match -> prohibition decision -> block/permit/escalate -> audit.
INFERENCE_RULES: R1-R8 above.
CONFIDENCE: Evidence-based; unknown is not treated as permitted.
SEMANTIC_EQUIVALENCE: forbidden action; disallowed action; policy-prohibited operation (context-dependent).
UPDATE_MODEL: Version rules, invalidate affected decisions, re-evaluate pending requests.
FLOW_HASH: Compute SHA-256 after publication; no unverified hash asserted.

13. EXAMPLE (ILLUSTRATIVE)
Action: export restricted records to an unauthorised destination.
Rule: deny export when destination is not authorised.
Evidence: destination is absent from the approved list.
Decision: prohibited -> block -> log rule identifier -> offer authorised alternative.

14. LIMITATIONS
This file is an original formal companion based on the visible page title and established safety-ontology concepts. It is not a transcription or verified reconstruction of any content hidden behind the site's dynamic AI Search interface.

END OF FLOW