An operations analyst exports archive records so an AI-assisted task can prepare a catalogue review. The titles arrive intact. Some record IDs do not: a leading zero disappears, or a long code becomes a different number. A fluent summary cannot fix a broken link to the original record.
Treat an identifier as an exact string unless its owner has defined a different representation. Before using the transferred data, compare the actual values with the source, including every character. A column that looks right on screen is not enough.
Microsoft documents that Excel removes leading zeros through automatic conversion and has a maximum precision of 15 significant digits for numeric values.[1] Its conversion guidance also covers codes containing an E and date-like letter-number combinations.[2] These are documented Excel behaviours, not results from a MAJLS client or a test of your workbook.
Framework: define an identifier-preservation contract
MAJLS's identifier-preservation contract is a proposed preparation tool. It keeps data conversion separate from identity repair. Fill these fields before anyone imports the working file:
- Name the source field and its human owner. State whether leading zeros, case, spaces and punctuation are meaningful; unresolved rules mean a hold.
- Specify text storage for IDs, separately from numeric quantities. Record the actual import route and destination version.
- Keep a source snapshot and a stable row reference outside the ID being checked, so a changed ID does not break the comparison itself.
- Define an exact comparison after import and after any export used downstream. Require the expected rows and columns as well as matching strings.
- Name the human who can authorize release or a separately documented repair. Preserve rejected values and the reason for holding them.
Do not silently trim, pad, uppercase or deduplicate an identifier to make the test pass. A legitimate normalization rule needs its own source-to-destination mapping and owner approval. It is a different task from preservation.
Example: review a museum archive transfer
Everything below is illustrative: the museum, people, IDs and transferred values are synthetic. These are deliberately constructed review cases, not captured Excel output. Leila owns the archive IDs. Arun prepares the review file but cannot merge or rewrite source records.
The source snapshot AR-10 uses a separate row locator. Under Leila's illustrative rule, the entire ID is significant and case-sensitive. Blank IDs are held rather than invented.
| Source row | Source ID | Candidate transferred value | Review result | Next step |
|---|---|---|---|---|
| AR-10:1 | 000184 |
184 |
Different string | Reimport from source as text |
| AR-10:2 | 987654321098765432 |
987654321098765000 |
Different string | Reject changed value; return to source |
| AR-10:3 | 123E5 |
123E5 |
Exact match | Keep, subject to whole-file checks |
| AR-10:4 | JAN-1 |
JAN-1 |
Exact match | Keep, subject to whole-file checks |
| AR-10:5 | blank | blank | Preserved, but incomplete | Leila resolves missing identity |
The first two rows fail preservation. The last row passes equality but fails readiness. That distinction matters: unchanged bad input is still bad input.
Arun records a pending handoff: "AR-10 has two changed IDs and one missing ID. Rows 3 and 4 match. Nothing is released. Please confirm the original identifiers or authorize a fresh import." Leila, the named human archive owner, retains consequential approval for record merges, identifier repairs and production imports. An assistant may prepare the comparison; it must not choose the correct ID from a plausible-looking alternative.
Import as text before information is lost
Microsoft's documented Excel route is Data > From Text/CSV, then the query editor, where selected columns can be assigned the Text data type before loading.[1] Review the conversion steps and preview against the preserved source; do not start from a workbook whose IDs are already damaged.
Microsoft lists Automatic Data Conversions for Excel for Microsoft 365 and Excel 2024, including the corresponding Mac versions.[1][2]
That setting is not a substitute for choosing types in Power Query: Microsoft says the options do not directly affect Power Query imports.[2]
Its date-like conversion option also does not cover every pattern; strings with spaces or characters such as JAN-1 may still be treated as dates.[2] Check your actual route instead of relying on a setting name.
Custom display formatting is not recovery. Microsoft explicitly warns that formatting does not restore leading zeros previously removed.[1] If only the changed file survives, hold the row for the owner. Padding it to an assumed length does not establish what the source contained.
Checklist: prove the transfer before using it
Use a private working copy for the first rehearsal. The proposed MAJLS acceptance rule is zero changed IDs, zero unaccounted-for rows and a named owner for every missing or duplicate-ID question. These are pilot targets, not measured performance claims.
First record a baseline from the current manual route: mismatch count, unresolved identity count and observed review time. Test representative examples with leading zeros, more than 15 digits, E-containing codes, date-like codes, blanks, repeated IDs and any owner-significant spaces. Compare by the independent row locator, not by joining on the possibly damaged ID.
Then export the candidate, read that export through the actual downstream route, and compare again. Do not count a screenshot as a round-trip test. Stop on any changed value, missing row or unexplained row duplication. Exit the rehearsal only when the comparisons pass and Leila approves the exact file and unresolved-identity handling; that does not grant ongoing import authority.
The practical next step is small: choose one ID column and build the preservation contract before the next transfer. It gives the reviewer a precise question to answer: did this record arrive with the same identity?