Archive and DOI deposition packet

Packet ID: LL-FDE-ARCHIVE-001
Version: 0.1.0
Status: deposition-ready template; no archive provider, deposit, reserved identifier, registered DOI, or preservation owner is established

1. Purpose

This packet binds one approved release to a durable archive and version-specific persistent identifier. It prevents four common failures: citing a mutable website, displaying a placeholder DOI, depositing bytes that differ from the approved release, and assuming a provider upload is verified preservation.

Zenodo DOI versioning, Zenodo’s GitHub integration, and GitHub citation guidance describe one possible route. No provider is selected by this template.

2. Provider due diligence

The publication owner, licensing owner, privacy/security owner, and preservation owner record:

A public archive must never receive identity documents, raw participant data, confidential customer material, secrets, private references, protected assessment content, or another restricted artifact merely to make a release appear reproducible.

3. Release-freeze prerequisite

Before reserving or registering an identifier, freeze:

• exact publication class, title, version, publication date, status, and canonical URL;
• named creators, affiliations, ORCID identifiers where approved, and organizational author;
• abstract, keywords, language, funding, conflicts, AI-use, data/materials, and review statements;
• operative code/content/data licenses and third-party-rights disposition;
• Git commit and signed tag;
• source manifest, package manifest, file digests, and total bytes;
• signed publication decision and all gate receipts; and
• predecessor, successor, correction, retraction, and related-identifier mappings.

Any changed byte after freeze creates a new package digest and repeats affected approvals.

4. Metadata worksheet

release_id:
version:
publication_class:
title:
subtitle:
organizational_creator:
individual_creators:
  - display_name:
    affiliation:
    orcid:
    credit_roles: []
publication_date:
description:
keywords: []
language:
license_id:
canonical_url:
repository_url:
git_commit:
git_tag:
source_manifest_sha256:
package_sha256:
related_identifiers:
  is_version_of:
  is_new_version_of:
  is_previous_version_of:
  is_supplement_to:
funding_statement:
conflict_statement:
ai_use_statement:
data_materials_statement:
review_status_and_scope:
corrections_url:

Unassigned people, licenses, dates, DOIs, and relationships remain blank or explicitly pending. Never use plausible placeholders in public metadata.

5. Deposit file manifest

The citable package should contain, as applicable:

1. publication PDF/HTML/Markdown and accessible text;
2. benchmark specification, card, methodology, status register, and changelog;
3. ontology, schemas, machine-readable data, and data dictionaries;
4. analysis code, environment lock, and reproduction instructions;
5. source ledger, references, disclosure, authorship, review, and publication-decision records;
6. public instruments, protocols, codebooks, and synthetic fixtures safe to release;
7. CITATION.cff, BibTeX, license files, README, source manifest, package manifest, and checksums; and
8. correction/retraction policy and monitored reporting URL.

Each manifest row records relative path, media type, byte count, SHA-256 digest, rights state, and withholding reason. Paths must be unique and traversal-free.

6. Deposit sequence

1. Create the release candidate from the signed tag in a clean environment.
2. Run the complete release gate and record logs.
3. Generate the source and package manifests.
4. Compare root/public citation metadata and publication front matter.
5. Review each file for rights, privacy, secrets, direct identifiers, controlled tasks, and confidential content.
6. Reserve an identifier only after provider and metadata review if the provider supports reservation.
7. Insert the reserved identifier into citation/front-matter files only according to the provider’s supported workflow; rebuild and re-freeze if this changes bytes.
8. Obtain the final release decision for the exact package digest.
9. Deposit and register the version.
10. Download the public deposit into a clean directory; independently regenerate checksums and run the reproduction/readability checks.
11. Verify DOI/PID resolution, provider record, canonical URL, citation export, license, creator order, related identifiers, and accessibility of public files.
12. Publish the verified deposition receipt and update the canonical page.

7. DOI and version policy

• Cite empirical findings and exact methods with the version-specific DOI/PID.
• Use a concept DOI only for the evolving benchmark family, never to conceal which version produced a result.
• A corrected release receives the provider-supported version relationship and links to the correction notice.
• A retracted release keeps its DOI/PID resolving to a tombstone and preserved record with authority withdrawn.
• A website slug, Git branch, draft DOI string, or unpublished reservation is not a registered identifier.

8. Independent post-deposit verification

The metadata reviewer, who is not the depositor, records:

PROVIDER RECORD URI:
VERSION DOI/PID AND RESOLUTION RESULT:
CONCEPT DOI/PID AND RESOLUTION RESULT, IF APPLICABLE:
DOWNLOADED PACKAGE SHA-256:
SOURCE/PACKAGE MANIFEST MATCH:
FILE CHECKSUM RESULT:
METADATA/CITATION MATCH:
CANONICAL AND VERSION LINK RESULT:
LICENSE/RIGHTS RESULT:
REPRODUCTION OR READABILITY RESULT:
VERIFIED AT:
VERIFIER AND SIGNED LOG DIGEST:

Machine receipts conform to SCHEMAS/research-ops/0.1.0/archive-deposition-receipt.schema.json. deposit_state: verified requires real identifiers, successful download/checksum verification, approved rights, and separate preservation and release approvals.

9. Current disposition

The packet is ready to complete, but all provider, person, license, identifier, deposit, and verification fields remain pending. No DOI should appear on the site or in a citation until a real verified receipt exists.