FAIRy documentation

Validation categories

• Metadata completeness: Required fields, data types, and format validation
• File organization: Naming conventions, directory structure, and file formats
• Repository-style expectations: sample/platform annotations, organism/host fields, accession-aware filenames, and other elements commonly required at submission time
• Data integrity: Checksums, file sizes, and format validation
• Reuse signals: license clarity, contact information, and basic attribution info so a curator (or future user) knows who to reach and how it can be shared

Why attestation matters

The attestation file provides documented proof that validation was performed, which is valuable for:

• Institutions: Demonstrate that you have records of validation performed before submission, reducing administrative back-and-forth.
• Journals: Show that data quality checks were performed using standardized validation rules and versioned rulepacks—demonstrating due diligence.
• Grant panels: Prove that your institution has processes in place to streamline data deposition and reduce friction for data publication.

What the attestation file includes

• FAIRy version and rulepack used: Documents which validation rules were applied and in which version.
• Validation timestamp: Records when the validation was performed.
• Summary of checks performed: Lists what was validated (e.g., dates normalized to ISO 8601, IDs validated, units standardized, ORCIDs present and well-formed).
• File hashes and manifest information: Provides SHA-256 checksums for data files to verify integrity.
• Repository dry-run results: Shows whether the dataset passed preflight checks for specific repositories (e.g., GEO, Zenodo).

Sample attestation file

You can download a sample attestation file to see what it looks like:

Download sample attestation file (FAIRy_attestation_example.json)

Learn more about how attestation helps with compliance and due diligence in our institutions documentation.

Note: This is illustrative; production attestation files include a signed JSON format for institutional deployments.

Local-only processing

All validation runs inside your environment (laptop, lab machine, core facility server, HPC cluster, etc.).

FAIRy does not send your raw data, filenames, sample IDs, coordinates, or metadata to us.

Institution control

You decide where reports are written and who sees them. FAIRy produces:

• a human-readable readiness sheet (PASS / WARN / FAIL, why it matters, how to fix), and
• a machine-readable summary.

You can share those internally without sharing the underlying data.

No phoning home

FAIRy does not collect usage analytics or send telemetry.

We don't phone home with filenames, metadata, run logs, or error details.

The only information we receive is what you explicitly choose to send us (for example, if you fill out a pilot interest form).

Data use

We do not use your datasets or metadata to train models or build products.

FAIRy is designed to be run locally so your data stays under your control.

FAIRy-core (CLI + validators)

Licensed under AGPL-3.0-only. This ensures the core validator remains open while allowing commercial licensing options for organizations that require it.

Rulepack schema & example rulepacks

Licensed under CC0 (or CC BY-4.0). This encourages community rulepack sharing and avoids license contamination concerns.

Sample datasets

Licensed under CC BY-4.0, allowing reuse with attribution.

Hosted UI / orchestration

Proprietary or source-available (when available).

Core pilot promise

FAIRy’s job is simple:

One run → a human-readable readiness sheet (PASS / WARN / FAIL + how to fix) → plus a structured summary you can archive.

APA Style

Slotnick, J. (2025). FAIRy Core (Version 0.1) [Computer software]. Datadabra.
https://github.com/yuummmer/fairy-core

BibTeX

@software{fairy2025,
  author = {Slotnick, Jennifer},
  title = {FAIRy Core},
  year = {2025},
  version = {0.1},
  publisher = {Datadabra},
  url = {https://github.com/yuummmer/fairy-core}
}