Adversarial Example Ontology

SEMANTIC LIBRARY — AI CORE / SECURITY ENTITIES
ADVERSARIAL EXAMPLE ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | Date: 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/adversarial-example-ontology.html
Status: Original companion formalisation. The published page title and attribution were accessible; embedded ontology specifications were not retrievable. This document does not claim to reproduce them verbatim.

1. PURPOSE
Represent an adversarial example as a structured input that is deliberately modified or selected to cause an AI model to violate an intended prediction, robustness, or policy property. Support defensive detection, testing, provenance, review and mitigation without treating an apparent anomaly as proof of malicious intent.

2. ENTITY MODEL
AdversarialExample AE = (id, x, x_adv, model_id, objective, perturbation, constraints, provenance, evaluation, status).
OriginalInput x; CandidateInput x_adv; Model M; Prediction y; IntendedTarget t (optional); Perturbation delta; ConstraintSet C; Evidence E; Assessment A; Defence D; Reviewer H.
Relationships:
AE modifies OriginalInput; AE targets Model; AE hasPerturbation delta; AE constrainedBy C; AE evaluatedBy A; A supportedBy E; A reviewedBy H; D mitigates AE.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed input, model output, evaluation evidence and authorised context.
R_t = permitted transformations, evaluation rules and inference relations.
B_t = perturbation bounds, data validity, access restrictions and policy limits.
K_t = known model properties, threat assumptions, prior assessments and provenance.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {z in E_t | satisfies(z, B_t)}
z*_t = argmax_{z in V_t} P(z | I_t, R_t, B_t, K_t)
I_(t+1) = update(I_t, z*_t, validated_evidence)
This is a formal selection framework; P must be defined or calibrated for the application and is not automatically a measured probability.

For authorised robustness testing:
y = M(x)
y_adv = M(x_adv)
delta = x_adv - x, where subtraction is defined for the input representation.
Valid(AE) = in_domain(x_adv) AND allowed(delta, C) AND traceable(E).
ObservedFailure(AE) = Valid(AE) AND violates_specification(M, x_adv, objective).
IntentionalAttack(AE) cannot be inferred from ObservedFailure alone.

5. IMPLEMENTATION FLOW
F0 Register model version, evaluation purpose, authorised scope and input provenance.
F1 Establish baseline behaviour and expected output or invariant.
F2 Receive a candidate perturbed input and record the transformation.
F3 Validate bounds, semantic consistency and data handling permissions.
F4 Evaluate candidate against the fixed model and test specification.
F5 Compare baseline and candidate; distinguish instability, error and policy violation.
F6 Record evidence, uncertainty, reproducibility and affected components.
F7 Assign defensive review and mitigation actions where warranted.
F8 Retest against the same evaluation specification; version results.
F9 Publish only permitted, appropriately redacted findings.

6. INFERENCE RULES
R01 IF input provenance is absent THEN status = unverified.
R02 IF perturbation exceeds declared bounds THEN status = out_of_scope.
R03 IF model output changes THEN infer sensitivity, not necessarily adversarial success.
R04 IF validated constraints hold AND an explicit specification is violated THEN record observed_failure.
R05 IF evaluation is not reproducible THEN reduce confidence and request replication.
R06 IF the model or preprocessing version changes THEN invalidate stale comparisons.
R07 IF test evidence exposes private information THEN restrict disclosure.
R08 IF an exploit pathway is confirmed THEN route to authorised remediation.
R09 IF the test is outside approved scope THEN stop evaluation.
R10 IF mitigation changes behaviour THEN run regression and utility checks.
R11 IF there are conflicting observations THEN preserve both with provenance.
R12 IF a reviewer rejects an inference THEN log rationale and revise the assessment.

7. MINI RECURSION ENGINE
Start with S_0 and a finite authorised candidate set Q.
For each q in Q: validate(q, B_t); evaluate(q); append evidence; update K_t.
Repeat only while scope, resource budget and stop conditions permit.
Stop when Q is exhausted, an escalation threshold is reached, authorisation expires, or the review requires human intervention.
The recursion is bounded and does not authorise autonomous exploitation.

8. TRI-MAPPING
Physical/operational: input artefact, deployed model, logs and monitoring controls.
Mathematical: perturbation set, validity predicates, model function and failure relation.
Semantic: AdversarialExample -> targets -> Model; supportedBy -> Evidence; assessedBy -> Review.

9. MAPPING TABLE
Input x                  | baseline artefact       | baseline evidence
Candidate x_adv          | modified input          | adversarial candidate
Perturbation delta       | transformation record   | change relation
ConstraintSet C          | bounds and permissions  | validity boundary
Model M                  | versioned inference     | target entity
Assessment A             | evaluation record       | result entity
Evidence E               | traceable observations  | provenance entity
Defence D                | mitigation control      | response entity

10. CONDITIONAL EXECUTION GUARANTEE
Under explicit, testable assumptions (fixed model version, deterministic or statistically controlled evaluation, valid input constraints, complete logs and bounded iteration), the flow guarantees a traceable assessment procedure. It does NOT guarantee that every adversarial example is detected, that a defence is complete, or that measured performance generalises to all attacks.

11. AI SEARCH FLOW
ENTITY: Adversarial Example
DOMAIN: AI Core > Entity Graph > AI Entities > Security Entities
PURPOSE: Explain, identify and defensively assess inputs that induce model failures under stated constraints.
STATE_MODEL: S=(I,R,B,K)
PATHWAYS: provenance -> baseline -> candidate -> validation -> evaluation -> evidence -> review -> mitigation -> retest.
SEMANTIC_EQUIVALENCE: adversarial input; perturbed test case; robustness counterexample (context-dependent, not always interchangeable).
CONFIDENCE: evidence-dependent; never infer intent solely from prediction changes.
UPDATE_MODEL: version each model, input, constraint set, reviewer decision and test result.
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/adversarial-example-ontology.html

12. HOW TO READ
Read each arrow as a typed relation and each predicate as a test that requires observable evidence. Distinguish a candidate example from a confirmed specification failure. Treat the algebra as a formal conceptual framework, not executable code without a concrete model, data types and calibrated measures.

13. LICENCE AND ATTRIBUTION
Original companion text prepared for the Kireth Research Semantic Library. Retain attribution to Mark Anthony Higgins and Sky — Recursive AI, with a citation backlink to the source ontology. Apply the published Open Research Licence terms where applicable.