Don't Ask AI to Reconstruct Digits Lost from an Identifier

A support assistant finds two orders with the same imported identifier and proposes combining their histories. In the original export, the identifiers differed in the last digit. Somewhere between the file and the tool response, both became the same number. The model is now reasoning faithfully about damaged evidence.

This is a constructed failure scenario, not a reported customer incident. Its practical question is whether an imported identifier still supports a lookup or a link. ZharfAI's recommendation is to preserve opaque identifiers as text, test every conversion boundary, and request authoritative originals when the surviving value is ambiguous. A plausible replacement digit is not a repair.

Decide whether the field names something or measures something

An order identifier answers “which order?”, not “how many orders?”. Adding two identifiers produces no useful business quantity. A field can contain only digits and still be a label. Its width, leading characters and issuing system may all matter independently of the numerical value those digits could represent.

Start with the producer's definition, not a preview of the first hundred rows. Record the identifier's namespace, permitted characters, length rules and missing-value policy. Two departments may legitimately issue the same string for different things. Preserving the string protects evidence; it does not by itself establish uniqueness or permission to access the associated record.

Our customer-record matching guide explains when evidence supports linking two records. This article addresses an earlier boundary: whether the evidence survived ingestion. Do not tune a similarity threshold to compensate for a parser that changed the lookup key.

Amounts and quantities belong on a separate path with their own units and arithmetic rules. Declaring the whole file to be text may be a useful landing-stage choice, but it is not a complete business schema. The eventual report must still distinguish identifiers, measured values and descriptive notes.

Separate missing zeros, lost precision and display formatting

These are three different problems. A leading zero can disappear even from a small, exactly representable number. A long number can lose distinguishing digits when stored in a representation with insufficient precision. Scientific notation can merely change how an intact value is displayed; seeing an exponent is a reason to inspect the underlying value, not proof of corruption.

Microsoft's guidance on leading zeros and large numbers documents Excel's 15-significant-digit precision and advises text for long number codes. Applying a text format after numeric entry does not restore the original digits. Supported recent versions also expose automatic-conversion controls; their availability is version-dependent.

The operational consequence is about timing. Establish the identifier type before the first lossy conversion. Widening a column, adding visible zeros or wrapping the current value in a string can improve presentation without recovering evidence. Inspect the stored cell value and type, and compare with a source that predates the suspected conversion.

Do not reject every identifier ending in zeros. Many valid identifiers do. A pattern such as an unusual rise in repeated suffixes is an investigation signal, not a license to edit records. Likewise, equal-looking cells are not necessarily equal values, and unequal-looking cells may be different presentations of the same authorized identifier.

Reproduce a collision at the JSON boundary

JSON syntax does not promise that every consumer preserves arbitrarily large numeric values. RFC 8259, section 6 allows implementation precision limits and identifies integers from -(2^53)+1 to (2^53)-1 as interoperable with the widely used binary64 representation. JSON numeric syntax also excludes leading zeros. A quoted identifier is a different type, not just another way of printing a number.

MDN's safe-integer reference gives JavaScript's Number.MAX_SAFE_INTEGER as 9007199254740991. Beyond that boundary, adjacent integers need not remain distinguishable. This is not the same rule as Excel's 15-digit precision, nor does it mean every larger integer is individually unrepresentable.

The following synthetic example uses no real customer data. Run it in a JavaScript runtime:

const damaged = JSON.parse(
  '[{"id":9007199254740992},{"id":9007199254740993}]'
);
const preserved = JSON.parse(
  '[{"id":"9007199254740992"},{"id":"9007199254740993"}]'
);

console.log(damaged[0].id === damaged[1].id);     // true
console.log(preserved[0].id === preserved[1].id); // false
console.log(String(damaged[1].id));              // 9007199254740992

The last line is the trap: converting the parsed number to text preserves the damaged value. A successful equality check or a successful JSON parse therefore does not establish fidelity. The original tokens distinguish the records; the numeric objects no longer do.

An exact-integer implementation can preserve large numerical values, but numerical equality still does not preserve a leading-zero spelling. Choose the representation to match the field's meaning and every supported consumer, not just the strongest component in the chain.

Make import settings part of the data contract

For each supported route, name the actual sequence: producer export, spreadsheet import, save, integration parser, tool response. “CSV uploaded successfully” is not enough. CSV field quoting and the receiving application's type inference are separate concerns; surrounding a field with quotes does not establish a universal spreadsheet text type.

For a human-edited workbook, provide an identifier column that is textual from the start and a tested import procedure. For machine ingestion, declare the column explicitly and preserve the unmodified incoming artifact under appropriate access and retention controls. If the producer already exported rounded digits, a careful importer cannot undo that earlier loss.

The pandas read_csv reference documents explicit column types and notes that converters take precedence over dtype. Missing-value interpretation is another setting: with keep_default_na=False and no na_values, strings are not interpreted as missing markers. A text declaration alone is not the complete import policy.

Review wrappers as well as the main parser call. A helper that converts every digit-only string to a number can defeat an otherwise correct schema. A later spreadsheet save can do the same. Test the path recipients actually use, including re-export, rather than stopping at the first successful load.

Protecting text from conversion into a formula is a separate obligation. Our spreadsheet export guide covers that boundary. A formula-safe file can still damage identifiers, and an identifier-preserving file can still contain unsafe formulas. Neither test substitutes for the other.

Allow normalization only when an authority defines it

“Never change a character” is too crude for systems that exchange formally defined identifier representations. The useful rule is to preserve the source and apply only a named, justified transformation. Its inputs, output format and version should be reviewable, with a separate decision about whether the result may drive an action.

GS1's EDI guidance gives a concrete exception: GS1 XML represents a GTIN with 14 numeric characters, padding shorter forms on the left. GS1 EANCOM instead suppresses non-significant leading zeros under its stated representation rules. Those rules belong to those formats; they do not authorize padding an arbitrary customer code.

Suppose an internal field is documented as exactly six ASCII digits and the source contains 000123. The landing record should retain that string. If the source instead contains numeric 123, width alone is insufficient proof of what happened. An authorized producer contract might define the six-character representation; without that contract, silently adding zeros invents certainty.

For Persian-facing systems, specify whether Persian and Latin digit forms are accepted and what conversion is permitted. Keep that conversion distinct from numeric parsing. A character mapping need not pass through a floating-point number. Reject unexpected separators or whitespace unless the identifier authority explicitly assigns them a harmless presentation role.

Length and pattern checks test shape, not provenance. A rounded identifier can have the expected length and character set. Even an applicable check digit is only one validity condition. A valid-looking value must still be traced to its source and resolved in the correct namespace.

Give the model references, not responsibility for repairing keys

ZharfAI proposes separating the evidence record from the model-facing description. The evidence record retains the source artifact reference, row or cell location, received type, original value, any authorized normalization and its rule version. Retain sensitive originals only where justified; do not copy them into ordinary diagnostic logs.

The model can explain an import rejection, identify a suspicious mapping or draft a request for a fresh export. It should not guess missing suffixes, choose the closest existing customer or append zeros merely to satisfy a pattern. Those actions would turn uncertainty about identity into an apparently precise instruction.

Where practical, let the model select a tool-returned record reference that the application resolves, rather than asking it to rewrite a long identifier. Bind that reference to the authorized user, namespace and available record set. Validate it when the action executes. A reference reduces transcription opportunities; it is not an access-control exemption.

Keep rejected identifiers out of automatic linking and side-effecting actions. A support summary may still describe the unresolved row without claiming a customer identity. The user should see a concrete reason such as “identifier precision could not be established; original export required,” not a generic model-confidence percentage.

Missing identifiers deserve their own state. Do not replace them with zero or a shared placeholder that later behaves as a real key. Our missing-value guide addresses that distinction for reporting; the same discipline prevents unrelated records from being grouped under an invented common identifier.

Choose acceptance, quarantine or source recovery

The following is an engineering decision framework, not a vendor certification. Apply it to the field and operation that require identity. An unresolved identifier does not necessarily invalidate every non-identifying observation in the same file, but any partial use must be explicit.

For recovery, first prevent new actions based on the suspect key. Establish which batch, parser version and downstream stores received it. Recover from the producer's authoritative export or another independently reliable source, then rerun the corrected import with an explicit mapping from old ingestion records to recovered records.

Do not simply overwrite the damaged key and declare the job finished. Earlier joins may have attached notes, tasks or decisions to the wrong record. Identify those downstream effects and assign review before undoing business actions. The correct remediation depends on what happened; this article does not authorize automatic reversal of transactions.

Keep a bounded incident record showing what was verified and what remains unknown. An unchanged source-file digest can show that a retained artifact was not modified; it does not prove that the producer generated correct identifiers in the first place.

Test distinguishing cases, not just successful imports

Build a small synthetic fixture whose expected values are declared as strings outside the path under test. Include 000123 and 123 as distinct values when the test namespace says they are distinct, plus the adjacent long values from the JavaScript example. Add legitimate trailing zeros so a heuristic cannot pass by rejecting every suspicious-looking suffix.

Also include empty text, an absent field, an unexpected numeric token, an exponent-shaped string, leading whitespace and permitted or forbidden digit variants. Expected acceptance depends on the chosen namespace. The fixture is not a universal identifier validator; it tests whether your implementation follows its own declared rules.

Compare exact recovered values at every boundary and after the full round trip. Count rows as well as distinct identifiers. A drop in distinct values may expose a collision; a stable row count does not rule one out. Conversely, repeated identifiers can be legitimate when several rows describe one order, so cardinality is a warning signal rather than a universal uniqueness constraint.

Test rejection explicitly. An out-of-contract numeric value should not be automatically stringified and accepted. A missing identifier should not enter the lookup tool. A model-generated “correction” should not override the quarantine state. These are application tests, not requests for the model to promise better behavior.

Monitor the conversion boundary after release

Track fidelity failures in synthetic checks, unexpected input types, normalization counts, quarantined rows and unresolved recovery cases. Break them down by producer and parser version without exposing identifiers in metric labels. A change in rejection rate should lead to investigation of the source contract, not an automatic relaxation of validation.

Repeat the fixture after a spreadsheet version change, parser upgrade, new export format or altered integration wrapper. Ask the data owner to confirm any namespace or width change. The useful acceptance statement is specific: this supported path preserves these identifier semantics, and refuses inputs whose identity it cannot establish.

AI can help explain a damaged import. It cannot make an ambiguous surviving value uniquely identify its lost original. Preserve that distinction before a neat-looking string becomes an instruction to touch somebody's record.

Source notes — reviewed October 5, 2026

The five primary references below support the documented format and parser behavior. The architecture, fixture, decision table and recovery procedure are ZharfAI analysis. The JavaScript demonstration is synthetic, not a customer incident or an end-to-end Excel test.

• Microsoft — keeping leading zeros and large numbers. Undated support guidance; reviewed on the date above.
• IETF — RFC 8259. December 2017; JSON format and interoperability.
• MDN — Number.MAX_SAFE_INTEGER. Page modified October 22, 2025.
• pandas — read_csv. Rolling documentation displaying version 3.0.6 at review; deployed versions must be tested separately.
• GS1 — GTIN format in EDI standards. Modified September 2, 2024; representation-specific rules.