An import needs a rehearsal.

Suppose a seed-swap organizer wants to bring a spreadsheet into a new collection tool. Each row has a variety, an amount, and a date. The spreadsheet also has a few notes that did not fit neatly anywhere else.

The imaginary tool announces that it recognizes the file. That is encouraging. It is not yet evidence that it understands the collection.

Does “amount” mean seeds or packets? Is the date when the seed was collected, received, or entered into the spreadsheet? A file can be readable while those questions remain unanswered.

An import should give someone a chance to rehearse the interpretation before it becomes saved work.

Map the meaning, not just the column

For this hypothetical seed collection, show the source headings beside the destination fields. Include representative values so the person can see what each choice would do.

A date column containing “03/04” needs more than a green checkmark. Ask for the intended convention when the input is ambiguous. Do not choose silently and then describe the records as successfully imported.

Keep the original values available during review. If the importer changes a date or splits a quantity into a number and a unit, show that interpretation. Let someone correct the mapping without uploading the file again.

Some information may have no destination. Name those omissions. A note about uncertain variety identification should not disappear merely because the new schema has a tidy variety field.

Use a practice collection

Before trusting an importer with a real collection, build a small fictional fixture with awkward records. Include two varieties with the same name from different sources, a blank amount, and a note with line breaks. Add a date whose interpretation needs a choice.

A rehearsal with this fixture would give those awkward decisions somewhere to surface before anyone brings in a real collection.

Run the rehearsal in a separate test destination. Compare the saved records with the source, including relationships and notes. A count of rows alone cannot tell you whether packets have become seeds or whether two distinct entries have been combined.

Try the same file again under the importer’s intended duplicate policy. If repeated imports are supposed to update records, check which identifier connects them. A matching name is not automatically a matching record.

Explain the commitment

The final review should say what will be added, what will update existing work, and which rows remain unresolved. Keep unresolved rows reachable so the person can address them without reconstructing the source.

If only part of the file can be imported, make that a deliberate choice. Explain whether the person can finish those rows later and how the tool will distinguish them from ones already saved. Do not promise an undo unless there is an implemented and checked recovery path.

This complements a useful export, but asks a different question. The export should preserve meaning on the way out. The importer needs to show which meaning it will assign on the way in.

For the seed organizer, a successful rehearsal would reveal the packet-versus-seed distinction before it affects the collection. Recognizing the file is a beginning. Understanding what its columns mean is the work.