Profile structure locally
Headers, inferred primitive types, blank rates, bounded distinct counts, length ranges, and a SHA-256 content digest are stored. Raw source rows and example values are discarded.
Handoff 09monthly parts export12 columns in, 12 columns out
Acceptedorders-2026-08.csv
order_idcustomer_idorder_dateregionquantityunit_pricecurrencyprioritywarehouse_codepromised_datesales_repnotes
Candidateorders-2026-09.csv
order_idclient_idorder_timestampquantityregionunit_pricecurrencyfulfillment_centerpromised_datenotesdiscount_codesource_system
Redline28 findings, 6 blocking
- was
customer_id - now
client_id - was
order_date - now
order_timestamp - was
warehouse_code - now
fulfillment_center - gone
priority - gone
sales_rep - new
discount_code - new
source_system - held
order_id regionquantityunit_pricecurrencypromised_datenotes
- struck a column the candidate no longer carries
- underlined a column the candidate adds
- was and now: a rename a reviewer committed, with an evidence note
See what changed before a spreadsheet quietly breaks.
This browser workbench is for analysts and data teams who receive the same CSV export again and again. Load the file your consumers accepted, load the one the producer just sent, and read the difference as a marked-up header row. Renames stay a human decision. Every finding is written against a named workbook, import, or merge.
Your files are profiled in this browser and never uploaded, so there is no account and no network step.
It opens on the bundled parts export, already compared, so the method is visible before you load anything of your own.
What the review desk does with your two files
Keep intent explicit
Suggested renames are evidence, never decisions. A reviewer commits a one-to-one mapping and writes down why the meaning is believed to survive the change.
Judge through consumers
Describe required columns, allowed inferred types, relative order, and tolerance for additions. Findings then belong to the workbook, import, or merge that actually reads the file.
A review other people can read without this app.
The passive ZIP packet holds readable HTML, CSV registers, JSON evidence, checksums, method and limitation notes, and a full restorable checkpoint. It contains no scripts and no source rows, so it survives an email thread and an audit six months later.
- 1Load the accepted baseline
- 2Load the proposed candidate
- 3Commit deliberate renames
- 4Describe each consumer
- 5Resolve and freeze the review
One month of a parts export, worked through.
The bundled sample is an accepted August file of twelve columns and a proposed September file of twelve columns. Comparing them produces twenty-eight findings, six of them blocking. Three baseline columns are simply gone. One column shifts from integer to number because a single fractional quantity appears. One column stays present while its blank rate rises by 75.0 percentage points, which no column-name diff would report at all. Two consumers described in the same project disagree completely about whether the file is acceptable, which is the point: compatibility belongs to a named consumer, not to a file.
The worked example page lists every finding, explains how to read the interesting ones, and offers the two source files and a restorable checkpoint as downloads, so you can reproduce each number before deciding whether the method suits your team.
Evidence for a conversation, not a compatibility certificate.
Type inference is observational. A profile can miss rare values or business meaning. The workbench does not execute imports, validate personal data, generate migrations, or prove that a consumer is safe. Your team still owns the decision.