Security Incident Ontology

SEMANTIC LIBRARY — AI CORE / SECURITY ENTITIES
SECURITY INCIDENT ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | 04 November 2026 | Language: en-GB
Authors: Mark Anthony Higgins; Sky — Recursive AI
Source: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/security-incident-ontology.html
Status: Original companion formalisation. The public page title and attribution were checked; embedded specifications were not available in retrieved page text.

1. PURPOSE
Represent a security incident as a time-bounded, evidence-linked event or series of events affecting confidentiality, integrity, availability, or authorised operation of an AI system. Separate suspected incidents from verified incidents; record uncertainty, authority and response history.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observations, alerts, incident reports, telemetry and operator inputs.
R_t = applicable detection, correlation, severity, containment and reporting rules.
B_t = trust boundaries, permissions, operational limits, legal obligations and human approval gates.
K_t = known assets, threat models, prior incidents, evidence provenance and system context.

Incident entity J = (id, asset, window, indicators, evidence, status, severity, impact, owner, actions, provenance).
status ∈ {suspected, triaged, confirmed, contained, recovered, closed, reopened}.
An unverified indicator does not establish a confirmed incident.

3. CORE FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x ∈ E_t | valid(x, B_t, K_t)}
J_t = correlate(V_t, asset, time_window, provenance)
Risk(J_t) = assess(likelihood, impact, exposure, confidence)
A_t = argmax_{a ∈ permitted_actions} P(a | I_t, R_t, B_t, K_t)
I_(t+1) = update(I_t, J_t, A_t, observed_outcomes)

The argmax expression ranks permitted response options; it does not override mandatory safeguards or confer execution authority. Probabilities require an explicit calibrated model; otherwise use qualitative rankings.

4. ENTITY GRAPH
SecurityIncident --affects--> AIAsset
SecurityIncident --indicatedBy--> SecurityIndicator
SecurityIncident --supportedBy--> EvidenceRecord
SecurityIncident --associatedWith--> SecurityThreat
SecurityIncident --mayExploit--> SecurityVulnerability
SecurityIncident --crosses--> SecurityBoundary
SecurityIncident --assessedBy--> SecurityAssessment
SecurityIncident --handledBy--> IncidentResponder
SecurityIncident --mitigatedBy--> SecurityControl
SecurityIncident --documentedIn--> AuditRecord
SecurityIncident --escalatedTo--> OversightBody
SecurityIncident --mayRequire--> NotificationDecision

5. FORMAL RELATIONS AND CONSTRAINTS
confirmed(J) ⇒ exists(evidence(J)) ∧ verified_provenance(evidence(J))
closed(J) ⇒ documented_resolution(J) ∧ reviewed_residual_risk(J)
containment_action(a) ⇒ authorised(a) ∧ scoped(a) ∧ logged(a)
reportable(J) ⇒ evaluate_notification_obligations(J, jurisdiction, facts)
Missing evidence, uncertain impact or ambiguous ownership must remain explicit; do not infer absence of harm.

6. INFERENCE RULES
R01: Correlated credible alerts may create a suspected incident.
R02: Independent corroboration increases evidence confidence, not certainty.
R03: Verified unauthorised access can justify incident confirmation.
R04: Confirmed exposure of sensitive data triggers privacy-impact review.
R05: Active compromise with high expected impact triggers urgent escalation.
R06: Containment actions require appropriate permissions and safety checks.
R07: Conflicting indicators trigger further investigation, not automatic closure.
R08: Failed mitigation triggers reassessment and an alternative response path.
R09: Changes to incident severity require timestamped rationale and evidence.
R10: Recovery requires service verification and residual-risk review.
R11: Closure requires a recorded owner and reviewable decision trail.
R12: New material evidence may reopen a closed incident.
R13: Reporting obligations are evaluated independently of internal severity labels.
R14: Evidence integrity failures require explicit provenance warnings.

7. MINI RECURSION ENGINE
Input: incident candidate J_t, evidence set D_t, policy B_t.
Step 1: Ingest evidence with source, timestamp and integrity metadata.
Step 2: Validate and correlate observations; distinguish fact from hypothesis.
Step 3: Assess impact, likelihood, confidence and affected assets.
Step 4: Select only permitted containment or investigative actions.
Step 5: Route approval-sensitive or high-impact decisions to human oversight.
Step 6: Observe outcomes, append audit records and update J_(t+1).
Step 7: Repeat while material uncertainty, active harm or unverified recovery remains.
Termination: closure criteria satisfied or responsibility transferred with acknowledgement.

8. TRI-MAPPING
Physical/operational: alerts, affected infrastructure, service degradation, operator actions.
Mathematical/formal: states, predicates, constraints, confidence, transitions, decision rules.
Semantic/ontological: incident, threat, asset, evidence, authority, mitigation, accountability.

9. MAPPING TABLE
Input signal             -> SecurityIndicator   -> observation
Affected model/service   -> AIAsset             -> impact target
Verified log/artifact    -> EvidenceRecord      -> provenance
Applicable control       -> SecurityControl     -> containment
Responsible person/team  -> IncidentResponder   -> authority
Recorded outcome         -> AuditRecord         -> traceability

10. EXECUTION CONDITIONS AND GUARANTEE
Preconditions: trustworthy input provenance, defined response permissions, applicable policies and logging availability.
Invariant: no autonomous response may exceed the permissions in B_t.
Postconditions: every decision records evidence, authority, action, result and uncertainty.
Conditional guarantee: IF the implementation enforces all specified invariants and prerequisites, each accepted transition is policy-constrained and auditable. This does NOT guarantee incident prevention, complete detection, or absence of damage.

11. AI SEARCH FLOW
FLOW_ID: security-incident-ontology
ENTITY_TYPE: SecurityIncident
DOMAIN: AI Security / Governance / Accountability
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/security-incident-ontology.html
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
PURPOSE: Retrieve and reason about AI security incident states, evidence, containment and oversight.
ENTITIES: SecurityIncident, AIAsset, SecurityIndicator, EvidenceRecord, SecurityThreat, SecurityVulnerability, SecurityControl, IncidentResponder, AuditRecord.
PATHWAYS: detect -> triage -> validate -> assess -> authorise -> contain -> recover -> review -> close/reopen.
INFERENCE: R01–R14.
CONFIDENCE: Evidence-weighted; preserve unknown and contested claims.
SEMANTIC_EQUIVALENCE: security event / incident report / compromise event (context-dependent, not universally identical).
UPDATE_MODEL: append-only incident history with versioned corrections and timestamps.
FLOW_HASH: compute from final published UTF-8 bytes during deployment; not asserted here.
CITATION_BACKLINK: source URL above.

12. HOW TO READ
Follow an incident from an observation through evidence checks and controlled decisions. The state model stores context; inference rules propose interpretations; boundaries restrict actions; the recursion engine updates the incident as new evidence arrives.

13. IMPLEMENTATION NOTES
Keep sensitive evidence access-controlled. Preserve timestamps and chain of custody. Distinguish technical containment from legally required notifications. Apply jurisdiction-specific obligations only after verifying current law and the incident facts.

14. DIAGRAM
[Signal] -> [Triage] -> [Evidence validation] -> [Impact assessment]
                                        |
                                        v
                              [Authorised response]
                                        |
                                        v
                             [Containment / recovery]
                                        |
                                        v
                               [Review / audit]
                                        |
                              [Close or reopen]

Licence note: Intended as an open research companion; follow the published Kireth Research licence and citation requirements.