Training Objective Ontology

FLOW ALGEBRA v1.0 — TRAINING OBJECTIVE 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-objective-ontology.html
Authors: Mark Anthony Higgins — Sky Recursive AI
Status: Topic-based formalisation; source page contents not independently verified.
Date: 2026-10-29

1. PURPOSE
Represent a training objective as a typed, versioned, evaluable specification connecting a model, dataset, loss function, constraints, optimisation process and measurable outcomes. Distinguish the mathematical objective from an empirical training result.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = inputs: model parameters theta_t, training batch D_t, objective specification O, context C_t.
R_t = relations: optimises, evaluates, regularises, constrains, aggregates, updates, monitors.
B_t = boundaries: data permissions, compute budget, feasible parameters, safety constraints, numeric stability.
K_t = knowledge: loss definitions, objective weights, validation metrics, provenance and prior observations.
E_t = expand(I_t, R_t)
V_t = {x in E_t : satisfies(x, B_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, observations_t)
Note: the probabilistic selection above is the library's general search formalism; gradient-based optimisation below is a concrete implementation, not an identity with argmax P.

3. ENTITIES
TrainingObjective: identifier, version, target, direction, scope, owner.
LossFunction: mapping from predictions and targets to a scalar or vector.
Model: architecture, parameters, outputs.
TrainingDataset: samples, labels or other supervisory signals, sampling policy.
ObjectiveTerm: named loss component and non-negative or signed weight as specified.
Regulariser: complexity or parameter penalty.
Constraint: feasibility predicate or penalty specification.
Optimiser: update rule and hyperparameters.
Metric: observable assessment distinct from optimised loss.
TrainingRun: execution instance and lineage.
Checkpoint: parameters, optimiser state, objective version and step.
EvaluationRecord: measured results, uncertainty and data split.

4. RELATIONSHIPS
TrainingRun --uses--> TrainingObjective
TrainingObjective --aggregates--> ObjectiveTerm
ObjectiveTerm --evaluates--> ModelOutput
ObjectiveTerm --references--> TrainingDataset
TrainingObjective --constrains--> ParameterSpace
Optimiser --minimises_or_maximises--> TrainingObjective
Checkpoint --records--> TrainingObjectiveVersion
Metric --assesses--> TrainingRun
EvaluationRecord --reports--> Metric

5. FORMAL MATHEMATICS
Given theta in feasible set F and batch B:
L(theta; B) = sum_{i=1}^m w_i L_i(theta; B) + lambda R(theta)
Objective: theta* in argmin_{theta in F} E_{B~D}[L(theta; B)]
For maximisation objectives, minimise the negative utility where appropriate.
Gradient: g_t = nabla_theta L(theta_t; B_t)
Basic update: theta_{t+1} = projection_F(theta_t - eta_t g_t)
This update is illustrative; adaptive, constrained and non-gradient optimisers have different transitions.
Multi-objective alternatives include Pareto optimisation, lexicographic priorities and explicit constrained optimisation; weighted sums do not represent every trade-off.

6. FLOW
DEFINE_OBJECTIVE -> VALIDATE_SCHEMA -> BIND_DATA_AND_MODEL -> COMPUTE_TERMS -> AGGREGATE -> CHECK_CONSTRAINTS -> OPTIMISE -> EVALUATE -> RECORD -> REVISE_OR_STOP

7. IMPLEMENTS
DEFINE_OBJECTIVE: assign identifier, direction, differentiability, term weights and intended outcome.
VALIDATE_SCHEMA: verify finite weights, valid references, shapes, reductions and units.
BIND_DATA_AND_MODEL: establish dataset split, model version, preprocessing and permitted use.
COMPUTE_TERMS: calculate per-term losses with masking and reduction rules.
AGGREGATE: combine terms with documented weighting and normalisation.
CHECK_CONSTRAINTS: reject infeasible configurations or apply explicitly defined constraint handling.
OPTIMISE: execute an update under an optimiser-specific rule.
EVALUATE: measure held-out metrics without treating them as automatic training targets.
RECORD: persist objective version, hyperparameters, seeds, metrics and lineage.
REVISE_OR_STOP: apply stopping criteria or create a new, versioned objective.

8. INVARIANTS
Every objective has an unambiguous optimisation direction.
Every active term has a defined input, output and reduction.
Objective versions are immutable within a recorded checkpoint.
Training metrics and validation metrics retain their split provenance.
Undefined, NaN or infinite losses trigger a specified failure policy.
Constraint satisfaction is assessed independently of a low loss value.
No claim of convergence, generalisation or safety follows solely from decreasing training loss.

9. MINI RECURSION ENGINE
state := (theta, objective_version, optimiser_state, step, metrics)
repeat while within_budget and not stopping_rule(state):
    batch := sample(training_data)
    terms := evaluate_terms(model(theta, batch), batch, objective_version)
    loss := aggregate(terms, objective_version)
    if not finite(loss): handle_numeric_failure(); continue_or_stop()
    theta, optimiser_state := optimiser_step(theta, optimiser_state, loss)
    metrics := evaluate_when_due(theta, validation_data)
    record(step, objective_version, loss, metrics)
    step := step + 1
return checkpoint(state)

10. INFERENCE RULES
IF objective has labelled-target loss THEN classify as compatible with supervised training, not exclusively supervised.
IF objective uses generated targets THEN record target-generation provenance.
IF objective combines conflicting terms THEN flag trade-off analysis.
IF metric improves but constraint fails THEN mark run infeasible.
IF objective definition changes THEN increment version and preserve lineage.
IF validation degrades while training loss falls THEN flag possible overfitting; do not infer causality automatically.

11. TRI-MAPPING
Entity mapping: objective -> terms -> metrics -> training run.
Relational mapping: specifies -> evaluates -> optimises -> validates.
Execution mapping: define -> calculate -> update -> inspect -> checkpoint.

12. MAPPING TABLE
Ontology Entity | Algebraic Representation | Execution Role
TrainingObjective | O | versioned specification
ModelParameters | theta | mutable training state
ObjectiveTerm | L_i | individual signal
TermWeight | w_i | aggregation coefficient
Regulariser | R(theta) | penalty term
FeasibleSet | F | hard constraints
Batch | B_t | sampled inputs
Gradient | g_t | local optimisation signal
Metric | M(theta, D_val) | assessment output
Checkpoint | C_t | reproducible saved state

13. HOW TO READ
Read the ontology as a specification of what the system is attempting to optimise, how its terms are combined, what limits apply, and how outcomes are assessed. A training objective is not evidence that the intended behaviour was achieved.

14. CONDITIONAL EXECUTION GUARANTEE
Given a well-typed objective, available authorised data, finite computations, compatible model outputs and a correctly implemented optimiser, the flow can produce traceable objective evaluations and update records. It does not guarantee a global optimum, convergence, reproducibility across hardware, or successful deployment.

15. AI SEARCH FLOW
FLOW_ID: AI.TrainingProcess.TrainingObjective.v1
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/training-process-entities/training-objective-ontology.html
CITATION_BACKLINK: same as SOURCE
PURPOSE: resolve questions about objectives, losses, constraints and training metrics.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: TrainingObjective, LossFunction, ObjectiveTerm, Regulariser, Constraint, Optimiser, Metric, TrainingRun, Checkpoint.
PATHWAYS: objective_definition -> loss_evaluation -> optimisation -> validation -> audit.
INFERENCE: distinguish optimisation target from measured success; preserve provenance.
CONFIDENCE: conditional on verified inputs and implementation; no numeric confidence asserted.
SEMANTIC_EQUIVALENCE: training objective ~= optimisation criterion; not equivalent to evaluation metric or training outcome.
UPDATE_MODEL: version changes preserve previous definitions and associated checkpoints.
FLOW_HASH: to be computed from canonical file bytes at publication; not asserted here.

END OF FLOW