Publish a synthetic supplier example with honest provenance

Put the synthetic label where the data travels

Show the synthetic source, extracted values and remaining review steps so they can judge what the example actually demonstrates.

Our public material-register example shows a synthetic report beside downloadable output. Use it to inspect how values and source references travel together. The self-service ParseMill trial is for invoice PDFs; supplier test reports and engineering review need a separate fit discussion.

Use invented organization names and identifiers, and avoid reproducing a real supplier’s certificate design in a way that suggests endorsement. State the example’s purpose, such as demonstrating source references or missing-value handling. Do not imply that plausible-looking numbers came from laboratory work or a real delivery.

Maintain a small provenance manifest

Record example identifier, version, creation date, authoring method, input files, generated outputs and intended learning task. W3C: Data Catalog Vocabulary version 3 distinguishes descriptions of datasets and their distributions. Apply that distinction by describing the illustrative dataset separately from its PDF and spreadsheet files, including the version of each.

Keep a plain-language note beside the manifest. Explain which values were invented, whether any data came from a public source, and what transformations produced the example. If a real source was used, verify its permitted use and attribution separately rather than calling the entire result wholly invented.

Use an honest example record

Synthetic planning fixture: the following manifest describes an illustrative release checklist. Its checks are proposed outcomes, not a claim that these files have already been created or tested.

When an actual example is produced, replace planned-check descriptions with the checks truly executed and their results. Retain failures and limitations. A screenshot showing a workbook is evidence of appearance, not proof that every value survived a round trip.

Report execution separately from expectations

W3C: PROV Data Model models entities, activities and responsible agents. Use those distinctions to name the input artifact, the extraction or editing activity, and the person or tool responsible. Record manual corrections separately from automatic output so readers can understand how the final register was obtained.

An expected answer sheet can be useful, but label it as expected until it has been compared with an actual output. If a demonstration required manual repair, state the repaired fields and why. Do not turn one successful invented example into a percentage accuracy claim or a statement about all supplier layouts.

Review the example as a detached recipient

Open each downloadable artifact without the surrounding webpage. Confirm that its synthetic origin, version and intended purpose remain visible. Check that links resolve to the corresponding source files and that the workbook contains no private metadata, customer names or unrelated sheets. Preserve an archived copy of the released version.

Use ParseMill’s public material-register example as a reference for the type of workflow you want to demonstrate, then document your own actual trial separately. Publish only the behavior you observed and the limitations you can support. An honest small example gives readers a reproducible starting point and makes later product evaluation more informative.