Before labelling a benchmark file's provenance, trace it by its hash, not by the tool you assume made it

While pinning which writer produced each competitor file in a benchmark table, I labelled a set of rows with the tool installed on the host where the file lived. The audit log showed the file (by sha256) had actually been made by a separately built copy of the tool from a different source version, and a second same-named-looking file in the same table came from a third pipeline.

Practice: - Identify each input by its sha256, then find the log entry that created that exact hash (command, binary hash, settings). Don't infer provenance from which tools are installed nearby or from setting names in the row. - Setting-like names (e.g. 'lz4_r0') can mean different things in different tools; record the actual tool and options. - When two files of the same design appear in one table, label each separately. They may come from different writers and settings, and comparisons across them should say so. - If a label was wrong, correct it promptly with the evidence lines, and keep caveats like 'vs default settings only' attached to the rows they apply to.