Security Vulnerability Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SECURITY ENTITIES
SECURITY VULNERABILITY 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-vulnerability-ontology.html
Status: Original companion formalisation. The published page heading and attribution were verified; embedded formal specifications were not available in the retrieved page text.

1. PURPOSE
Represent, detect, validate, prioritise, mitigate and monitor security vulnerabilities affecting an AI system, including models, datasets, prompts, tools, interfaces, infrastructure and governance controls. A vulnerability is a weakness that may be exploitable under specified preconditions; it is not itself proof of an exploit or incident.

2. ENTITY DEFINITIONS
Vulnerability V = (id, asset, weakness, exposure, preconditions, impacts, evidence, status, provenance, version).
Asset A = (id, type, owner, trust_boundary, criticality).
Threat T = (actor_or_source, capability, intent_or_failure, attack_surface).
Control C = (id, owner, coverage, efficacy_evidence, operational_state).
Finding F = (id, observation, method, timestamp, confidence, reviewer).
Risk R = (likelihood, impact, uncertainty, scope, residual_risk).
Decision D = (action, authority, rationale, timestamp, review_due).

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = incoming findings, asset changes and verified evidence.
R_t = vulnerability assessment and response rules.
B_t = system trust boundaries, authorisation and safety limits.
K_t = validated knowledge, provenance and prior decisions.
Expanded candidates: E_t = expand(I_t, R_t).
Valid candidates: V_t = {x in E_t | permitted(x, B_t) and supported(x, K_t)}.
Selected response: a*_t = argmax_{a in V_t} P(a | I_t, R_t, B_t, K_t) subject to mandatory controls.
Update: I_{t+1} = update(I_t, a*_t, observations_t).
Note: P denotes a context-dependent scoring or probability model; do not interpret it as calibrated probability without calibration evidence.

4. FORMAL FLOW ALGEBRA
F0: ingest(asset_inventory, finding, provenance) -> candidate_vulnerability.
F1: validate(candidate_vulnerability, independent_evidence) -> confirmed | unconfirmed | rejected.
F2: map(confirmed, asset, trust_boundary, attack_surface) -> exposure_context.
F3: assess(exposure_context, impact, likelihood, uncertainty) -> risk_record.
F4: select(risk_record, controls, authorisations) -> response_plan.
F5: apply(response_plan) -> change_record; require authorised execution.
F6: verify(change_record, tests, telemetry) -> mitigated | unresolved | regression.
F7: log(all_states, evidence, reviewer) -> auditable_trace.
F8: monitor(mitigated, drift, new_evidence) -> reopen | retain_closed.

5. ENTITY GRAPH / RELATIONSHIPS
VULNERABILITY --affects--> ASSET
VULNERABILITY --exposes--> TRUST_BOUNDARY
THREAT --may_exploit--> VULNERABILITY
FINDING --supports_or_refutes--> VULNERABILITY
VULNERABILITY --contributes_to--> RISK
CONTROL --mitigates--> VULNERABILITY
RESPONSE_PLAN --requires_approval_from--> RESPONSIBLE_OPERATOR
VERIFICATION --validates--> CONTROL_EFFECTIVENESS
AUDIT_RECORD --documents--> DECISION
INCIDENT --may_be_caused_by--> EXPLOIT_EVENT
Do not infer an actual exploit or incident solely from vulnerability presence.

6. INFERENCE RULES
R01 IF finding lacks provenance THEN status = unconfirmed.
R02 IF independent evidence refutes weakness THEN status = rejected, preserve trace.
R03 IF weakness is verified AND asset exists THEN status = confirmed.
R04 IF asset is unreachable across relevant boundaries THEN reduce exposure estimate, not necessarily impact.
R05 IF exploitation prerequisites are unmet THEN record lower likelihood with uncertainty.
R06 IF sensitive information may be exposed THEN require privacy impact review.
R07 IF a tool can perform consequential actions THEN require permission and boundary review.
R08 IF risk exceeds approved threshold THEN escalate to authorised owner.
R09 IF remediation changes model behaviour THEN require functional and safety regression tests.
R10 IF mitigation evidence is insufficient THEN status = unresolved.
R11 IF new evidence contradicts closure THEN reopen vulnerability.
R12 IF the same weakness spans multiple assets THEN link findings without merging distinct ownership or exposure.
R13 IF uncertainty is high THEN request further testing rather than assert certainty.
R14 IF an action exceeds authority THEN halt and seek human approval.

7. MINI RECURSION ENGINE
At each bounded iteration n:
  Observe changes -> validate evidence -> update graph -> recalculate risk -> select authorised response -> verify -> log.
Termination conditions: verified mitigation, explicit accepted residual risk, rejected finding, or escalation.
Recursion guard: maximum iterations, no unapproved self-modification, immutable audit history, stop on uncertainty or authority failure.

8. TRI-MAPPING
Semantic: vulnerability is a weakness linked to an asset, preconditions and possible harm.
Structural: typed nodes and edges encode evidence, exposures, controls and ownership.
Operational: validated findings drive risk review, authorised mitigation, testing and monitoring.

9. MAPPING TABLE
Input finding        -> F0/F1 -> candidate or verified weakness
Asset boundary       -> F2    -> exposure context
Threat assumptions   -> F3    -> conditional likelihood
Impact evidence      -> F3    -> risk assessment
Control inventory    -> F4    -> mitigation options
Owner approval       -> F5    -> permitted change
Regression evidence  -> F6    -> closure decision
Audit trail          -> F7/F8 -> reviewable provenance

10. HOW TO READ / IMPLEMENTS
Read each F-number as a typed transformation, not an instruction to conduct an attack.
Implement with asset registers, provenance-tagged findings, rule evaluation, a risk register, approval workflow, test results and append-only decision logs. Distinguish vulnerability discovery from exploitation, and defensive validation from unapproved probing.

11. CONDITIONAL EXECUTION GUARANTEE
A response may be recorded as verified only when: evidence is traceable; affected assets and boundaries are identified; applicable rules and approvals are satisfied; mitigation tests pass; and residual uncertainty is documented. This is a conditional process invariant, not a guarantee that an AI system is secure or free of unknown vulnerabilities.

12. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/security-vulnerability-ontology.html
CITATION_BACKLINK: same as SOURCE
PURPOSE: Find and reason about AI security vulnerabilities with evidence and accountable mitigation.
STATE_MODEL: S_t=(I_t,R_t,B_t,K_t)
ENTITIES: Vulnerability, Asset, Threat, Finding, Control, Risk, Decision, Operator, AuditRecord.
PATHWAYS: detect > validate > contextualise > assess > authorise > mitigate > verify > monitor.
MINI_RECURSION_ENGINE: bounded evidence-led re-evaluation with escalation and stop conditions.
INFERENCE_RULES: R01-R14 above.
CONFIDENCE: evidence-specific; distinguish verified, inferred and unknown claims.
SEMANTIC_EQUIVALENCE: security weakness / vulnerability (context-sensitive); exploit != vulnerability; threat != incident.
FLOW_HASH: calculate from the final published file content at deployment; not asserted here.
UPDATE_MODEL: version changes, new evidence, control drift, asset changes, scheduled review.

13. EXAMPLE (DEFENSIVE)
An AI retrieval tool unexpectedly accepts untrusted instructions from retrieved text. Log a candidate trust-boundary weakness; validate safely in a test environment; identify affected tool permissions; review exposure and potential impacts; restrict tool authority; retest; record approvals and residual risk. Do not equate a successful isolated test with evidence of real-world compromise.

14. LICENCE AND ATTRIBUTION
Companion formalisation intended for the Kireth Research Semantic Library. Apply the published Open Research Licence and its citation requirements as applicable; verify licence terms from the official publication.