The Number Was Valid, but It Meant Something Else

The sensor response passes its schema checks. It has the expected field, and the value is a finite number. Botie’s model nevertheless reports a much larger score than yesterday. The device started reporting Fahrenheit while the fitted preprocessing still expects Celsius.

The number’s type cannot tell us its unit. We need the meaning of the number to cross the boundary with it, and we need to convert it before using the model’s saved reference. Retrieval scores have a similar trap: a smaller distance can be better, while a larger similarity can be better.

Botie’s fitted Celsius model receives temperatures from a device that may report Fahrenheit.

Temperature in Celsius and temperature in Fahrenheit describe the same kind of quantity using different scales. The number needs its unit before another program can interpret it. A field called value leaves that information out; a documented unit field or a name such as temperature_c can make it explicit.

Guessing from the range is unreliable. Ordinary operating temperatures can produce plausible-looking numbers in either scale, so a range check may accept the value while the model interprets it incorrectly.

A version adapter can make a documented conversion. It should not silently reinterpret an unknown unit.

The model’s reference temperature was learned in Celsius. Convert the request into that representation first, then subtract the saved centre and apply the coefficient. Reversing those operations changes what the centre means.

Temperature conversion needs an offset as well as a scale. Converting a temperature difference uses the scale without the absolute-temperature offset.

incoming temperature = 68 F
Celsius = (68 - 32) × (5 / 9) = 20 C
saved centre = 4 C
centred reading = 20 - 4 = 16
coefficient = 2
illustrative score = 16 × 2 = 32

Both requests now reach the same Celsius input and produce the same illustrative score.

fahrenheit = 50
celsius = (fahrenheit - 32) * 5 / 9
training_centre = 4
print(celsius)
print(celsius - training_centre)

10.0
6.0

A retrieval tool may return a number beside each passage. That number needs an explanation too. A Euclidean distance describes how far two representations are apart, so the smaller distance comes first. Cosine similarity measures how closely their vector directions align, so the larger similarity comes first. A descending sort cannot be correct for both meanings.

Record the metric and its ranking direction with the index version. A similarity is not automatically a probability of relevance. A probability would need a defined event and evidence that its claimed likelihood agrees with observed outcomes; a finite similarity score supplies neither by itself.

IDs = [A,B,C]
reported distances = [0.7,0.2,0.2]
order for smaller-is-better = [B,C,A]
first two IDs = [B,C]

The equal-distance tie keeps the declared incoming order. The score stays attached to its passage ID.

Dot products, cosine similarities and squared distances are related only under stated assumptions. Cosine similarity divides by vector lengths. A zero vector needs an explicit policy because that division is undefined. Squaring a distance preserves its ordering, but changes its numerical scale and threshold meaning.

Do not transplant a threshold merely because two metrics return the same-shaped array. Keep the preprocessing, metric and threshold as one reviewed configuration.

This lesson’s ranking challenge takes an explicit ordering direction. It does not infer the metric or calibrate its threshold.

An array shape tells us how many entries exist, not which axis means examples, features or time. A batch of two examples with three features has a different contract from three examples with two features. A transpose can create a valid matrix that answers a different question.

Document feature names, axis meanings, units and numerical dtype beside the model input. Validate these before relying on broadcasting or a matrix multiplication.

The model’s first coefficient must receive the same named quantity, in the same unit and axis position, that it received during fitting.

Use two independently specified fixtures that describe the same physical input. Their canonical values and model predictions should agree within a justified numerical tolerance. Include a temperature where an offset matters; testing only a special point can hide a broken conversion.

For score adapters, use a case where the best score is the smallest, a negative-score case where larger is still better, and a tie. These fixtures expose meaning rather than checking only whether the function returned a list.

Equivalent representations must really describe the same situation. Arbitrary perturbations are not automatically prediction invariances.

If a caller sends Kelvin to a C/F-only interface, reject it with an actionable error. Adding Kelvin support later requires an explicit conversion and tests; it does not require guessing today. Similarly, a retrieval response that omits its metric should not inherit an unrelated threshold by accident.

Track contract versions and model versions with incident reports so a discrepancy can be reproduced. Avoid logging complete private prompts merely to record which representation was in use.

When a device changes its calibration, review that assumption alongside the unit contract.