FAIR Principles: Check the Evidence Behind Reuse Claims

The FAIR principles guide how research data and metadata can be found, accessed, used across systems, and reused. They apply to people and machines. Metadata means the records that describe the data: what they contain, how they were made, and how to use them.

A public download link is only one piece of evidence. If a record has no reuse terms, a reader may be able to get the files but still not know what use is allowed. Keep that gap visible rather than marking the whole deposit “FAIR.”

What FAIR means for research data

FAIR stands for Findable, Accessible, Interoperable, and Reusable. The GO FAIR Foundation principle list sets out more detailed points within each group. Read those points alongside the needs and standards of your field.

The aim includes machine use, not just a page that a person can read. A clear web description may help a human find data, while a system also needs identifiers, structured records, and defined ways to retrieve them. The NNLM glossary explains this human-and-machine scope.

This guide offers a document review, not a formal FAIR assessment. It helps you ask which claim is supported by which record, what remains unclear, and who should check the service itself.

Read the principles as different questions

Findable: Can a person or system discover the data and tell which object the record describes? Look for a stable identifier and rich metadata in a searchable service. A filename on a private drive does not, by itself, show this.

The GO FAIR identifier principles call for persistent references. A DOI is a common persistent identifier, meaning a long-lived reference to an object. It helps, but does not settle all four principles. Check the record's title, description, creator, and link to the data as well.

Accessible: Does the record state how to retrieve the data or metadata through a defined protocol? Access may require a login or approval. DTU Library's guide explains that restricted data can still have accessible metadata.

Interoperable: Can the data and records be understood and used with other data? Check named formats, shared terms, and links to related objects. A CSV file can be easy to open while its field names still have meanings that only the author knows. The DTU practical steps help frame this check.

Reusable: Can a new user understand how the data were made and what use is allowed? Look for provenance, clear rights, and enough detail to support the intended use. Provenance means the source and history of the data, including key changes.

The KU Leuven practical guide gives examples across all four groups. Use those examples as prompts, then return to the full principles when a shorthand leaves out a needed detail.

Gather records that can support a claim

Choose one deposit or data object. Gather its public record, metadata export, README, access policy, reuse license, codebook, and any process notes. Use only material you are allowed to inspect and supply to a tool.

Use these checks to avoid treating a plan or a page as proof of every principle:

• Use a research log to record the date and version of each item. A README may describe version one while the data record links to version two; note the mismatch before making a claim.
• Separate planned handling from a completed deposit. A data management plan describes intended actions, which still need evidence that they happened.
• Read the official subprinciples before using four shorthand labels. Metadata persistence after data withdrawal is a distinct question from today's download link.
• Keep a promise in a plan, a statement in a record, and a live service test apart. Each supports a different claim, and a clear policy is not proof that the service works.

Build an evidence-and-gap table

The table below uses a fictional climate-data deposit. Its README names files and units, its record has a DOI, and access requires a request. It lacks a clear reuse license and a named shared vocabulary.

These rows are teaching examples, not results from a real FAIR audit. Add actual source locations when you apply the same structure to your own records.

Table 1: The record may support a limited claim even while a gap remains. “Fields and units are defined” is narrower than “data are interoperable.” Keep the narrower wording until the missing evidence is checked.

Use statuses such as supported by the record, unclear, conflicting, and not tested. “Not tested” is useful when a policy states that an identifier persists but you have not checked the service. Do not replace that status with a pass just because the wording sounds clear.

The NNLM definition of reuse also keeps standards and conditions in view. A download, a license, and a README answer different questions; none can stand in for every other record.

Review the supplied records in Atlas

Add the permitted records to one Atlas project. Open a chat and use @ to select the README, access policy, metadata record, and license. Name the records so the question has a clear source scope.

Ask for a bounded comparison:

For each FAIR group, cite the passages in these records that describe relevant evidence. Keep stated policies separate from tested behavior. Mark missing details and conflicts. Do not certify FAIRness or infer reuse rights from a download link.

Atlas can compare these selected records. It does not prove that the answer found every relevant passage, so read the full records that matter to your decision.

The image shows a research PDF and a cited answer side by side. Its paper is unrelated to the fictional deposit. The relevant action is checking the source behind a claim; the image supplies no evidence of FAIRness.

Open each citation and read its context. If the answer claims unrestricted reuse but the cited text only says “available on request,” correct the row. Record “access route stated; reuse conditions unclear.” If a cited location is missing, find the named record and read it yourself.

Save the corrected evidence-and-gap table as a note. Include source versions, remaining tests, and the person responsible for each question. Atlas assists the reading and record comparison. Arrange metadata validation, service tests, and any formal deposit assessment with the responsible repository or specialist.

Keep open access and FAIR claims distinct

Restricted access can have a clear route and conditions. Open data can lack useful metadata, rights, or provenance. The KU Leuven FAIR-versus-open explanation makes this distinction explicit.

Technical access also does not establish permission to reuse. Confirm the license and any applicable limits with the data owner or responsible service. Do not infer rights from a working download button.

If the review feeds a publication, a research paper appendix may explain parts of the study. It does not replace the data record, access policy, or license. Link readers to the objects they need for the reuse task.

Check one record before expanding the review

Choose one data object and one gap. Ask whether the record states the needed fact, whether other records agree, and what test would settle the claim. Assign that test to the right owner.

When the record or service changes, revisit the affected row. Keep the evidence, the gap, and the review date together so the next reader can see why you made a limited claim.