Turn data science research results into a checkable public table

To share data science research, export the results behind your figures—not just a screenshot of the chart. A useful public table lets readers find a result, understand how it was calculated, and trace it to the corresponding data and code.

For a model-comparison study, the deliverable can be small: a reviewed results CSV, a data dictionary, a methods README, and a public page for exploring the table. Keep the reproducibility files in a research repository; use the interactive page as the readable entry point.

1. Define what one row represents

Start with a specific question: How accurately do the candidate models predict delay, measured in minutes, under the same evaluation protocol?

Use one row per model configuration, evaluation split, random seed and metric. A split identifies which observations were used for training and evaluation. A seed records an input used to control randomness; it is not a complete description of an experiment.

The following table is fictional sample data, illustrating structure only. These are not measured research results.

run_id	model	split_id	seed	metric	value
R001	Baseline	holdout_A	42	mae_minutes	8.4
R002	Linear regression	holdout_A	42	mae_minutes	6.1
R003	Decision tree	holdout_A	42	mae_minutes	6.0

Here, mae_minutes means mean absolute error: the average absolute difference between predicted and observed delay. Lower MAE means smaller errors on this evaluation set.

Assign each run_id to an exact model configuration, split and seed in a companion run manifest. Record the source dataset version, evaluation sample count, preprocessing settings and code version there. If those details vary across rows, expose the relevant identifiers or counts as columns too. When recording several metrics for one run, repeat its run_id; the combination of run_id and metric should be unique.

Do not mix individual runs and averages in the same value column without an explicit field distinguishing them. For repeated runs or cross-validation, retain the underlying run or fold results and publish any summary separately.

2. Check the experiment before formatting its results

A clean table cannot repair an invalid evaluation. Before exporting, confirm that:

• Compared models use the same documented evaluation observations and metric definition.
• Preprocessing learned from training data is applied consistently to evaluation data.
• Held-out test data did not influence feature selection, preprocessing fitting or model tuning; document validation data used for tuning separately.
• The release includes the baseline and relevant runs, rather than only the best-looking result.

The scikit-learn guidance on common pitfalls explains that data leakage can produce overly optimistic performance estimates. It recommends splitting before learned preprocessing and keeping test data out of fitting and model-selection decisions.

Document the random-state settings for both the model and the splitting procedure, including what the table’s seed controls. Preserve split assignments where sharing them is permitted; a seed alone does not capture the input data, software environment or full procedure.

For the sample table, the difference between 6.1 and 6.0 is not enough by itself to establish a reliable winner. Readers also need the evaluation design and evidence about variability.

3. Package definitions and provenance

Create a data dictionary with one entry per column: its meaning, type, units, allowed values and missing-value convention. Harvard Medical School’s data-dictionary guidance recommends documenting variable definitions, units and allowed values so others can interpret and reuse a dataset.

For this example, explain that split_id refers to an archived split definition and that run_id joins to the run manifest. Keep identifiers as text. Do not encode a failed run as zero error; use a documented missing value and a separate status field.

The README should identify:

• The research question, authors, release date and version.
• Source datasets, their versions and applicable reuse terms.
• Inclusion rules, exclusions and transformations.
• Evaluation protocol and metric calculation.
• Code revision, dependencies and instructions for regenerating the results.
• Known limitations, license and recommended citation.

These files document provenance: where the data came from and what happened to it. The FAIR principles call for detailed provenance, clear usage licenses, rich metadata and persistent identifiers—not merely a public link.

4. Export only the public release

Generate a separate release file from the reviewed analysis output. Use a single header row, consistent column types and unrounded values where appropriate. Keep presentation rounding separate from the underlying results. For format trade-offs, see why convert data to CSV before sharing.

Before uploading, check row counts, uniqueness of each run_id–metric pair, missing values and agreement with the reported figures. Inspect the entire release for confidential fields, identifying information and material you lack permission to redistribute. Do not upload sensitive research data to a public publisher.

Removing names is not automatically sufficient. Oxford’s research-data sharing guidance discusses anonymisation limits, third-party restrictions and controlled-access archives when open sharing is unsuitable.

5. Publish an exploration page and preserve the release

As of October 24, 2026, TablePage supports CSV, TSV, XLSX and XLS uploads and generates public dataset pages with filterable tables and shareable links. Upload only the reviewed release file, then inspect the resulting page for altered identifiers, unexpected numeric parsing, missing rows and incorrect labels.

Test a reader task: can someone find R002, identify its metric and split, and locate the corresponding methods and configuration? Put those explanations and links in the accompanying project page or repository documentation; do not assume the table explains itself.

Deposit the versioned results, dictionary, README and supporting code in an appropriate research repository. Oxford cautions against relying on a project website alone for long-term availability and recommends depositing a copy in an archive alongside it.

When correcting results, issue a new release version and describe what changed. Identify the exact archived release represented by the public table in its accompanying documentation.