Open tools for decompression research.

What a release bundle contains

No bundle is downloadable, because no run has been released.

A download link here would name a file that does not exist. The layout below is the contract a bundle is built to, and the builder refuses to write a bundle that is missing any entry in it.

Specification 133 names 12 entries and the builder writes 13. This list is not written out on this page. It is the list the bundle builder and the shared TypeScript contract are both pinned to by a fixture, so the page cannot drift from what a bundle actually holds.

checksums.sha256

One line per file, in the two-space format sha256sum reads, covering every file in the bundle except itself. Paths are bundle relative and sorted by their UTF-8 bytes.

configurations.json

The exact parameter set each model ran with, identified by configuration identifier and parameter digest.

content_addresses.json

The digest index of specification 134 in one document, so a release gate or a reader takes every artifact digest from one place.

datasets.json

Every dataset version the run read, with its identifier, its version, its recorded checksums and its licence. Where a licence withholds the records, this document carries the reconstruction steps for a reader who holds the source data.

environment.json

The compute environment the run executed in, including the image digest and the dependency lock digest a reader checks their own environment against.

logs/

The execution logs of the run, kept because a number without its execution record cannot be inspected.

manifest.json

The run manifest. It names the code commit, the worker image digest, the dependency lock digest, the dataset versions, the model configurations, the evaluation mode and the seed policy the run executed under.

metrics.json

The metric definitions the run computed, bound to the statistical protocol version they were computed under.

models.json

Every model implementation the run called, with its adapter identity, its source identity, its declared capabilities and its verification level.

predictions/

The per-exposure model output tables. A run that produced none of these did not complete, and the builder refuses to write its bundle.

README.md

The reader's entry point: what the run was, what the bundle contains and how to check it without OpenDeco software.

summary/

The aggregated metric tables a reader compares their own reproduction against, within the tolerance the bundle states.

validation/

The validation output that had to pass before the run could be frozen.

Four of those directories must each carry at least one file. A run that produced no prediction, no summary, no validation output or no log did not complete, and the builder refuses to write its bundle.

Checking a bundle with sha256sum alone

The integrity check belongs to the reader, so it cannot depend on software the publisher wrote. Each line of the manifest is a 64 character lowercase hexadecimal SHA-256 digest, two spaces, then the bundle relative path.

The check needs coreutils and nothing else. OpenDeco writes the manifest in the plain sha256sum format for that reason, and a test in the bundle builder runs the real program against a clean bundle, a one byte change and a removed file.

Reproducing a release

opendeco reproduce <release-id>

Specification 137 fixes this verb and says it does not need to exist on day one. It does not exist. What exists is the plan it would read: the release builder writes the code commit, the image digest, the dependency lock digest and the dataset versions for each run, acquisition steps for every dataset whose records a licence withholds, and seven verification steps that begin with the checksum check above.

The publication gate refuses a release whose reproduction plan cannot be written. A missing acquisition step for a withheld dataset blocks publication, in place of surfacing to a reader afterwards.

Citing OpenDeco

Cite the commit, because no release exists yet.

The repository ships a Citation File Format 1.2.0 document at the path above. Its message asks a reader who cites OpenDeco before the first release to cite the exact commit they used, because the code on a branch keeps moving and a citation has to keep resolving to what it said.

CITATION.cff, Citation File Format 1.2.0

PLACEHOLDER-DOI-NOT-YET-MINTED

Field doi. A repository issues the DOI at deposit. Until a versioned archive has been deposited, the field carries this token and no invented value.

PLACEHOLDER-ORCID-NOT-YET-REGISTERED

Field orcid. The token is replaced by an orcid field on the author entry once an ORCID has been registered and verified.

A placeholder is a recorded gap. The release builder scans the citation document for every value that starts with the prefix PLACEHOLDER, and lists each one in the readiness report, so an unreplaced token blocks a deposit instead of travelling into one.

A released benchmark carries its own citation metadata in the release manifest. These four fields are the citation half of the eighteen that manifest declares.

Citation text

How an external author is asked to cite this release.

Related publications

Papers and preprints that report on this release.

Supersedes

The release or releases this one replaces.

Superseded by

The later release that replaced this one, once one exists.

Release identifiers

odr-XXXXXXXXXXXXC

The prefix names the object class. 12 payload symbols carry sixty bits from a cryptographic source, and the final symbol is the check symbol, the payload value modulo 37. A mistyped identifier fails that check before any lookup happens, which is why a malformed address and an unknown one answer differently.

Opaque

The allocator takes an entropy source and nothing else. It is never given the title, the version, the date or the operator, so the identifier cannot encode one. An identifier that encoded its content would stop being stable the first time the content was corrected.

Never reused

The ledger holds every identifier it has ever issued in any state. Revoking a release keeps its identifier out of the pool, and a failed gate burns the identifier allocated for it, so an old citation can never land on different work.

Stable

One string becomes the release identifier in the manifest, the last segment of the public address and the argument to the reproduction command.

Version relationships and corrections

A published artifact is immutable and a relationship discovered later is not. The release keeps its bytes, and the ledger records what happened to it afterwards.

A correction goes forwards

A correction is a new release with a new identifier that names the older release in its own supersedes field. The older release keeps its bytes, its digest, its page and its identifier, and a reader following an old citation lands on what was cited.

The reverse direction lives in the ledger

The release that will supersede this one does not exist when this one is written, so the superseded-by field cannot be written into an immutable manifest. The ledger is append-only and records that direction against the older release.

A revoked release stays readable

The record and its reason stay published under the same identifier. Deleting a release would break every citation of it and explain nothing.

Archival readiness

Specification 138 asks for release metadata a repository could accept, and warns against depending on DOI infrastructure to operate. The release builder writes a DataCite compatible record from the release manifest and the citation document, and a readiness report beside it that states, field by field, what is ready and what is outstanding.

FAIR compatibility

Specification 115 asks that release metadata map cleanly onto the FAIR principles, DataCite metadata, research package formats and common citation formats, and that the first public release be exportable as a complete machine-readable bundle. The mapping below states what carries each principle and what state it is in today.

Machine-readable metadata is written by the release builder from the run record, so a reader parses the same values a person reads on a page.

Each artifact above is produced by the release builder from the run record. None of them is served over the network today, because publishing one would mean claiming a release exists.