F1 ยท Publication Volume 30

Final Reproducible Package

data manifests, versions, builds, audit and static demonstration

Learning objectives and boundary

  • Explain data manifests, versions, builds, audit and static demonstration as an auditable evidence problem.
  • Separate source observations, controlled derivatives, interpretation and decision state.
  • Apply identity, spatial, semantic, lineage, quality and review checks.
  • Produce a self-contained synthetic evidence package, clean-build audit and static demonstration.

This lesson is part of a general, institution-neutral tutorial and has no relationship to any company or individual. All identifiers, geometries and values in the worked case are explicitly synthetic. The method does not confer professional authority and must not be transferred to a real decision without appropriate sources, competence, law and review.

Core method

The final package is a closed, inspectable evidence object. Its root manifest names the charter, source register, admitted distributions, schemas, coordinate operations, processing graph, drillhole versions, view states, hypotheses, claims, holdout record, reviews, limitations, build recipe and content digests. Every path is relative or resolvable, every generated artefact identifies its inputs, and no secret or changing endpoint is required to inspect the static demonstration.

Reproducibility has levels. Bitwise identity may be possible for packaged assets; computational repeatability requires pinned environments and deterministic operations; scientific reproducibility requires the evidence and reasoning to support the same evaluation, not necessarily identical pixels. Verify the package from a clean directory, offline where practical. Produce machine-readable validation results and a human-readable audit. The static demonstration is a view over the package, not a substitute for it.

A reproducible package binding charter, sources, data, transformations, claims, review and static delivery
A reproducible package binding charter, sources, data, transformations, claims, review and static delivery

Record and evidence model

| Field or object | Operational meaning | |---|---| | package_id, version and root_digest | release identity | | manifest_entry | path, media type, size, digest and role | | build_environment and recipe | pinned tools and ordered operations | | validation_result | rule, subject, result and evidence | | release_note and limitations | scope, changes, failures and prohibited uses |

Every record carries a version, validity interval, source or derivation link, quality state and review state. Missing, unknown, not applicable and failed are separate states; none is silently represented as zero or an empty string.

Controlled workflow

  1. Assemble only admitted, licensed and versioned objects.
  2. Generate a root manifest and content digests.
  3. Pin schemas, operations, environments and build order.
  4. Rebuild from a clean workspace and validate offline paths.
  5. Compare outputs, inspect differences and preserve failures.
  6. Release the package, audit and static view under one version.

Record each step as an activity with declared inputs, parameters, outputs and checks. A rerun creates the same content or a documented difference; it never overwrites the evidence needed to explain the previous state.

Worked synthetic example

SYN-WB release 1.0 contains 48 synthetic source and derived objects. A clean rebuild reproduces all vector and table digests; one raster differs because a resampling environment was not pinned. The release is withheld, the environment is fixed, version 1.0-rc2 is built and the difference audit passes. The final static view opens without network access and every target card resolves to packaged evidence, review state and limitations.

The example is deliberately small enough to inspect row by row. Its names and numbers are fictional teaching values and cannot be used to infer a real place, right, resource, hazard or organisation.

Quality control and failure modes

Run six gates before accepting the lesson artefact: identity resolves the exact objects; spatial control confirms coordinate and extent validity; semantics preserve units, vocabularies and epistemic class; lineage exposes every transformation and dependency; quality records passed, failed and not-run checks; review binds a disposition to the exact content digest. A failed gate is retained as evidence and blocks only the affected use. It is never converted into a favourable value or hidden to simplify the display.

Common failure modes:

  • Shipping files without a root manifest
  • Depending on a changing online response
  • Calling a screenshot the reproducible package
  • Ignoring a build difference because it looks small
  • Publishing success logs while discarding failed validation

Practical exercise

Complete the following tasks against a new copy of the synthetic package:

  1. Design the root manifest schema.
  2. Classify bitwise, computational and scientific reproducibility.
  3. Perform a clean-room package audit.
  4. Write a release note that keeps limitations and failed checks visible.

For every answer, cite the package object IDs, show the failed as well as passed checks, and state which conclusion would change if one assumption were reversed.

Completion artefact and verification

Deliver a self-contained synthetic evidence package, clean-build audit and static demonstration. Include a manifest, exact input identities, transformation or reasoning record, machine-readable validation results, human-readable limitations and the current review state. A second reader must be able to trace one accepted conclusion to its source support, one rejected path to its first failed gate and one unknown to the evidence required to resolve it. Rebuild the artefact from a clean location and compare content digests. Completion is withheld when a required source, parameter, permission or review is missing; no substitute data are invented.

Sources