Load the export that downstream consumers last accepted, load the proposed one, commit only the renames a person can defend, describe each consumer, then dispose of every finding and freeze. Five steps, about five minutes for a file of ordinary width, and the output is an evidence packet rather than an opinion.

Worked example

The bundled sample is a monthly parts export. The accepted August file has twelve columns beginning order_id, customer_id, order_date, region, quantity. The September candidate has twelve columns too, but three baseline columns are gone, three new ones appear, and several moved. Running the five steps on it produces twenty-eight findings, six of them blocking. Two of the blockers are structural (order_date and priority are simply absent), one is a type shift (quantity was every-value-integer in August and carries 2.5 in September), and two are consumer policy failures raised by the finance workbook. Without the sequence below you would probably have noticed the missing order_date and missed the quantity shift entirely.

Step one: choose the accepted reference

Use the last file downstream consumers actually accepted, not merely the most recent file you received. A file that arrived and was never successfully imported is not a baseline; it is a second candidate. Label it with the period it covers so the frozen packet reads clearly a year from now.

Step two: profile the candidate

Choose encoding and delimiter, or leave both on automatic detection and confirm what was detected. Parsing is strict on purpose: ragged rows, duplicate headers, unbalanced quoting, and headers that would be unsafe in a spreadsheet are refused rather than repaired. A refusal at this step is information about the producer's pipeline, so record it before asking for a corrected file.

Step three: commit only confirmed renames

Name similarity is a lead, never proof. customer_id to client_id looks obvious and is still a claim about business meaning that only the producer can confirm. Commit the mapping once someone has confirmed it, and write who confirmed it in the mapping note.

Step four: describe consumers narrowly

List only the columns and structural assumptions each workbook, import, or merge really depends on. The sample's finance workbook depends on six columns, reads them by position, and expects quantity to be an integer. That narrow description is what turns a general observation into a specific blocker.

Step five: dispose and freeze

Give every finding an outcome and a note, then freeze a review point and export the passive packet. Later edits appear as amendments against the frozen point rather than silently rewriting the record.

Method and limits

Everything above rests on observed structure in the files you loaded. A column that happens to be integer in four sample rows is reported as integer; that is an observation about this file, not a guarantee about next month's. The workbench does not execute a consumer, so a green review means "no encoded structural finding", not "the import will succeed".

Do this in the app

Open the workbench and use the view switcher across the top: Overview to load both files, Columns to inspect profiles side by side, Mappings to commit renames, Consumers to encode expectations, Findings to dispose, and Packet to freeze and export. Choose Open sample on the overview to follow the example above with the same numbers.

Related reading