Valid JSON Numbers Can Lose Distinct AI Record Identities

Define the representation used for an exact record key

An AI input can carry record identifiers for later source matching. When the identifier is an exact key, the receiving component needs to distinguish the agreed identities. A small numerical change can matter even when the changed value remains a perfectly usable number.

RFC 8259, published in December 2017, defines decimal number syntax while allowing implementations to limit accepted range and precision. It does not assign every JSON number a universal fixed-width integer representation. Section 6 identifies the inclusive interval from -(2^53)+1 to (2^53)-1 as exactly interoperable for the binary64 software it discusses: -9007199254740991 through 9007199254740991.

That interval is a useful contiguous agreement range. It is not a JSON grammar boundary. Whether a particular larger integer survives exactly depends on the receiving representation and conversion.

References: [R8259]

JI-72: compare the same three intended identities

JI-72 is an original fictional comparison for three AI input records. Their exact intended record_id values are 9007199254740992 for record A, 9007199254740993 for record B and 9007199254740994 for record C. A, B and C are explanatory row labels, not alternative keys supplied to the consumer.

Path N carries each identifier as a JSON number token. Its stipulated receiver converts each token directly to IEEE 754 binary64 using correctly rounded round-to-nearest, ties-to-even conversion. The consumer compares the resulting numeric values as keys. All three integer tokens fit JSON number grammar. This receiver choice is a premise, rather than a claim about every JSON parser.

Path T is a separately agreed alternative: each identifier travels as a JSON string containing exactly its stated decimal digits. The complete path retains those string contents without numeric conversion, and the consumer uses exact string equality.

All three records remain present in both paths. This case derives representation outcomes from those premises; it describes no executed application test.

References: [R8259][B64]

Derive the midpoint collision from 53 bits of precision

The double format described in Oracle's Numerical Computation Guide has 52 fraction bits and an implicit leading bit, giving normal values 53 bits of significand precision. The significand is the part carrying the significant binary digits. The guide also describes nearest rounding with ties resolved toward an even retained value.

At 2^53, which equals 9007199254740992, one step in the fraction changes the represented value by 2^53 × 2^(-52) = 2. The adjacent representable values relevant here are therefore 9007199254740992 and 9007199254740994. Both endpoints are exact. The intervening integer, 9007199254740993, is one unit from each endpoint.

To resolve the tie, express the two candidates in units of 2. Their retained integer significands are 4503599627370496 and 4503599627370497. The first is even, so the stipulated tie rule chooses 9007199254740992. Both displayed endpoint integers are themselves even; the deciding parity belongs to the retained significand.

Thus 2^53 and 2^53+2 remain exact despite both exceeding the RFC interval's positive endpoint, 2^53-1. That interval does not claim that every integer outside it is inexact. JI-72 exposes the missing integer between two exact representable neighbors.

References: [B64][R8259]

Keep the record count separate from the distinct-key count

At Path N's consumer, A carries numeric key 9007199254740992, B also carries numeric key 9007199254740992, and C carries numeric key 9007199254740994. The received record count is three. The number of distinct decoded numeric keys is two.

A report that three records parsed successfully would therefore leave the identity requirement unresolved. A and B's intended identifiers differ, but their decoded keys compare equal. A duplicate-key finding at this boundary would not establish that the original records actually shared an identifier.

Nor can formatting the rounded values as strings afterward recover B's original last digit from those values alone. The distinction has already been removed by the stated conversion. Whether later software rejects a duplicate, retains both records, performs a match or writes anything is a separate behavior; this example stipulates none of those actions.

References: [B64]

An integer assertion still needs an exact receiving path

JSON Schema Draft 2020-12's validation document defines integer as a number with a zero fractional part. Its numeric-instance discussion does not impose a general precision bound. A declaration of integer therefore does not, by itself, select a storage width that preserves the application's entire identifier domain.

In JI-72, all three intended values are integers. All three decoded numeric values also have zero fractional parts. If an integer-type check examines those already rounded values, that check alone cannot distinguish the original B identifier from A's identifier.

Additional assertions can narrow the allowed domain. Minimum and maximum, for example, constrain numeric values according to their declared bounds. Such constraints still need an implementation that evaluates the relevant values faithfully. They cannot reconstruct a source digit already lost before the check.

The related schema-valid AI output guide explains structural assertions, business rules and source matching. This comparison adds a narrower requirement: the representation reaching those checks must retain the exact key distinctions they need.

References: [JS20][B64]

Choose the agreed identity contract before choosing a representation

Path T's received strings retain 9007199254740992, 9007199254740993 and 9007199254740994 as different character sequences. Exact string equality therefore yields three distinct keys under the stipulated unchanged string path.

That result depends on the agreement. JSON strings and numbers are different value kinds, and substituting strings does not automatically satisfy an existing numeric field requirement. If a later component converts these strings to the same binary64 representation, the identity comparison must address that conversion too. Starting with strings created from already rounded numbers would not supply the original digits.

An exact numeric path with sufficient integer capacity could also preserve these three identifiers. It needs evidence for the actual domain through every relevant conversion, rather than a broad claim that numeric transport always fails.

Decide whether the application requires exact mathematical integer values or exact character identifiers, then assess the offered path against that requirement. The two JI-72 paths compare agreed contracts; they do not establish a universal recommendation to replace numeric schemas with strings.

References: [R8259][JS20]

Ask for a traceable comparison at the consuming component

Begin with the allowed identifier domain and the consumer's equality rule. An offer limited to a smaller range does not meet a requirement to preserve JI-72's three keys merely because it accepts other valid JSON numbers. Conversely, a documented exact integer representation can answer this case without adopting Path T.

Ask the input-path owner to identify the receiving component, its numeric or string representation, and the conversions between the source text and the point where keys are compared. Relevant parser, adapter and consumer versions belong with that explanation. A promise about the initial response format leaves a later conversion unresolved.

Useful evidence pairs each exact source identifier with the value and type that reach the consumer, plus the equality rule used there. Keep the exact source available as the reference: comparing two copies of an already rounded value cannot establish preservation of the original identifier. Report received records and distinct keys separately.

For this fictional case, Path N fails the distinct-key requirement and Path T satisfies it under its premises. A real implementation needs evidence that its actual path follows the claimed behavior. These three examples illuminate the boundary; coverage of the full agreed identifier domain needs a corresponding representation argument.

The related Parquet decimal guide addresses a different precision decision: how unscaled integers, scale and declared capacity preserve amounts. JI-72 concerns equality of record identities after numeric conversion. Preserving either one does not establish the other.

Scope a separate equipment-installation need

If the wider AI project also requires physical installation of selected servers, storage or switches, Leviathan's Rack-and-Stack Installation service and the linked project inquiry provide the relevant next step. Share a nonconfidential outline of the equipment, rack positions, mounting inputs, IT connections, site conditions and requested physical handoff to discuss scope and availability.

The service covers agreed physical installation and its records. JSON handling, application integration and exact-key assurance remain with the appointed software and data owners.

References: [L1]