Instruction Tuning Ontology

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

1. PURPOSE
Represent instruction tuning as a structured, auditable training process that adapts a pretrained model to follow instructions using instruction-response examples, with explicit constraints, provenance and evaluation.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t := current instruction-tuning process state, including model parameters and dataset cursor.
R_t := transformation and training rules (tokenisation, loss, optimisation, validation).
B_t := boundaries (compute, privacy, policy, data licence, safety, time).
K_t := knowledge (dataset metadata, model architecture, checkpoints, evaluation history).
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, feedback_t)
NOTE: The argmax expresses an abstract selection operator; practical gradient training uses minibatch optimisation rather than exhaustive candidate enumeration.

3. ENTITY SET
E01 InstructionTuningProcess: a training run that optimises instruction following.
E02 BaseModel: pretrained parameterised model M_theta.
E03 Instruction: user/task directive.
E04 Context: optional supporting information for the directive.
E05 TargetResponse: reference response or response sequence.
E06 InstructionExample: tuple (instruction, context, target, metadata).
E07 InstructionDataset: collection of examples with split and provenance.
E08 Tokeniser: maps text to token IDs.
E09 PromptTemplate: serialises roles, instructions and context.
E10 TrainingObjective: conditional next-token cross-entropy or documented alternative.
E11 Optimiser: parameter update procedure.
E12 TrainingConfiguration: learning rate, batch size, epochs, schedule, seed.
E13 Checkpoint: model and optimiser state at a step.
E14 ValidationSet: held-out instruction examples.
E15 EvaluationSuite: measures quality, safety and robustness.
E16 PolicyConstraint: restrictions on training data or output behaviour.
E17 DataProvenance: origin, licence, consent and processing lineage.
E18 FineTunedModel: model produced by instruction tuning.
E19 FeedbackRecord: observations from tests or human review.
E20 DeploymentGate: criteria for acceptance or rejection.

4. RELATIONSHIPS
InstructionTuningProcess USES BaseModel.
InstructionTuningProcess CONSUMES InstructionDataset.
InstructionDataset CONTAINS InstructionExample.
InstructionExample HAS Instruction, optional Context and TargetResponse.
PromptTemplate FORMATS InstructionExample.
Tokeniser ENCODES formatted examples.
TrainingObjective COMPARES model predictions WITH TargetResponse tokens.
Optimiser UPDATES BaseModel parameters.
InstructionTuningProcess PRODUCES Checkpoint.
Checkpoint IS_EVALUATED_ON ValidationSet AND EvaluationSuite.
DeploymentGate ACCEPTS_OR_REJECTS FineTunedModel.
DataProvenance QUALIFIES InstructionDataset.
PolicyConstraint RESTRICTS data, optimisation and release.

5. FORMAL MATHEMATICS
D = {(u_i, c_i, y_i, m_i)}_(i=1..N)
u_i := instruction; c_i := context; y_i := target response; m_i := metadata.
p_theta(y | u,c) = product_(j=1..|y|) p_theta(y_j | u,c,y_<j)
L_SFT(theta) = -(1/N) sum_i sum_j w_ij log p_theta(y_ij | u_i,c_i,y_i,<j)
w_ij = 1 for supervised target positions; 0 for excluded/prompt positions, subject to the chosen masking policy.
theta_(t+1) = OptimiserStep(theta_t, gradient_theta L_batch, eta_t)
ValidationLoss = L_SFT(theta; D_validation)
GeneralisationGap = ValidationLoss - TrainingLoss
These quantities are operational definitions; lower validation loss alone does not guarantee factuality, harmlessness or reliable instruction following.

6. TRAINING PATHWAY
P01 Define target instruction-following capabilities and exclusions.
P02 Verify example provenance, permissions and data handling.
P03 Deduplicate, filter and split data to reduce leakage.
P04 Format conversations and establish role boundaries.
P05 Tokenise; construct attention masks and target-only loss masks.
P06 Initialise from the selected pretrained checkpoint.
P07 Run minibatch optimisation under resource and policy limits.
P08 Validate periodically and inspect overfitting.
P09 Evaluate held-out tasks, adversarial cases and safety behaviour.
P10 Compare with baseline; document regressions and uncertainty.
P11 Approve, revise or reject using explicit deployment criteria.
P12 Record final model, configuration, dataset version and metrics.

7. INVARIANTS AND BOUNDARIES
INV01 Dataset splits remain traceable and disjoint under the stated split policy.
INV02 Training targets and masks match the declared objective.
INV03 Every published checkpoint has identifiable provenance.
INV04 Evaluation records identify model version and test version.
INV05 Protected or unauthorised data is excluded under applicable policy.
INV06 No evaluation result is represented as a guarantee of safety.
INV07 Training cannot infer reliable truth merely from imitation of target responses.
INV08 Changes to data, hyperparameters or templates create a new run/version.

8. MINI RECURSION ENGINE
INPUT: model M_theta, dataset D, rules R, boundaries B, knowledge K.
FOR each training cycle t:
  candidate_batches = expand(I_t, R_t)
  valid_batches = filter(candidate_batches, B_t)
  IF valid_batches empty: halt_with_reason('no valid training batch')
  batch = select(valid_batches, sampling_rules)
  loss = compute_masked_objective(M_theta, batch)
  IF not finite(loss): halt_with_reason('invalid numerical state')
  theta = optimiser_update(theta, loss)
  metrics = evaluate_if_due(theta, validation_data)
  record(theta, loss, metrics, provenance)
  IF stopping_rule(metrics, B_t): break
OUTPUT: versioned checkpoint, evaluation report and audit record.

9. INFERENCE RULES
IR01 IF example includes instruction and target AND passes validation THEN eligible_for_training.
IR02 IF provenance or permission fails THEN quarantine_or_exclude example.
IR03 IF validation worsens persistently THEN consider early stopping or revision.
IR04 IF prompt tokens are masked THEN they provide context without direct target loss.
IR05 IF evaluation regression exceeds threshold THEN deployment_gate = reject_or_review.
IR06 IF held-out performance improves THEN evidence supports improvement on tested distribution only.
IR07 IF policy boundary is violated THEN stop or remediate before release.
IR08 IF model and data versions change THEN invalidate prior unqualified comparisons.

10. HOW TO READ THE FLOW
The model receives formatted instructions and contexts; supervised response tokens provide a learning signal. Rules determine preprocessing, objective and parameter updates. Boundaries restrict eligible data and training actions. Validation and evaluation feed back into the next cycle and the release decision.

11. TRI-MAPPING
ONTOLOGY: InstructionExample -> TrainingObjective -> Optimiser -> FineTunedModel.
ALGEBRA: D -> L_SFT(theta) -> theta_(t+1) -> M_theta*.
EXECUTION: load_examples -> mask_and_tokenise -> train_step -> validate_and_gate.

12. MAPPING TABLE
InstructionExample | (u,c,y,m) | validated training record
BaseModel | M_theta0 | initial checkpoint
TrainingObjective | L_SFT | masked loss computation
Optimiser | theta update | train step
PolicyConstraint | B_t | filtering and stopping
ValidationSet | D_val | held-out evaluation
FineTunedModel | M_theta* | accepted checkpoint
DataProvenance | K_t metadata | reproducibility record

13. EXECUTION GUARANTEE — CONDITIONAL
Given well-formed inputs, available compute, finite arithmetic, correctly implemented rules and a terminating schedule, the flow produces a recorded training outcome or explicit failure state. It does NOT guarantee convergence, correct answers, generalisation, alignment, safety or deployment suitability.

14. AI SEARCH FLOW
FLOW_ID: semantic-library.ai.training-process.instruction-tuning
FLOW_VERSION: 1.0
ENTITY_TYPE: AITrainingProcess
CANONICAL_NAME: Instruction Tuning Ontology
ALIAS: supervised fine-tuning for instruction following; instruction-following SFT
PARENT: Training Process Entities
SOURCE_URL: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/training-process-entities/instruction-tuning-ontology.html
AUTHORS: Mark Anthony Higgins — Sky Recursive AI
PURPOSE: Map instruction-response supervision to model optimisation and evaluation.
INPUTS: pretrained model; instruction-response dataset; configuration; policy constraints.
OUTPUTS: candidate instruction-tuned model; checkpoint; evaluation; provenance.
PATHWAYS: curate -> format -> tokenise -> train -> validate -> evaluate -> gate.
INFERENCE: eligibility, leakage control, regression detection, deployment decision.
SEMANTIC_EQUIVALENCE: instruction tuning is commonly implemented with SFT, but is not identical to all supervised learning; preference optimisation and RLHF are separate or additional stages.
CONFIDENCE: conceptual ontology, not a claim of empirical performance.
UPDATE_MODEL: version each material dataset, model, objective or policy change.
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/training-process-entities/instruction-tuning-ontology.html
FLOW_HASH: not computed; compute SHA-256 on final published bytes if required.

END OF FLOW