Compatibility is not a property of a file. It is a property of a file and one named consumer, so the workbench asks you to describe consumers rather than deliver a single verdict. The same candidate export can be harmless to one import and fatal to another.
What a consumer policy contains
- Required baseline columns, translated through committed mappings before checking.
- Allowed observed primitive types per column.
- Whether relative column order matters.
- Whether unlisted candidate columns are tolerated.
- A free-text note describing how the consumer reads the file.
Worked example
The bundled sample carries two consumers with opposite temperaments. The monthly finance workbook requires six columns, reads them by position, allows additional columns, and expects quantity to be an integer. Against the September candidate it raises two blocking findings: order_date is absent even after mappings are applied, and the observed type for quantity is number rather than integer.
The warehouse label merge requires a much shorter list and does not tolerate unlisted columns. It raises no blocking findings at all, and instead raises eight review findings, one for each candidate column it was not told about, including client_id, order_timestamp, discount_code, and source_system. One file, two consumers, two entirely different reviews. A single global verdict would have hidden both stories.
How to write a good policy
Describe what the consumer actually depends on, not everything it receives. A workbook that reads six columns and ignores the rest should list six columns and allow additions. Over-listing produces noise that reviewers learn to skip, which is worse than no policy. If you do not know whether a consumer is order sensitive, say so in the note and leave the flag off until someone checks.
Method and limits
Policies are checked against observed structure only. The workbench does not run the consumer, open the workbook, or read the import configuration, so a policy is only as accurate as the person who wrote it. A consumer that passes every encoded policy can still fail on a value the profile never saw.
Do this in the app
Open the workbench and use the Consumers view. Add a consumer, tick the required columns, set allowed types, set the order and extras flags, then return to Findings: policy findings are labelled with the consumer that raised them.
Related reading
- The full worked exampleBoth sample consumers and every finding they raise.
- Modelling what consumers depend onA longer field note on the same idea.
- Rename reviewWhy mappings are applied before policies.