Training Data Leakage Ontology

SEMANTIC LIBRARY — AI CORE — SECURITY ENTITIES
TRAINING DATA LEAKAGE 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/training-data-leakage-ontology.html
Status: Original companion formalisation; the source page title and attribution were verified, but embedded specifications were not available in retrieved text.

1. PURPOSE
Represent, identify, evaluate and mitigate the unintended disclosure of training-set information by an AI system. Distinguish verbatim memorisation, sensitive attribute exposure, membership inference, and authorised release. Treat detected leakage as evidence requiring review, not proof of a particular attack or training record.

2. ENTITY DEFINITION
TrainingDataLeakage = (system, dataset, information, exposure_channel, observation, evidence, affected_party, impact, controls, status, provenance).
Entity types: TrainingDataset, TrainingRecord, SensitiveInformation, ModelOutput, Query, LeakageObservation, ExposureChannel, AccessPolicy, ConsentRecord, EvidenceRecord, RiskAssessment, MitigationControl, IncidentReport, HumanReviewer.
Relations: trainedOn(system,dataset); contains(dataset,record); emittedBy(output,system); reveals(output,information); supportedBy(observation,evidence); governedBy(information,policy); mitigatedBy(risk,control); reviewedBy(incident,reviewer).

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed outputs, authorised test inputs, evaluation context and evidence.
R_t = detection, provenance, classification, validation and mitigation rules.
B_t = privacy, security, consent, authorisation and evidence-quality boundaries.
K_t = verified knowledge of datasets, policies, incidents and prior assessments.
E_t = expand(I_t, R_t)
V_t = {x in E_t : complies(x,B_t) AND supported(x,K_t)}
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)
If V_t is empty, output REVIEW_REQUIRED and do not assert leakage as established fact.

4. FORMAL FLOW ALGEBRA
F1: authorised_observation -> evidence_capture -> provenance_check.
F2: evidence_capture + potential_training_overlap -> candidate_leakage.
F3: candidate_leakage + validated_source_match -> supported_disclosure_finding.
F4: supported_disclosure_finding + policy_context -> authorisation_assessment.
F5: unauthorised_disclosure + impact_assessment -> leakage_incident.
F6: leakage_incident + feasible_controls -> mitigation_plan.
F7: mitigation_plan + human_approval -> controlled_remediation.
F8: remediation + retest + monitoring -> verified_status_update.
All arrows describe guarded transformations, not automatic causal proof.

5. LEAKAGE CATEGORIES
L1: Verbatim reproduction of identifiable training content.
L2: Partial reproduction revealing sensitive details.
L3: Membership information exposure about whether a record was used.
L4: Statistical or attribute inference exposing protected information.
L5: Indirect disclosure through logs, tools, retrieval or generated metadata.
An output resembling public material is not by itself proof of training data leakage.

6. EVIDENCE AND CONFIDENCE
Evidence = (observation_id, timestamp, model_version, test_authorisation, output_digest, comparison_reference, provenance, reviewer).
Evidence strength must account for independent corroboration, alternate sources, false matches, public availability, and evaluation limitations.
Confidence(leakage) = calibrated_assessment(evidence_quality, specificity, reproducibility, alternative_explanations).
Confidence is not a substitute for human review or legal determination.

7. INFERENCE RULES
R01: IF output matches sensitive reference AND reference provenance verified THEN flag candidate.
R02: IF matching content is publicly available THEN lower attribution certainty.
R03: IF dataset membership is unverified THEN do not assert training-set origin.
R04: IF information is consented and authorised for release THEN assess permitted disclosure separately.
R05: IF private information appears without valid authorisation THEN escalate for review.
R06: IF observation is non-reproducible THEN preserve uncertainty.
R07: IF evidence is incomplete THEN status = INDETERMINATE.
R08: IF exposure risk exceeds policy threshold THEN apply approved containment.
R09: IF remediation changes model or access controls THEN retest relevant failure modes.
R10: IF new evidence contradicts a finding THEN reopen assessment.
R11: IF affected parties may be impacted THEN invoke notification review under applicable rules.
R12: IF test exceeds permitted access THEN stop and request authorisation.
R13: IF audit record lacks provenance THEN mark evidence unverified.
R14: IF residual risk remains unacceptable THEN block release pending authorised decision.

8. MINI RECURSION ENGINE
Initialise S_0 and authorised test scope.
At each iteration t:
  Observe permitted outputs and record provenance.
  Expand candidate explanations using R_t.
  Filter by privacy, scope and evidence boundaries B_t.
  Rank supported assessments and propose proportionate controls.
  Request human review for consequential or uncertain cases.
  Update K_(t+1) only with validated findings.
Stop on: verified resolution, reviewer decision, evidence exhaustion, or maximum iteration budget.
Invariant: no new disclosure is justified by a leakage investigation.

9. TRI-MAPPING
Semantic mapping: TrainingDataLeakage -> disclosure event -> affected information -> affected party.
Logical mapping: evidence + policy + provenance -> finding + confidence + review status.
Operational mapping: observe -> validate -> classify -> assess -> contain -> review -> retest.

10. MAPPING TABLE
Entity | Input | Transformation | Output
TrainingRecord | reference provenance | source validation | verified/unverified record
ModelOutput | authorised observation | sensitive-match analysis | candidate exposure
EvidenceRecord | logs and comparisons | integrity validation | evidence status
AccessPolicy | permitted use and scope | authorisation check | allowed/disallowed/unknown
RiskAssessment | likelihood and impact | calibrated evaluation | risk band and rationale
MitigationControl | approved remediation | deployment and test | residual-risk status
IncidentReport | validated findings | human governance review | decision and audit trail

11. EXECUTION CONDITIONS AND GUARANTEE
Preconditions: authorised evaluation; defined scope; trustworthy evidence capture; privacy-safe handling; identified policy authority.
Safety invariants: no unauthorised querying, no disclosure of actual private training records in reports, no automatic accusation, no unreviewed high-impact remediation.
Conditional guarantee: IF inputs are valid, rules terminate, constraints are enforced, and evidence is adequate, the flow yields an auditable classification or an explicit INDETERMINATE/REVIEW_REQUIRED outcome. It does NOT guarantee detection of all leakage, causal proof, or zero residual risk.

12. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.security.training-data-leakage
FLOW_VERSION: 1.0
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/training-data-leakage-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/training-data-leakage-ontology.html
PURPOSE: Interpret and evaluate training data leakage as a security and privacy ontology entity.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: TrainingDataLeakage; TrainingDataset; TrainingRecord; ModelOutput; LeakageObservation; EvidenceRecord; AccessPolicy; RiskAssessment; MitigationControl; HumanReviewer.
PATHWAYS: observe > validate > compare > classify > assess > mitigate > review > retest.
MINI_RECURSION_ENGINE: guarded iterative evidence assessment with human escalation.
INFERENCE_RULES: R01-R14.
CONFIDENCE: calibrated, evidence-dependent, never presumed certain.
SEMANTIC_EQUIVALENCE: training data exposure; memorised data disclosure; training-set information leakage (context dependent).
FLOW_HASH: compute SHA-256 of canonical published TXT after final approval; no hash asserted here.
UPDATE_MODEL: versioned changes, provenance log, human approval for material policy updates.

13. HOW TO READ
Read the ontology entity as the subject; follow F1-F8 as the operational flow; use R01-R14 for guarded decisions; apply B_t before any action; use the tri-mapping to move between concepts, logic and operational evidence. Unknowns remain unknown until supported.

14. OPEN RESEARCH NOTE
Original companion Flow Algebra for the Semantic Library. Open research use with source citation requested. No claim that this file reproduces inaccessible embedded page specifications.