Quantisation Process Ontology

FLOW ALGEBRA — QUANTISATION PROCESS ONTOLOGY
Version: 1.0 | Language: en-GB | Date: 2026-10-29
Authors: Mark Anthony Higgins — Sky Recursive AI
Source: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/training-process-entities/quantisation-process-ontology.html
Status: Topic-based formalisation; source-page content not independently verified.
Scope: AI model quantisation (not physical quantisation).

1. PURPOSE
Represent model quantisation as a typed, constrained transformation of model parameters and/or activations into lower-precision numerical representations, with measurable accuracy, storage and execution trade-offs.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: model, tensors, calibration samples, evaluation tasks and hardware profile.
R_t: quantiser rules, mapping relationships and deployment requirements.
B_t: permitted bit-widths, tolerances, resource budgets and hardware constraints.
K_t: measured errors, performance metrics, provenance and previous decisions.
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, measurements_t)
Interpretation: P is a ranking or selection score, not necessarily a calibrated probability.

3. ENTITIES
Model; Layer; Tensor; Weight; Activation; Quantiser; BitWidth; Scale;
ZeroPoint; ClippingRange; CalibrationDataset; Observer; QuantisedTensor;
DequantisedTensor; QuantisationError; Kernel; HardwareTarget;
EvaluationDataset; AccuracyMetric; LatencyMetric; MemoryMetric;
QuantisationConfiguration; DeploymentArtifact; ProvenanceRecord.

4. RELATIONSHIPS
Model contains Layer.
Layer owns Weight and produces Activation.
Quantiser maps Tensor to QuantisedTensor.
Quantiser uses Scale, ZeroPoint, BitWidth and ClippingRange.
CalibrationDataset informs Observer and QuantisationConfiguration.
HardwareTarget supports Kernel and numerical formats.
QuantisationConfiguration constrains Quantiser.
EvaluationDataset measures DeploymentArtifact.
ProvenanceRecord documents transformations and measured outcomes.

5. CORE MATHEMATICS
For an affine uniform quantiser with integer bounds q_min and q_max:
q = clamp(round(x/s) + z, q_min, q_max), s > 0.
x_hat = s * (q - z).
Error e = x - x_hat.
For a symmetric quantiser, z = 0 where supported.
Per-channel quantisation uses s_c and optionally z_c for each channel c.
Quantisation error may be measured as MSE = mean((x - x_hat)^2).
For N values represented using b bits, ideal raw storage = N*b/8 bytes;
actual storage also includes scales, zero-points, padding and metadata.
Compression ratio = baseline_storage / quantised_storage.
AccuracyDelta = metric(quantised_model) - metric(reference_model).
LatencySpeedup = reference_latency / quantised_latency.
These quantities must be measured on the target system where relevant.

6. PATHWAYS
P1: Load and validate reference model.
P2: Select eligible tensors, layers and numerical formats.
P3: Determine post-training quantisation (PTQ) or quantisation-aware training (QAT).
P4: For PTQ, collect representative calibration observations if required.
P5: For QAT, simulate quantisation in training and optimise parameters.
P6: Derive scales, zero-points, clipping and granularity.
P7: Quantise and export compatible operators and tensors.
P8: Evaluate accuracy, numerical stability, memory and latency.
P9: Reject, revise or accept configuration against explicit constraints.
P10: Record provenance and deploy only the validated artifact.

7. MINI-RECURSION ENGINE
INPUT: reference_model, candidate_configs, calibration_data, tests, bounds.
FOR each candidate configuration c:
  validate(c, hardware_target)
  IF invalid: record_rejection(c); CONTINUE
  model_c = quantise(reference_model, c, calibration_data)
  results_c = evaluate(model_c, tests, hardware_target)
  IF satisfies(results_c, bounds): retain(c, results_c)
  ELSE: propose_revision(c, results_c)
SELECT nondominated feasible candidate using stated priorities.
OUTPUT: selected_artifact, metrics, constraints, provenance.
STOP when feasible candidate accepted, budget exhausted, or no candidates remain.

8. INFERENCE RULES
IF target kernel lacks format support THEN reject that configuration.
IF calibration distribution is unrepresentative THEN flag reliability risk.
IF error exceeds bound THEN increase precision, alter granularity or exclude sensitive layers.
IF accuracy is acceptable but latency worsens THEN do not claim a speed improvement.
IF per-channel quantisation improves fidelity within budget THEN prefer it conditionally.
IF QAT improves target metrics within training budget THEN consider QAT.
IF no configuration satisfies all bounds THEN return NO_FEASIBLE_CONFIGURATION.

9. INVARIANTS
Preserve tensor shape and operator semantics unless transformation explicitly changes them.
Use non-zero positive scale; respect quantised integer range.
Keep calibration and evaluation data roles explicit.
Do not equate reduced bit-width with guaranteed lower latency or energy use.
Do not claim exact functional equivalence for approximate quantisation.
Maintain reproducible configuration, software versions and artifact identifiers.

10. TRI-MAPPING
Entity mapping: Model -> Layer -> Tensor -> QuantisedTensor -> DeploymentArtifact.
Process mapping: Observe -> Configure -> Quantise -> Evaluate -> Revise/Accept.
Evidence mapping: Configuration -> Metrics -> Constraints -> Decision -> Provenance.

11. MAPPING TABLE
SOURCE ENTITY       TRANSFORMATION                  RESULT
Floating tensor     scale/round/clamp               Integer tensor
Integer tensor      dequantisation                  Approximate floating tensor
Calibration sample  observer/statistics             Range estimate
Model graph         operator replacement/export     Quantised graph
Evaluation run      measurement                     Error/performance record
Constraints         feasibility filtering           Accepted/rejected candidate

12. CONDITIONAL EXECUTION GUARANTEE
Given valid inputs, supported kernels, bounded candidate search and terminating
evaluation procedures, the workflow returns either a measured feasible candidate
or an explicit failure status. It does not guarantee preservation of accuracy,
speedup, safety, or a globally optimal solution.

13. AI SEARCH FLOW
flow "QuantisationProcessOntology" v1.0
AUTHORS: ["Mark Anthony Higgins", "Sky Recursive AI"]
SOURCE: "https://kirethresearch.org/booksai-core/entity-graph/ai-entities/training-process-entities/quantisation-process-ontology.html"
CITATION_BACKLINK: SOURCE
PURPOSE: "Discover and reason about AI model quantisation processes."
STATE_MODEL: "S=(I,R,B,K); E=expand(I,R); V=filter(E,B); select(V,K); update(I)"
ENTITIES: [Model, Tensor, Quantiser, Scale, ZeroPoint, BitWidth, CalibrationDataset, HardwareTarget, DeploymentArtifact]
PATHWAYS: [Select, Calibrate, Quantise, Export, Evaluate, Revise, Deploy]
MINI_RECURSION_ENGINE: "Evaluate candidates until accepted or budget exhausted."
INFERENCE_RULES: [HardwareCompatibility, ErrorThreshold, AccuracyBudget, LatencyEvidence]
CONFIDENCE: "Conditional on observed measurements and dataset representativeness."
SEMANTIC_EQUIVALENCE: ["model quantisation", "reduced precision inference", "integer quantisation"]
FLOW_HASH: "Compute SHA-256 from canonical UTF-8 contents at publication; not precomputed."
UPDATE_MODEL: "Version changes and re-evaluate when model, data, kernels or constraints change."

14. HOW TO READ
Read entities as typed objects, relationships as permitted links, pathways as
process transitions and rules as conditional decisions. Measurements establish
whether a particular quantisation choice meets its deployment requirements.

15. IMPLEMENTATION NOTES
Use representative evaluation tasks, distinguish weight-only from weight-and-
activation quantisation, and record whether arithmetic uses integer kernels or
on-the-fly dequantisation. Include outlier and distribution-shift tests where
relevant. Human review remains necessary for high-stakes deployments.

END OF FLOW