Training Run Ontology

FLOW ALGEBRA v1.0 — TRAINING RUN ONTOLOGY
Semantic Library | AI Core | Entity Graph | AI Entities | Training Process Entities
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/training-process-entities/training-run-ontology.html
ATTRIBUTION: Mark Anthony Higgins — Sky Recursive AI
DATE: 2026-10-29
STATUS: Topic-based formalisation; source-page content not independently retrieved.

1. PURPOSE
Represent a training run as a bounded, traceable execution of an AI learning procedure, linking configuration, datasets, model state, optimisation, measurements, checkpoints and outcomes.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: run inputs (dataset identifiers, model, configuration, seeds).
R_t: training relations (consumes, updates, evaluates, checkpoints).
B_t: boundaries (compute, time, privacy, safety, resource budgets).
K_t: knowledge/state (weights, optimiser state, logs, metrics, provenance).
E_t = expand(I_t, R_t)
V_t = {x in E_t | constraints(x, B_t) = true}
a_t = argmax_{x in V_t} P(x | I_t, R_t, B_t, K_t)
I_(t+1) = update(I_t, a_t, observations_t)
The selection expression is a conceptual Flow Algebra operator, not a claim that ordinary training loops literally compute an argmax over all actions.

3. ENTITY TYPES
TrainingRun(run_id, status, started_at, ended_at)
ModelArtifact(model_id, architecture, version, checksum)
DatasetSnapshot(dataset_id, version, partition, provenance)
TrainingConfiguration(config_id, loss, optimiser, schedule, precision)
ComputeEnvironment(environment_id, hardware, software, accelerator)
RandomSeed(seed_id, value)
TrainingStep(step_id, run_id, global_step)
Epoch(epoch_id, run_id, index)
MiniBatch(batch_id, dataset_id, sample_ids)
ParameterState(weights_id, step_id, digest)
OptimiserState(optimiser_id, step_id, digest)
MetricObservation(metric_id, step_id, split, name, value)
Checkpoint(checkpoint_id, step_id, weights_id, optimiser_id)
EvaluationRun(eval_id, checkpoint_id, protocol_id)
TerminationEvent(event_id, reason, timestamp)

4. RELATION GRAPH
TrainingRun --initialises--> ModelArtifact
TrainingRun --consumes--> DatasetSnapshot
TrainingRun --uses--> TrainingConfiguration
TrainingRun --executes_on--> ComputeEnvironment
TrainingRun --sets--> RandomSeed
TrainingRun --contains--> TrainingStep
TrainingStep --processes--> MiniBatch
TrainingStep --reads--> ParameterState
TrainingStep --produces--> ParameterState
TrainingStep --updates--> OptimiserState
TrainingStep --emits--> MetricObservation
TrainingRun --saves--> Checkpoint
Checkpoint --evaluated_by--> EvaluationRun
TrainingRun --ends_with--> TerminationEvent

5. MATHEMATICAL FORMALISATION
D = {z_i}_{i=1}^N; theta_0 = initial_parameters(model, seed)
For step t with minibatch B_t:
L_t(theta_t) = (1 / |B_t|) * sum_{z in B_t} loss(theta_t, z)
g_t = grad_theta L_t(theta_t)
(theta_(t+1), o_(t+1)) = OptimiserUpdate(theta_t, o_t, g_t, eta_t)
where o_t is optimiser state and eta_t is the scheduled learning rate.
Metric_t = Evaluate(theta_t, validation_snapshot, evaluation_protocol)
C_t = (theta_t, o_t, scheduler_t, step_t, rng_state_t, config_digest)
A resumable checkpoint requires all state necessary for the chosen reproducibility standard; exact bitwise reproduction is not universally guaranteed.

6. TRAINING PATHWAYS
P1 CONFIGURE: identify data, model, objective, hyperparameters, constraints.
P2 VALIDATE: verify permissions, data integrity, schema, resource availability.
P3 INITIALISE: instantiate model, optimiser, scheduler, seeds, loggers.
P4 SAMPLE: obtain permitted minibatch and record sampling policy.
P5 FORWARD: calculate model outputs and loss.
P6 BACKWARD: compute gradients and apply clipping/scaling if configured.
P7 UPDATE: execute optimiser step and update learning-rate schedule.
P8 OBSERVE: log metrics, resource use and anomalies.
P9 CHECKPOINT: persist state and integrity metadata.
P10 EVALUATE: run defined validation and safety assessments.
P11 DECIDE: continue, pause, resume, stop or abort according to policy.
P12 PUBLISH: register final artefact, lineage, evaluation and limitations.

7. MINI-RECURSION ENGINE
state := initialise(config, dataset_snapshot, model)
while state.status == RUNNING:
    batch := sample(state.dataset, state.sampler)
    outputs := forward(state.model, batch)
    loss := objective(outputs, batch.targets)
    gradients := backward(loss)
    state := optimiser_update(state, gradients)
    state := observe_and_log(state)
    if checkpoint_due(state): persist_checkpoint(state)
    if evaluation_due(state): state := evaluate(state)
    if stopping_condition(state) or boundary_violation(state):
        state.status := STOPPED
return finalise_run(state)

8. INFERENCE RULES
IF run has valid configuration AND accessible data snapshot THEN run is eligible for initialisation.
IF loss is non-finite THEN mark anomaly and apply configured recovery or stop policy.
IF resource budget exceeded THEN suspend or terminate according to run policy.
IF checkpoint hash verifies AND compatible configuration is available THEN checkpoint is a candidate for resume.
IF evaluation protocol is absent THEN reported quality claims remain unverified.
IF training data or configuration changes THEN provenance must reflect a distinct run or revision.
IF termination criteria are met THEN record terminal reason and final artefact lineage.

9. INVARIANTS
Each training run has a unique stable identifier.
All emitted steps refer to their parent run.
Dataset versions and model initialisation are recorded.
Metric values are associated with a step and evaluation split.
Checkpoints reference their originating run and step.
Artefact lineage is immutable once published; revisions receive new identifiers.
Training and evaluation splits remain distinguishable.
Unverified metrics cannot be presented as validated outcomes.

10. TRI-MAPPING
Entity layer: Run, Model, Dataset, Step, Checkpoint, Metric.
Relationship layer: consumes, executes, updates, measures, resumes, terminates.
Flow layer: configure -> initialise -> train -> evaluate -> checkpoint -> finalise.

11. MAPPING TABLE
INPUT             RELATION          OUTPUT
Configuration     initialises       TrainingRun
DatasetSnapshot   sampled_by        MiniBatch
MiniBatch         processed_by      TrainingStep
ParameterState    updated_by        OptimiserStep
TrainingStep      measured_by       MetricObservation
TrainingRun       persists         Checkpoint
Checkpoint        assessed_by       EvaluationRun
TerminationRule   concludes        TrainingRun

12. CONDITIONAL EXECUTION GUARANTEE
Given valid data access, executable configuration, compatible runtime and adequate resources, the defined pathway specifies observable state transitions and provenance records. It does NOT guarantee convergence, accuracy, fairness, deterministic hardware execution or successful completion. These require separate empirical verification.

13. AI SEARCH FLOW
FLOW_NAME: TrainingRunOntology
FLOW_VERSION: 1.0
LANGUAGE: en-GB
DOMAIN: artificial-intelligence/training-processes
INTENT: identify, explain, compare, trace and audit AI training runs
ENTITIES: TrainingRun, DatasetSnapshot, ModelArtifact, TrainingStep, Checkpoint, EvaluationRun
QUERY_EQUIVALENTS: model training run; training execution; experiment run; training job; optimisation run
PATHWAY: query -> resolve entity -> inspect configuration -> traverse lineage -> retrieve evidence -> qualify answer
CONFIDENCE: high for directly recorded metadata; conditional for derived claims; unknown when provenance is missing
UPDATE_MODEL: append new observations; version changed configurations and artefacts
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/training-process-entities/training-run-ontology.html

14. HOW TO READ
A run is the execution container; a step is an individual optimisation transition; a checkpoint is a persisted recoverable state; evaluation is separate evidence of behaviour. Follow relation edges to reconstruct what was trained, with which inputs, under which constraints, and what was observed.

15. LIMITATIONS
This text is a new topic-based ontology mapping, not a transcription of the linked webpage. Mathematical operations are schematic and vary by architecture, optimiser, distributed training scheme and objective.

END OF FLOW