If you've written a data management plan in the last few years, you've probably typed "our data will be FAIR" and moved on. Funders ask for it, repositories advertise it, and most people who use the word couldn't list what it covers. That's not a failing. The original principles are short, but they're written for people who build data infrastructure, not for a researcher with a spreadsheet and a deadline.
This guide translates them. It covers what each letter asks of you, what FAIR doesn't require (the part people get wrong most often), and a checklist you can use on your next dataset.
Where FAIR came from
The FAIR Guiding Principles were published in 2016 in Scientific Data by Mark Wilkinson and a long list of co-authors from universities, funders, publishers, and industry. The goal was a short, shared list of what makes data reusable. GO FAIR, an international initiative, now keeps the principles online as a reference.
One detail explains a lot of the wording: the principles care about machines as much as people. A human can read a messy web page and work out what a file is. Software that searches thousands of repositories can't. So FAIR leans on identifiers, standard metadata, and shared vocabularies, the things a computer can read without guessing.
There are fifteen principles grouped under four letters. Here's what they mean in practice.
F is for findable
Someone who needs your data should be able to discover that it exists. The principles ask for:
- A persistent identifier (F1). In practice, a DOI (here's how DOIs, ORCID iDs, and ROR IDs fit together). A link to your lab website or a shared drive doesn't count, because those break.
- Rich metadata (F2). A title, creators, a description, keywords, dates, and the methods that produced the data. More than the minimum form asks for.
- Metadata that name the identifier (F3). The description and the DOI point at each other.
- Registration in a searchable place (F4). A repository that search engines and data indexes can crawl.
You rarely do any of this by hand. Deposit in a repository that issues DOIs and it handles F1, F3, and F4. F2 is on you: the metadata are only as good as what you type into the form.
A is for accessible
Once someone finds the data, they should be able to learn how to get them. The principles ask that data can be retrieved through their identifier using a standard, open protocol (in plain terms, a web link that works), that the protocol allows for login and permission steps where needed, and that the metadata stay available even if the data themselves are withdrawn.
That last point matters more than it sounds. If a dataset has to be taken down, the record that it existed, who made it, and how it was cited should still be there. Papers that cite it shouldn't lead to a dead end.
I is for interoperable
Your data should work alongside other data and other software. The principles ask for formal, shared ways of describing things, vocabularies that are themselves FAIR, and references to related data.
For most researchers this comes down to a few habits:
- Save in open, widely readable formats (CSV rather than a proprietary statistics file, or both).
- Use standard codes where they exist: ISO country codes, FIPS codes, IPEDS unit IDs, controlled subject terms in your field.
- Link related things: the paper, the code, the earlier version, the source dataset you built on.
The guide to organizing research data covers file naming in more detail, and the guide to research data file formats covers which formats last.
R is for reusable
The goal of the other three letters is this one. Someone who gets your data should be able to use them correctly without emailing you. The principles ask for a clear license (R1.1), a record of where the data came from and how they were processed (R1.2), and metadata that meet the standards of your field (R1.3).
The license is the step people skip. Data with no license leave a careful reuser unsure what they're allowed to do, and some will simply not use them. For most public research data, CC0 or CC BY is the simple choice; your repository will usually offer both. Provenance is the other gap: a README that says where the raw data came from, what you cleaned, and which script produced each file. The reproducibility guide shows how to set that up while you work, not at the end.
What FAIR doesn't require
FAIR isn't the same as open. This is the most common misreading. The accessible principle is about a clear, standard route to the data, and it explicitly allows for authentication and authorization. Interview transcripts, student records, or health data can sit behind an application and a data use agreement and still be FAIR, as long as the metadata are public and the steps to request access are spelled out. The repository guide covers where that kind of data can go, and the data ethics guide covers the consent side.
FAIR isn't a certificate. There's no FAIR stamp for a dataset. There are self-assessment tools and automated checkers, and repositories can earn trust certifications like CoreTrustSeal, but FAIR is a direction to move in. "More FAIR" is a fair claim; "fully FAIR" usually isn't.
FAIR isn't only for big data. A 400-row survey file with a clear codebook and a DOI can be more reusable than a terabyte of undocumented sensor output.
A checklist for your next dataset
You don't need to memorize fifteen principles. If you do these things, you're most of the way there:
- Deposit in a repository that issues DOIs, not a personal website or a cloud folder.
- Fill in the metadata properly: a specific title, all creators (with ORCID iDs if you have them), a real description, keywords, and dates.
- Include a README that explains what each file is, how the data were collected, and what was changed.
- Include a codebook or data dictionary: variable names, labels, units, and codes for missing values.
- Save in open formats, and keep the original format too if converting loses anything.
- Choose a license.
- Link the dataset to the paper and the code, and link back from the paper with a data availability statement and a proper data citation.
- For restricted data, describe the access process in the public record: who to contact, what they'll need to sign, and roughly how long it takes.
How to write about FAIR in a data management plan
Reviewers have read "data will be made FAIR" hundreds of times. It tells them nothing. Replace it with the specific steps: which repository, that it issues DOIs, which metadata standard applies in your field, what the license will be, and what documentation you'll include. That paragraph is concrete, it's checkable, and it answers the question the reviewer was actually asking. The DMP guide and the DMP checklist walk through the rest of the plan.
If you support researchers
A short FAIR session works well as a follow-on to a data citation or DMP workshop, because it gives researchers a reason for the steps they've already been told to take. If your campus is building that kind of support, the guide to starting research data services is a good place to begin. I also help institutions set this up; get in touch if that would help.
Common questions
Does FAIR mean my data have to be open? No. FAIR asks that people and machines can find the data and learn how to get access. Data about people can sit behind an application or a data use agreement and still be FAIR, as long as the metadata are public and the access route is clear.
Who wrote the FAIR principles? A group of researchers, funders, publishers, and repository staff, published by Wilkinson and colleagues in Scientific Data in 2016. GO FAIR now hosts the principles as a living reference.
Is there a FAIR certification? Not for individual datasets. There are self-assessment tools and automated checkers, and repositories can hold trust certifications such as CoreTrustSeal, but FAIR is a set of goals, not a pass-or-fail standard.
What's the fastest way to make a dataset more FAIR? Deposit it in a repository that issues DOIs, fill in the metadata fields properly, pick a license, and include a README and codebook in open file formats. That covers most of the fifteen principles.