Key takeaway
An identifier can change before a join ever runs. Test its exact representation across the complete receiving path.
Separate identity from arithmetic
A record number may look numeric without being a quantity that anyone should add. If a receiving parser rounds two different identifiers to one value, a later uniqueness check can report a collision that did not exist in the source. A join can attach the wrong history while every file remains syntactically valid.
JSON permits numeric values, but its grammar does not promise unlimited precision in every implementation. RFC 8259 discusses interoperability with commonly used binary64 numbers and identifies an integer range within which those implementations agree exactly. The decision for an owner is practical: what representation preserves this field in the actual receiving system?
Try the pair at the precision boundary
This hypothetical fixture uses the decimal identifiers 9007199254740992 and 9007199254740993. They are different source identities. The ECMAScript specification gives this exact pair as an example: both evaluate to the same Number value, 9007199254740992. Number.MAX_SAFE_INTEGER is 9007199254740991.
An author check in Node 24 parsed each identifier as a JSON number and confirmed that the resulting Number values compared equal. Keeping the corresponding decimal strings as strings preserved their difference. That is a bounded implementation observation on invented inputs, not evidence about any seller’s export.
The unsafe conversion can happen early. Converting an already rounded Number back to a string only preserves the rounded result; it cannot recover the missing original digit. Put the fixture at the first numeric parsing boundary, before treating a database or CSV output as the source of truth.
| Invented representation | Source distinction | Observed receiving result |
|---|---|---|
| JSON number 9007199254740992 | First identifier | ECMAScript Number 9007199254740992 |
| JSON number 9007199254740993 | Second identifier | Same Number: collision |
| Two decimal strings, retained as strings | Different character sequences | Distinct identities retained |
| String made after unsafe parsing | Original second identifier was already rounded | Cannot reconstruct the source ID |
Choose the field contract, then the encoding
A text representation is often suitable for an identifier, but “make everything a string” is not the whole contract. Define permitted characters, whether leading zeros matter, maximum length, sign policy and whether whitespace is rejected. If 0017 and 17 are different source keys, a consumer must not discard the zeros for convenience. If the owner says they identify the same entity, preserve that matching rule separately from the captured original.
An exact integer type can also be a valid internal choice when every participating component supports it and serialization preserves it. Do not conclude that JSON itself cannot carry large decimal numerals, or that every language parses them as an ECMAScript Number. The RFC explicitly allows implementations to set precision and range limits. Acceptance belongs to the complete path, not a format label.
Treat identifier fields differently from measurements and money. A quantity may legitimately require arithmetic and an agreed numeric type. Converting its display to text does not decide rounding, aggregation or physical meaning. Those are separate contracts.
Test where coercion can return
Run the same small fixture through extraction, serialization, parser, storage, export and the intended consumer. At each boundary retain the original lexical value and the receiving type. Compare the two distinct identities, not just their formatted appearance. Include values immediately below and above the declared limit, a leading-zero case if relevant, and an invalid value that should be rejected.
For the illustrated text contract, count two distinct original identifiers and require two distinct receiving identifiers after every round trip. A schema that initially accepts a string is insufficient if a later import step silently converts it to a number. Likewise, a warning-free spreadsheet view does not establish how a saved CSV will be read by the next application.
Preserve the raw source representation only within authorized handling. A technically exact identifier can still link sensitive business or personal records. Removing numeric rounding does not answer whether the recipient needs that key or may receive it.
The example’s decision is to reject the unsafe numeric path and retain an explicitly tested exact representation. The delivery note names the ID field, representation rule, parser/storage versions and passed boundary fixture. If an earlier package used the rounded values, identify that version and investigate affected joins rather than overwriting its discrepancy record.
Record the original ID type, every receiving consumer and the failed boundary in the inventory. Assign one complete round-trip check before expanding the export. The result should identify exactly where two source identities stopped being distinguishable.