FAIR in Scientific Projects
FAIR implementation is a project-wide process for making research data and related digital outputs findable, accessible, interoperable and reusable by both people and machines.
Effective FAIR practice begins when a project defines its research outputs, responsibilities, metadata, formats, identifiers, repositories and access conditions. It continues throughout data creation, processing, analysis, publication and preservation.
This page provides a practical framework for integrating FAIR activities into scientific work packages, research workflows, deliverables and quality-control procedures.
Page information
Topic: FAIR implementation in scientific projects
Coverage: Project planning, research-object inventories, metadata, identifiers, repositories, provenance, software, workflows, FAIR assessment and quality assurance
Primary audience: Researchers, project coordinators, work-package leaders, data stewards, data curators, repository managers and research software specialists
Applicable to: Experimental, observational, computational, simulation, survey and data-integration projects
Last reviewed: August 2026
FAIR by design
FAIR by design means that decisions affecting future discovery, interpretation and reuse are made while the project and its workflows are being designed, not after the research outputs have already been created.
Plan early
Identify expected outputs, responsibilities, standards, repositories and access conditions before data production begins.
Document continuously
Capture metadata, parameters, versions, provenance and decisions during the research process.
Use shared standards
Select community formats, metadata schemas, identifiers and vocabularies wherever suitable standards exist.
Review before release
Assess completeness, consistency, rights, documentation and repository readiness before publication.
What FAIR applies to
A scientific project usually produces a connected set of digital research objects rather than one final dataset. FAIR planning should therefore cover the objects needed to understand, validate and reuse the research.
Research data
Raw, processed, analysed, simulated, aggregated and reference datasets.
Research software
Source code, scripts, libraries, applications and executable environments.
Models and workflows
Trained models, configurations, computational workflows, notebooks and processing pipelines.
Supporting objects
Protocols, documentation, metadata, provenance, instruments, samples and quality reports.
Build a research-object inventory
The project should maintain a structured inventory of the digital objects it expects to create, reuse, transform or publish.
| Inventory field | Information to record |
|---|---|
| Object identifier | Internal project identifier or stable working name |
| Object type | Dataset, software, model, workflow, protocol, sample or other type |
| Scientific purpose | The research question, activity or deliverable supported |
| Responsible partner | Organisation and person responsible for the object |
| Source | Generated in the project, reused from elsewhere or derived |
| Format and volume | File formats, estimated size and expected growth |
| Access status | Open, embargoed, restricted, controlled or internal |
| Publication target | Intended repository, registry or archive |
| Related objects | Inputs, outputs, software, publications and workflows to be linked |
| FAIR status | Planned, in preparation, reviewed, deposited or published |
FAIR across the project lifecycle
1. Project design
Identify outputs, standards, responsibilities, risks, repositories and required resources.
2. Data production
Apply naming, formats, metadata, versioning, storage and quality procedures.
3. Processing and analysis
Record transformations, software, parameters, environments and provenance.
4. Publication and preservation
Prepare FAIR packages, deposit stable versions and maintain identifiers and metadata.
Operational interpretation of FAIR
| FAIR dimension | Project-level implementation |
|---|---|
| Findable | Persistent identifiers, rich metadata, catalogue registration and links between related objects |
| Accessible | Trusted repositories, standard retrieval protocols, explicit access conditions and persistent metadata |
| Interoperable | Community formats, metadata schemas, controlled vocabularies, ontologies and qualified relationships |
| Reusable | Licences, provenance, quality information, documentation and domain-relevant standards |
Findability in practice
Assign a persistent identifier: use a DOI or another recognised PID for stable published objects.
Create rich metadata: describe the content, context, methods, creators, funding, rights and related objects.
Include the identifier in the metadata: the metadata record must identify the object it describes.
Register the object: deposit it in a repository or registry that supports search and harvesting.
Identify versions: distinguish concept-level records, releases and revised datasets.
Accessibility in practice
Repository access
Deposit stable research objects in a repository with documented governance and preservation arrangements.
Standard protocols
Use open and implementable web, harvesting or data-access protocols.
Explicit conditions
State whether access is open, embargoed, authenticated, controlled or unavailable.
Persistent metadata
Keep the metadata record accessible even when the data are withdrawn or access is restricted.
Interoperability in practice
Open formats
Prefer documented and broadly supported formats over undocumented proprietary structures.
Metadata schemas
Apply general and domain-specific profiles appropriate to the object and repository.
Controlled vocabularies
Use persistent terms for resource types, roles, units, methods and scientific concepts.
Typed relationships
State how data, software, workflows, publications, instruments and versions are related.
Reusability in practice
Licence: state what users may copy, modify, redistribute or incorporate into new work.
Provenance: document how the object was created, transformed and validated.
Scientific context: explain the methods, instruments, assumptions, parameters and limitations.
Quality information: report validation procedures, uncertainty, missing values and known limitations.
Community standards: follow established disciplinary practices where they exist.
Dependencies: identify software, data, models and environments required for reuse.
Minimum project metadata
| Metadata group | Information to include |
|---|---|
| Identification | Title, persistent identifier, version and resource type |
| Responsibility | Creators, contributors, roles, affiliations and responsible organisation |
| Scientific description | Purpose, methods, scope, variables, materials and research context |
| Technical description | Formats, software, environment, size and system requirements |
| Rights and access | Licence, access status, embargo and access procedure |
| Funding | Project, grant, funder and institutional information |
| Provenance | Sources, transformations, processing steps and responsible agents |
| Relationships | Inputs, outputs, publications, software, versions and related research objects |
| Quality and limitations | Validation, uncertainty, completeness and known constraints |
Persistent identifiers
Research objects
Use DOI or another recognised identifier for stable datasets, software releases and related outputs.
Researchers
Use ORCID to distinguish contributors and connect outputs with their creators.
Organisations
Use ROR or another recognised organisational identifier where available.
Projects and instruments
Use appropriate project, grant, facility, instrument or sample identifiers where supported.
Provenance
Provenance records explain where a digital object came from, which activities changed it and which people, organisations or software agents were responsible.
Entities
Data files, models, samples, parameters, software and generated results.
Activities
Collection, simulation, processing, training, analysis, validation and conversion steps.
Agents
Researchers, institutions, instruments, services and software systems responsible for activities.
Relationships
Used, generated by, derived from, attributed to and associated with.
Research software and computational workflows
Archive stable releases: preserve the exact software version used to obtain reported results.
Record dependencies: document libraries, compilers, containers, operating systems and hardware requirements.
Provide installation and execution instructions: explain how the software or workflow can be run.
Add a software licence: distinguish software licensing from dataset and publication licensing.
Describe inputs and outputs: identify accepted formats, parameters and generated objects.
Link code and data: connect the software release with datasets, publications, models and workflow records.
Preserve the execution configuration: include configuration files, random seeds and environment definitions.
FAIR research packages
Related project files should be organised as a coherent package rather than uploaded as an unexplained collection of folders and files.
| Package component | Purpose |
|---|---|
| README | Explains the scientific purpose, contents and recommended use |
| File manifest | Lists files, checksums, formats, roles and relationships |
| Metadata record | Provides structured descriptive and administrative information |
| Provenance record | Describes sources, activities, agents and transformations |
| Workflow description | Documents the sequence of processing and analysis activities |
| Software environment | Records dependencies, containers or environment specifications |
| Licence and access statement | Defines lawful reuse and any restrictions |
| Quality or evaluation report | Records validation, metrics, limitations and uncertainty |
Selecting a repository
Domain suitability
The repository accepts the relevant object type and supports disciplinary standards.
Persistent identification
Stable published objects receive a recognised persistent identifier.
Metadata and interoperability
Records are structured, exportable, harvestable and visible through external catalogues.
Preservation and support
Governance, preservation, versioning, access and support procedures are documented.
Project roles and responsibilities
| Role | FAIR responsibility |
|---|---|
| Project Coordinator | Ensures that FAIR actions are included in governance, planning and reporting |
| Work Package Leader | Identifies outputs and ensures implementation within the work package |
| Researcher or Object Owner | Creates accurate data, documentation, metadata and provenance |
| Data Steward | Coordinates data-management decisions, standards and FAIR planning |
| Data Curator | Reviews and prepares data packages, metadata and repository deposits |
| Research Software Specialist | Supports software quality, versioning, dependencies and executable environments |
| Repository Specialist | Advises on deposit, metadata, identifiers, access and preservation |
| Legal or Ethics Specialist | Reviews licences, personal data, consent, confidentiality and intellectual property |
Integrating FAIR into work packages
Tasks
Include metadata, documentation, repository selection, curation and assessment as explicit activities.
Deliverables
Define inventories, DMPs, metadata profiles, FAIR packages and publication records as project outputs.
Milestones
Review readiness before large-scale production, publication and final reporting.
Resources
Allocate staff time, repository fees, storage, software and curation support.
Recommended FAIR deliverables
Research-object inventory
Data Management Plan and scheduled updates
Metadata and identifier plan
Format, vocabulary and ontology selection
Repository and preservation plan
Access, licensing and restriction register
Provenance and workflow documentation
Software and model publication plan
FAIR package templates
FAIR assessment and quality-review reports
Final registry of published outputs and persistent identifiers
FAIR assessment
FAIR assessment should be used to identify missing actions and improve an object before or after publication. A numerical score should not be treated as an absolute certification of scientific quality.
Self-assessment
Researchers and data stewards review planned practices before repository deposit.
Curatorial review
A curator checks documentation, metadata, relationships, licences and package completeness.
Automated assessment
Software evaluates machine-detectable properties exposed through the repository record.
Improvement plan
Findings are translated into assigned actions, priorities and deadlines.
FAIR assessment tools
| Tool or framework | Use in a project |
|---|---|
| FAIR-Aware | Builds researcher awareness before data are deposited |
| F-UJI | Performs automated dataset-level assessment using a persistent identifier |
| RDA FAIR Data Maturity Model | Provides common indicators and assessment priorities |
| FAIR Implementation Profile | Records the implementation choices adopted by a project or community |
| FAIR Implementation Framework | Supports organisational assessment and development of an action plan |
| Repository-specific validation | Checks mandatory metadata, files and deposit requirements |
FAIR and data quality
| Assessment area | Main question |
|---|---|
| FAIRness | Can the object be found, accessed, interpreted and reused? |
| Scientific quality | Are the methods, observations and conclusions scientifically valid? |
| Technical quality | Are files complete, valid, readable and internally consistent? |
| Documentation quality | Can another user understand the object and its limitations? |
| Legal and ethical compliance | Is access and reuse permitted and appropriately documented? |
| Reproducibility | Are the inputs, software, workflows and parameters sufficient to verify the result? |
FAIR implementation risks
| Risk | Mitigation |
|---|---|
| Outputs are identified too late | Create and update the research-object inventory from project start |
| Metadata are added only before deposit | Capture metadata automatically or routinely during research |
| No responsible owner is assigned | Assign an accountable partner and contact for every major object |
| Repository does not support the object | Select and test repositories before large-scale data production |
| Restrictions are undocumented | Maintain an access, rights and restrictions register |
| Software environment cannot be reconstructed | Archive versions, dependencies, containers and configuration files |
| FAIR responsibilities are under-resourced | Allocate staff time, curation support and infrastructure costs |
| Assessment is performed after project closure | Schedule reviews before publication and final reporting |
Common misconceptions
“FAIR means open.” FAIR requires explicit and workable access conditions but permits justified restrictions.
“A DOI makes a dataset FAIR.” A persistent identifier supports findability but does not provide documentation, interoperability or reuse conditions.
“Uploading files completes FAIRification.” Files require structured metadata, context, provenance, rights and relationships.
“FAIR is only the repository’s responsibility.” Many essential decisions must be made by researchers while creating and processing the data.
“One metadata schema is sufficient for every project.” General repository metadata usually need to be complemented by discipline-specific descriptions.
“A high FAIR score proves scientific quality.” FAIR assessment does not validate the scientific conclusions.
“Only final data need to be documented.” Intermediate objects, software and workflows may be essential for validating or reusing the result.
“FAIR can be added at the end without extra resources.” Sustainable implementation requires planning, staff time, infrastructure and curation.
FAIR project readiness checklist
Expected digital research objects have been identified.
An accountable owner has been assigned to each major object.
FAIR tasks are included in work packages and deliverables.
Metadata requirements have been defined before data production.
Appropriate formats and controlled vocabularies have been selected.
Persistent identifiers and versioning rules are planned.
Suitable repositories have been identified and tested.
Access conditions, licences and restrictions are documented.
Provenance will be captured during processing and analysis.
Software, models and workflows are included in FAIR planning.
README, manifests and package structures are defined.
Quality review and FAIR assessment points are scheduled.
Curation, storage and repository resources are budgeted.
Published outputs will be linked through typed relationships.
Final metadata and identifiers will be preserved after project closure.
How to use this page
For proposal teams
Use the lifecycle, roles and deliverables sections to define a realistic FAIR work plan.
For researchers
Use the metadata, provenance and packaging sections during daily research work.
For data stewards
Use the inventory, assessment and risk sections to coordinate support across work packages.
For project coordinators
Use the checklist and deliverables to monitor implementation and reporting.
Explanatory status
This page provides a general implementation framework for applying FAIR practices in scientific projects.
It does not replace the requirements of a specific funder, discipline, repository, ethics body, data-protection authority or research infrastructure.
The appropriate level of FAIR implementation depends on the type of research object, scientific community, legitimate access restrictions, available standards and intended reuse.
Automated FAIR assessments evaluate only properties that can be detected from the digital object and its metadata. They should be complemented by scientific, curatorial, technical, legal and ethical review.