FAIR package pre-check checklist
Use this checklist to review a completed research data package before it is submitted for curation, deposited in a repository or published.
The checklist verifies that the expected files are present, documented and consistently described, that access and reuse conditions have been defined, and that the package contains sufficient information for verification, preservation and reuse.
Resource information
Resource type
FAIR data package quality-control checklist
Intended users
Dataset authors, data curators, data stewards and repository depositors
Recommended use
Final package review before curation, repository deposit or publication
Status
Recommended pre-submission checklist of the Competence Center
Download the checklist
Use the XLSX version to record review results, evidence, unresolved issues, responsible persons and corrective actions. The DOCX version is suitable for internal review and approval.
Available formats
What is a FAIR data package?
A FAIR data package is an organised collection of research data, metadata, documentation and supporting files prepared for preservation, publication and reuse.
Its exact composition depends on the discipline and research method. A package may include raw or processed data, scripts, configuration files, software-environment information, provenance records, visualisations and supporting documentation.
The checklist reviews the package as a whole
Individual files may be technically valid while the complete package remains inconsistent. The pre-check therefore compares file paths, versions, names, metadata, documentation, access conditions and relationships across all package components.
Expected package components
Not every package requires every component. The selected elements should reflect the actual research method, data types and intended reuse.
Research data
Raw, processed, derived or final data files, together with structures, models, tables, images or other research outputs.
Documentation
README, methodological descriptions, data dictionaries, codebooks, protocols and instructions for interpreting the files.
Structured records
Manifest, dataset metadata, checksums, provenance records, workflow descriptions and software-environment information.
Access and reuse information
Licence, rights statement, access category, embargo, restrictions, citation information and contact details.
Minimum package for pre-check
At minimum, submit the principal data files, a README, a file inventory or manifest, a draft metadata record and information about access and reuse conditions.
Add scripts, configuration files, provenance, software-environment records and quality-control evidence whenever they are required to understand or reproduce the results.
Detailed pre-check checklist
Verify each criterion against the actual package. Record the relevant file, metadata field, URL or other evidence in the downloadable checklist.
| Area | Pre-check criterion | Expected evidence |
|---|---|---|
| Package identity and scope | The package represents a clearly defined dataset or research output. | Title, description and scope statement |
| The package version is identified. | Version in README and metadata | |
| The responsible creators and contact person are identified. | Creator and contact fields | |
| The contents correspond to the stated scientific purpose. | README and file inventory | |
| Temporary, duplicate and unrelated files have been removed. | Reviewed final directory | |
| Files and organisation | The folder structure is clear and consistent. | Package directory structure |
| File names are meaningful and follow a consistent convention. | Actual file names | |
| Relative paths are used in documentation and structured records. | Manifest, metadata and workflow files | |
| File extensions correspond to the actual file formats. | File inspection or validation | |
| Raw, processed, derived and final files can be distinguished. | Folder structure or file-role fields | |
| Compressed archives can be opened and contain the expected files. | Archive validation result | |
| Files that require special software are clearly identified. | README and format information | |
| README and documentation | A current README is present in the package root. | README.md or equivalent file |
| The README explains the purpose and content of the package. | Overview section | |
| The README explains the directory and file structure. | File-structure section | |
| Methods of data creation, collection or processing are documented. | Methods section or supporting document | |
| Required software, instruments or workflows are identified. | Technical requirements section | |
| Known limitations and quality issues are documented. | Limitations or quality section | |
| Manifest and integrity | A manifest or structured file inventory is included. | manifest.csv, XLSX or JSON |
| Every principal file has a manifest record. | One record per file | |
| Manifest paths correspond exactly to the package paths. | Successful path comparison | |
| File roles and descriptions are consistent with the README. | Manifest and README comparison | |
| File sizes have been recorded where required. | size_bytes values |
|
| Checksums have been generated for principal or preservation files. | Checksum and algorithm fields | |
| Dataset metadata | A structured metadata record is available. | Metadata profile, JSON or repository draft |
| The dataset title is identical across metadata and documentation. | Metadata–README comparison | |
| Creator names and affiliations are represented consistently. | Creator and affiliation fields | |
| ORCID and organisation identifiers are included where available. | ORCID and ROR fields | |
| The description explains the content, purpose and scope. | Description field | |
| Keywords, scientific domain, methods and formats are recorded. | Relevant metadata fields | |
| Related publications, software, projects and datasets are identified. | Related identifier records | |
| Provenance and reproducibility | The origin of the principal files can be determined. | README, manifest or provenance record |
| Input, output and derived files are connected where relevant. | Relationships or workflow metadata | |
| Scripts and configuration files required for reuse are included. | Scripts and configuration directories | |
| Software names and versions are documented. | README or environment file | |
| Execution environment or dependencies are recorded where needed. | Environment YAML, requirements file or container reference | |
| Quality-control and convergence evidence is included where relevant. | Validation logs, tables or reports | |
| Access, rights and reuse | The access category is explicitly defined. | Open, restricted, embargoed or closed |
| Restrictions and access procedures are documented. | Access statement | |
| Personal, confidential or sensitive data have been reviewed. | Documented review decision | |
| The rights holder and authority to publish have been confirmed. | Rights statement or internal approval | |
| A licence or reuse statement has been selected. | Licence identifier or rights statement | |
| The selected licence is consistent across files and metadata. | README–metadata–repository comparison | |
| A recommended citation can be prepared. | Citation statement | |
| Technical validation | Principal files can be opened with the stated software. | File-opening test |
| Structured files are syntactically valid. | JSON, CSV, XML or YAML validation result | |
| Tables use consistent separators, encoding and column structure. | CSV or spreadsheet inspection | |
| Text-based files use a suitable character encoding. | UTF-8 where appropriate | |
| Links and referenced paths resolve correctly. | Successful link and path check | |
| No passwords, tokens, credentials or unintended confidential files are present. | Security review | |
| Final consistency | File names and paths match across the README, manifest and metadata. | Cross-file consistency check |
| Title, version, creators, licence and access conditions are consistent. | Cross-record comparison | |
| All files declared in documentation are present. | Directory and documentation comparison | |
| All important package files are declared in the manifest. | Manifest completeness check | |
| The final package version has been approved for submission. | Named reviewer and review date |
How to record the result
Record both the status and the evidence used to verify each criterion.
Yes
The criterion is satisfied and supporting evidence is available.
Partly
The criterion is addressed, but correction or completion is required.
No
The criterion has not been satisfied.
Not applicable
The criterion does not apply to this data package.
Needs clarification
Specialist advice is required before a decision can be made.
How to use the checklist
1. Freeze
Prepare a clearly identified package version for review.
2. Inspect
Review the files, documentation and structured records.
3. Compare
Check consistency between the README, manifest, metadata and actual package.
4. Correct
Resolve missing files, invalid paths, metadata gaps and rights issues.
5. Approve
Record the reviewer, review date and approved package version.
Issues that should block submission
The package should not proceed to deposit until the following critical issues have been resolved.
Missing principal files
Required data, metadata or documentation files are absent or cannot be opened.
Unresolved rights or sensitivity
Authority to publish, licence, confidentiality or personal-data issues remain unclear.
Material inconsistencies
File paths, versions, titles, creators or access conditions conflict across package records.
Security-sensitive content
Credentials, tokens, internal secrets or unintended restricted information are present.
Record the package review
The completed checklist should record the package title and version, review date, reviewer, unresolved issues, corrective actions and final decision.
Recommended decisions: approved, approved with minor corrections, revision required or specialist consultation required.
Important notes
- Apply the checklist to a fixed and clearly identified package version.
- Review the actual files rather than relying only on the README or author statements.
- Record evidence for each important decision.
- Use relative paths consistently across the manifest, metadata and workflow records.
- Generate final checksums only after the files have been completed and frozen for submission.
- Re-run the pre-check whenever files are added, removed, renamed or replaced.
- Do not include passwords, API keys, authentication tokens or security-sensitive configuration values.
- Repository-specific deposit requirements should be checked in addition to this general package review.
- Passing this pre-check does not replace repository review, disciplinary validation or formal FAIR assessment.