Human Oversight Entity Ontology

SEMANTIC LIBRARY — AI CORE — SAFETY ENTITIES
HUMAN OVERSIGHT ENTITY 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/human-oversight-entity-ontology.html
Status: Original companion formalisation; not a verbatim extraction of the webpage's embedded specifications.

1. PURPOSE
Represent accountable human supervision of AI decisions, actions and state transitions. Define when human review, approval, veto, escalation or intervention is required, and preserve auditable evidence of each oversight event.

2. ENTITY MODEL
HumanOversightEntity H = (id, human, system, scope, authority, trigger, review, decision, intervention, evidence, status, time).
Related entities: HumanReviewer, AIModel, Agent, ProposedAction, SafetyPolicy, SafetyConstraint, RiskEntity, IncidentEntity, OversightRequest, Approval, Rejection, Escalation, AuditRecord, SafeState.
Relationships:
  supervises(H, system)
  assigned_to(H, human)
  evaluates(human, ProposedAction)
  constrained_by(ProposedAction, SafetyPolicy)
  produces(H, AuditRecord)
  may_invoke(H, intervention)

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = inputs: proposed action, model output, operating context and observations.
R_t = rules: review triggers, authority requirements, approval criteria and escalation rules.
B_t = boundaries: permitted actions, reviewer jurisdiction, time limits and safety constraints.
K_t = knowledge: provenance, risk assessments, previous reviews and policy versions.
Oversight state q_t ∈ {UNASSESSED, REVIEW_REQUIRED, PENDING, APPROVED, REJECTED, ESCALATED, INTERVENED, EXPIRED, CLOSED}.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x ∈ E_t | conforms(x, B_t) ∧ supported(x, K_t)}
ReviewRequired(a,t) := high_risk(a,t) ∨ irreversible(a) ∨ policy_requires_review(a,t) ∨ uncertain_safety(a,t).
Authorised(h,a,t) := identity_verified(h,t) ∧ authority_covers(h,a,t) ∧ not_conflicted(h,a,t).
ValidApproval(h,a,t) := Authorised(h,a,t) ∧ informed_review(h,a,t) ∧ explicit_approval(h,a,t) ∧ within_validity_window(h,a,t).
Gate(a,t) = ALLOW if (¬ReviewRequired(a,t) ∧ policy_permits(a,t)) ∨ (ValidApproval(h,a,t) ∧ policy_permits(a,t)); otherwise HOLD or DENY.
Selected_t = argmax_{x ∈ V_t} P(x | I_t,R_t,B_t,K_t), subject to Gate(x,t)=ALLOW.
I_(t+1) = update(I_t, Selected_t, observed_outcome_t).
A high model score cannot override a failed safety boundary or a required human approval.

5. OVERSIGHT TRANSITION FLOW
ProposedAction -> RiskClassification -> TriggerEvaluation
  -> [review not required AND permitted] -> AuthorisedExecution
  -> [review required] -> PENDING -> HumanReview
HumanReview -> APPROVED | REJECTED | ESCALATED | INTERVENED
APPROVED -> RevalidateContext -> AuthorisedExecution OR PENDING
REJECTED -> BlockAction -> CLOSED
ESCALATED -> HigherAuthorityReview OR SafeHold
INTERVENED -> Stop/Pause/Modify/Rollback -> VerifySafeState
Timeout/UnavailableReviewer -> EXPIRED -> SafeHold
All transitions -> Immutable-or-tamper-evident AuditRecord.

6. INFERENCE RULES
R1: IF action exceeds oversight threshold THEN require human review.
R2: IF reviewer lacks authority THEN approval is invalid.
R3: IF safety policy prohibits action THEN human approval cannot make it permissible without a separately authorised policy change.
R4: IF approval context changes materially THEN invalidate approval and reassess.
R5: IF reviewer rejects action THEN prevent execution and record reason.
R6: IF immediate hazard is detected THEN invoke authorised safe-stop mechanism and notify human oversight.
R7: IF evidence is insufficient THEN hold or escalate; never infer approval from silence.
R8: IF oversight decision occurs THEN capture reviewer identity, decision, rationale, time, policy version and evidence references.
R9: IF review deadline expires THEN fail closed for gated actions.
R10: IF appeal or override is permitted THEN require independent authority and a separately auditable decision.

7. MINI RECURSION ENGINE
For each oversight cycle t:
  observe proposed action and context;
  classify risk and evaluate policy;
  if review required: request authorised human decision;
  verify decision validity and boundary compliance;
  execute only when gate permits;
  observe outcome, append evidence, update K_(t+1);
  re-evaluate if hazard, policy change or material context drift occurs.
Termination: action completed safely, rejected, escalated, cancelled or timed out.
Recursion limit: finite review attempts and escalation depth; unresolved cases remain on safe hold.

8. TRI-MAPPING
Ontology -> Formalism -> Operational Evidence
HumanReviewer -> Authorised(h,a,t) -> identity/role/authority record
OversightTrigger -> ReviewRequired(a,t) -> risk/policy trigger log
Approval -> ValidApproval(h,a,t) -> signed or attributable approval record
Intervention -> Gate(a,t)=HOLD/DENY -> pause/stop/rollback event
SafeState -> conforms(state,B_t) -> verified post-intervention state
AuditRecord -> trace(H,t) -> timestamped decision and provenance chain

9. MAPPING TABLE
Input: proposed action | Transformation: risk and policy assessment | Output: oversight requirement
Input: oversight request | Transformation: reviewer authentication | Output: authorised review session
Input: evidence and context | Transformation: informed human judgement | Output: approve/reject/escalate
Input: approval | Transformation: validity and boundary recheck | Output: execute or hold
Input: incident signal | Transformation: intervention protocol | Output: safe stop and audit record

10. EXECUTION GUARANTEE — CONDITIONAL
Under verified identity, correct policy configuration, reliable gating, protected audit logging and functioning intervention controls:
  G1: no action marked review-required is executed without valid approval;
  G2: rejected or expired approvals do not authorise execution;
  G3: each oversight transition creates an attributable record;
  G4: safety boundary violations result in hold/deny regardless of approval.
These are design invariants to be tested and monitored, not unconditional guarantees about deployed systems. Failures of sensors, integration, governance or human judgement can invalidate them.

11. AI SEARCH FLOW
FLOW_ID: AI-CORE-SAFETY-HUMAN-OVERSIGHT-ENTITY
FLOW_VERSION: 1.0
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/human-oversight-entity-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/human-oversight-entity-ontology.html
PURPOSE: Define human oversight as a verifiable control over AI action selection and execution.
STATE_MODEL: S_t=(I_t,R_t,B_t,K_t)
ENTITIES: HumanOversightEntity; HumanReviewer; OversightRequest; Approval; Rejection; Escalation; Intervention; AuditRecord; SafeState
PATHWAYS: propose -> assess -> review -> gate -> execute/hold -> audit -> reassess
MINI_RECURSION_ENGINE: bounded review-and-feedback cycle with safe-hold fallback
INFERENCE_RULES: R1-R10
CONFIDENCE: Contextual; dependent on evidence quality, reviewer authority and implementation verification.
SEMANTIC_EQUIVALENCE: human supervision; human-in-the-loop; human-on-the-loop; manual approval; human intervention (not exact synonyms in all contexts)
FLOW_HASH: Compute SHA-256 over the published UTF-8 file at deployment; no hash asserted here.
UPDATE_MODEL: version changes when policy, authority, thresholds, transitions or ontology relations change.

12. HOW TO READ
The ontology identifies who can oversee which AI activities, under what conditions, and with what evidence. Formal rules specify the authorisation gate; state transitions show operational behaviour; tri-mapping links abstract entities to verifiable records.

13. EXAMPLE
An AI agent proposes a high-impact account change. Risk classification triggers mandatory review. A qualified reviewer examines the request and supporting evidence. If approved, the system rechecks policy and context before execution. If rejected, unavailable or timed out, the action stays blocked. Every step is logged.

14. PROVENANCE AND LICENCE NOTE
This is a newly authored Flow Algebra companion for the referenced Kireth Research page. Credit: Mark Anthony Higgins and Sky — Recursive AI. Refer to the publisher's Open Research Licence for reuse terms; no licence terms are invented in this file.