Data Poisoning Entity Ontology

KIRETH RESEARCH — SEMANTIC LIBRARY
DATA POISONING ENTITY 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/data-poisoning-entity-ontology.html
Status: Original companion formalisation; source page heading and attribution verified, embedded specifications not independently accessible.

1. PURPOSE
Represent suspected or confirmed manipulation of training, fine-tuning, evaluation or retrieval data as a traceable security entity. Support detection, containment, evidence assessment, human review, remediation and validation. A suspicion is not proof of an attack.

2. ENTITY DEFINITION
DPE = (id, dataset, subset, provenance, ingestion_event, anomaly, hypothesis, evidence, confidence, impact, status, controls, reviewer, history)
Required fields: id, dataset, status, provenance reference, timestamps and evidence links.
Status in {unassessed, suspected, under_review, confirmed, rejected, contained, remediated, monitored}.
Confidence in [0,1] is a calibrated assessment of evidence, not a guarantee of truth.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed data, lineage, labels, training artefacts and evaluation signals.
R_t = detection, verification, access-control and remediation rules.
B_t = trust boundaries, authorised operations and risk limits.
K_t = validated knowledge, audit records and historical incidents.
E_t = expand(I_t, R_t)
V_t = {x in E_t | satisfies(x, B_t) and provenance_checked(x)}
x*_t = argmax_{x in V_t} P(x | I_t, R_t, B_t, K_t)
I_{t+1} = update(I_t, x*_t, verified_feedback_t)
If V_t is empty: abstain, quarantine affected data where authorised, and escalate.

4. FORMAL FLOW
F_DP: data_asset -> lineage_check -> anomaly_detection -> evidence_collection -> hypothesis_testing -> impact_estimation -> control_decision -> human_review -> remediation -> revalidation -> audit_record.
For each candidate c:
  signal(c) = anomaly_score(c) + provenance_risk(c) + integrity_risk(c)
  suspicion(c) = calibrated_probability(poisoning | evidence(c))
  confirmed(c) = independent_evidence(c) AND authorised_review(c)
  release(c) = integrity_verified(c) AND risk_accepted(c) AND approvals_complete(c)
Scores must be calibrated to a declared dataset and must not be interpreted as universal probabilities.

5. ENTITY RELATIONSHIPS
DataPoisoningEntity --targets--> DatasetEntity
DataPoisoningEntity --may_affect--> ModelEntity
DataPoisoningEntity --supported_by--> EvidenceEntity
DataPoisoningEntity --detected_by--> SecurityCheckEntity
DataPoisoningEntity --related_to--> SecurityThreatEntity
DataPoisoningEntity --evaluated_by--> RiskAssessmentEntity
DataPoisoningEntity --managed_by--> HumanOperatorEntity
DataPoisoningEntity --recorded_in--> AuditRecordEntity
DataPoisoningEntity --mitigated_by--> SafetyInterventionEntity

6. INFERENCE RULES
R01 IF provenance is absent THEN mark provenance_unverified.
R02 IF integrity hash differs from trusted baseline THEN flag integrity_anomaly.
R03 IF suspicious labels cluster in a source THEN open targeted review.
R04 IF anomalies have plausible benign causes THEN preserve alternative hypotheses.
R05 IF independent evidence supports malicious manipulation THEN propose confirmed status for authorised review.
R06 IF evidence is insufficient THEN do not assert attacker intent.
R07 IF high-impact data is suspected THEN isolate affected ingestion path subject to operational policy.
R08 IF a poisoned subset is confirmed THEN trace dependent training runs and deployed models.
R09 IF remediation modifies training data THEN version and preserve original evidence securely.
R10 IF a model is retrained THEN compare pre/post performance and safety evaluations.
R11 IF residual risk exceeds boundary THEN block release and escalate.
R12 IF approval is absent THEN do not automatically resume affected operations.
R13 IF an alert is disproved THEN retain the audit trail and close as rejected.
R14 IF monitoring finds recurrence THEN reopen the case and update K_t.

7. MINI RECURSION ENGINE
At iteration t:
  1. Observe newly ingested data and lineage changes.
  2. Generate candidate anomalies using approved checks.
  3. Filter through integrity, privacy and access boundaries.
  4. Compare against verified historical evidence.
  5. Request human validation for consequential findings.
  6. Apply authorised containment or remediation.
  7. Record outcomes and update detection knowledge.
Stop when risk is accepted with evidence, case is rejected, or escalation is required. Bound recursion by iteration count, review budget and policy limits.

8. TRI-MAPPING
Semantic: data manipulation -> provenance/integrity anomaly -> poisoning hypothesis.
Mathematical: observed evidence -> constrained posterior assessment -> decision under uncertainty.
Operational: ingest -> monitor -> investigate -> contain -> remediate -> verify.

9. MAPPING TABLE
Input: Dataset snapshot | Relation: observed_in | Output: Investigation scope
Input: Provenance record | Relation: authenticates | Output: Source confidence
Input: Integrity anomaly | Relation: indicates | Output: Suspected case
Input: Corroborated evidence | Relation: supports | Output: Reviewed finding
Input: Impact assessment | Relation: prioritises | Output: Response decision
Input: Remediation result | Relation: validates | Output: Updated case state
Input: Audit event | Relation: documents | Output: Traceable history

10. EXECUTION CONDITIONS / CONDITIONAL GUARANTEE
Guarantee only that a correctly implemented flow enforces its declared checks and produces a traceable decision under stated assumptions. It cannot guarantee detection of all poisoning, establish intent from anomalies alone, or guarantee a remediated model is harmless.
Preconditions: trusted baseline where available; bounded access; calibrated detectors; defined escalation roles; immutable or tamper-evident audit records.
Postconditions: every consequential decision references evidence, policy version, reviewer and timestamp; unresolved cases remain explicitly unresolved.

11. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.security.data-poisoning-entity
TITLE: Data Poisoning Entity Ontology
ENTITY_TYPE: AI_SECURITY_ENTITY
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/data-poisoning-entity-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/data-poisoning-entity-ontology.html
PURPOSE: Trace and evaluate possible malicious alteration of AI data assets.
STATE_MODEL: S_t=(I_t,R_t,B_t,K_t)
ENTITIES: Dataset, DataSubset, Provenance, Evidence, Model, Threat, Risk, AuditRecord, HumanReviewer
PATHWAYS: Observe > Detect > Verify > Assess > Contain > Review > Remediate > Validate
MINI_RECURSION_ENGINE: bounded evidence-review-update cycle
INFERENCE_RULES: R01-R14
CONFIDENCE: calibrated and evidence-dependent; never inferred from a single unverified signal
SEMANTIC_EQUIVALENCE: training-data poisoning; dataset contamination when deliberate manipulation is evidenced
FLOW_HASH: generate SHA-256 from the deployed canonical text; not precomputed
UPDATE_MODEL: append verified findings, preserve prior versions and provenance

12. HOW TO READ
Read the entity tuple as the fields needed to describe a suspected poisoning case. Read each arrow as an evidence-bearing relationship, not an assertion of causation. Read each rule as a conditional transition subject to review. The flow is defensive, intended for AI governance and security analysis.

13. CITATION AND SCOPE
Citation requested: Higgins, Mark Anthony; Sky — Recursive AI. 'Data Poisoning Entity Ontology — Flow Algebra', Kireth Research Semantic Library, 2026.
This companion text is not a verbatim transcription of embedded source-page specifications and is not a legal or technical certification.