Skip to content

7. Functional Specification

This section defines what the Data Director must do and how it must behave. It is structured in two parts.

Section 7.1 sets out the functional requirements: the specific capabilities the Data Director must provide, ordered to follow the workflow sequence established in the uses table in Section 4.1. Each requirement is assigned a priority level and mapped to known existing tools and resources in the Existing Solutions column. The Existing Solutions column is informational, not prescriptive. It identifies tools and resources the community has confirmed are relevant or compatible, to support implementers in meeting each requirement. It is not a complete list and does not constitute an endorsement of any specific product or platform; it reflects the state of community knowledge at the time of writing. Entries where no confirmed existing solution has been identified are marked accordingly; where a known tool is in active development or awaiting community evaluation, this is noted against the relevant entry.

Section 7.2 sets out the non-functional requirements: the quality standards and constraints the Data Director must meet across all its capabilities, regardless of which functional requirements are implemented.

7.1 Functional Requirements

The following requirements describe the specific capabilities and behaviours the Data Director must provide (Table 3). They are ordered broadly to follow the workflow sequence established in the uses table in Section 4.1, though some requirements span multiple workflow phases.

The key words MUST, SHOULD, and MAY in this document are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174)1 when, and only when, they appear in capitals as shown here. Each is qualified using one of three terms:

  • MUST: mandatory; no compliant implementation without this.

  • SHOULD: strongly recommended; departure requires documented justification.

  • MAY: optional but explicitly permitted.

Where a requirement is marked SHOULD, implementing organisations operating in contexts with more demanding compliance or audit requirements should consider whether that requirement should be treated as MUST in their deployment. This applies in particular to R1 and R8, as noted in the relevant rows.

Table 3. Functional requirements for the Data Director, showing each capability, its description, its priority, and known existing solutions or resources.

ID Requirement
The specific capability or behaviour		 Description
What the requirement means in practice		 Priority
MUST / SHOULD / MAY		 Existing Solutions
Relevant or compatible known tools and resources
R1 Recommend and select repositories meeting funder, journal, institutional and community requirements Identify suitable repositories and flag conflicts between funder, journal and institutional requirements. Repository selection should be initiated before metadata generation, since the selected repository determines the required metadata schema, controlled vocabularies, and validation rules. Recommendations must distinguish commercial from open repositories, surface deposit fees, and support affiliation-based suggestions. SHOULD
Where repository recommendation is a mandatory service requirement, implementers should treat this as MUST.
Note: implementing organisations must assess whether C3 Compliance (a non-functional requirement set out in Section 7.2, Table 4) requires treating R1 as MUST.		 FAIRsharing.2 A curated registry of community-defined standards, databases and policies across disciplines; includes repository records and supports filtering by subject and data type. A FAIRsharing MCP server3 is available for direct integration with the Data Director.
re3data.4 A registry of research data repositories with filtering by subject, access type and deposit conditions.
Cornell Data Storage Finder.5 An open-source tool for localised repository and storage recommendations; may serve as a reference implementation for R1.
R2 Generate FAIR-aligned and discipline-appropriate metadata using controlled vocabularies, ontologies and community standards including CARE principles Generate a draft FAIR-aligned metadata record, drawing on discipline-specific vocabularies and ontologies where available. Produce metadata meeting named community standards including domain-specific fields and CARE considerations where applicable. Researcher reviews before submission. Where no controlled vocabulary exists for a domain, the tool must explicitly state this; it should additionally suggest candidate terms drawn from related datasets or adjacent community terminology, clearly flagged as informal or unvalidated. MUST Ontology Lookup Service (OLS).6 An ontology repository providing controlled vocabularies across disciplines.
NFDI Terminology Service.7 A terminology service providing controlled vocabularies for research communities.
OntoPortal instances. Including BioPortal8 and AgroPortal);9 domain-specific ontology repositories.
Global Indigenous Data Alliance (GIDA).10 Community standards with explicit CARE guidance for Indigenous data.
RDA kernel metadata recommendations.11 Define essential domain-agnostic metadata fields.
FAIR2 metadata specification.12 A community-driven metadata specification built on MLCommons Croissant, relevant to this requirement.
R3 Suggest appropriate vocabularies, ontologies and open data formats Recommend suitable controlled vocabularies, ontologies and file formats, including field-level formats such as date/time standards, for a given dataset to improve consistency, interoperability and discoverability. Must support emerging standards and new mappings. Must distinguish between ontology alignment and controlled vocabulary concept linkage. MUST FAIRsharing. Covers terminologies, formats, identifier schemas and reporting guidelines across disciplines; see R1 for MCP integration note.
R4 Validate metadata quality and produce standardised records assessed against community best practices, recommendations and standards Check metadata completeness and correctness against defined schemas. The tool should connect to repository-provided validation tools where available, and to community validation tools where repository-specific tools do not exist. It does not replicate full FAIRness evaluation. Metadata validation outputs must be traceable through the provenance chain (see R10). MUST RO-Crate validator,13 Frictionless Data,14 JSON Schema,15 XSD,16 SHACL,17 Croissant Validator.18 Schema validation tools applicable to this requirement.
CEDAR Workbench,19 OntoPortal/BioPortal,20 Skosmos,21 OLS, FOOPS!.22 Ontology and vocabulary validation tools.
fairassist.org.23 A full list of community FAIR assessment tools, including those with OSTrails framework integration.
MOMSI FAIRsharing collection.24 Cross-domain benchmarking reference covering domain-specific and universal standards, confirmed useful for evaluating R3 and R4: fairsharing.org
FAIRshake,25 F-UJI.26 Metadata quality evaluation tools for assessing AI-generated record quality against curation standards; relevant to C15.
R5 Draft data documentation including READMEs and data dictionaries at publication Generate a draft of supporting documentation so that others can understand and reuse the data at the point of data publication. The tool can automatically draft elements it can infer from available data and metadata, including file structure, field names, and basic descriptions. Elements that cannot be inferred and require direct researcher input include variable definitions, units, missing value codes, study design details, and data collection procedures. A human-reviewed and approved version must be produced before submission. MUST No confirmed existing solution identified at v1.0. Known solutions to be identified through community input.
R6 Enable interoperable metadata across institutions and Data Director instances Reuse existing metadata formats and schemas to reduce data wrangling and enable consistent interpretation across systems and institutions. The tool must support mapping of metadata across multiple schemas so that the same dataset can be described in more than one standard, enabling deposit across different repositories without manual remapping by the researcher. Researchers must be able to view original metadata alongside mapped versions and crosswalks. Synchronisation between Data Director instances must be supported where multiple institutions collaborate. MUST FAIR Digital Object (FDO) framework.27 Supports interoperability through typed, validated objects; multiple profiles enable metadata at domain-agnostic, domain-specific and application-specific levels simultaneously.
Cross-Domain Interoperability Framework (CDIF).28 Supports cross-domain metadata mapping.
R7 Support assignment of persistent identifiers (PIDs) at point of publication The Data Director generates PID-ready metadata and informs users of repository PID capabilities. It does not interact directly with PID registration systems; PID assignment remains the responsibility of the repository. Users must be informed whether the selected repository assigns PIDs, including whether DOIs are minted automatically. Any costs associated with PID assignment must be surfaced to the user and must not be absorbed silently into the application; institutional configuration must determine how such costs are handled. MUST DataCite.29 Provides the primary membership model for institutional DOI minting for deposited datasets; the Data Director should surface whether a selected repository holds DataCite membership.
FAIRsharing identifier schema catalogue.30 Maintains curated records describing identifier schemas and their persistence, resolvability, and global uniqueness characteristics, enabling repositories and applications to assess the suitability of identifier systems against EOSC PID criteria.31 Records are linked to the repositories that implement each schema.
R8 Verify data sharing at publication against Data Management Plan (DMP) commitments At the point of data publication, the Data Director should verify that data sharing aligns with the associated DMP where one exists. Discrepancies must be flagged for human review, not automatically enforced. Where the human review of a discrepancy concludes that data should not be shared, in whole or in part, consistent with the DMP's commitments, this determination is a valid terminal outcome of the verification step, not an exception, a failure, or an incomplete workflow. The system must function without a DMP where one is not available. Embargo status must be confirmed by the responsible human before any sharing workflow proceeds, consistent with Section 5.2. SHOULD
Where DMP compliance is an audit requirement, implementers should treat this as MUST.		 Data Stewardship Wizard (DSW).32 Exposes DMP commitments in a computationally amenable form; confirmed compatible with the Data Director.
Argos.33 DMP tool with machine-readable output; confirmed compatible.
DAMAP.34 DMP tool with machine-readable output; confirmed compatible.
RDA maDMP Working Group.35 For a complete list of compatible tools, contact the RDA Common Application Programming Interface (API) for Machine Actionable Data Management Plans Working Group.
R9 Retrofit FAIR-aligned metadata for already-published datasets and supplementary materials Generate metadata improvement recommendations for previously published, preliminary, or unpublished datasets to support more discoverable, citable, and reusable outputs. All recommendations are advisory and subject to human review and action before any changes are made. Automated repository updates are not within scope; the researcher or Data Support Professional is responsible for submitting approved recommendations to the relevant repository. Where a dataset lacks a persistent identifier, users should be directed to R7. SHOULD FAIR Digital Object (FDO) framework. Enables retrofitting by managing metadata independently of repositories, allowing harmonised metadata across multiple repositories without repository operator involvement.
COMET initiative.36 Supports community-curated enrichment of PID metadata for existing outputs, directly aligned with the retrospective scope of this requirement.
R10 Track provenance of AI agent actions on data and metadata Record all actions taken by AI agents on data and metadata so that they can be verified, validated and audited. MUST PROV-O.37 Identified as a candidate standard for provenance recording, with archiving option. See also Section 5.4.
eScience 2025 provenance paper.38 Community reference for PROV-O implementation in agentic AI research workflows.
yProv.39 Provenance tracking service and includes yProv4ML.
R11 Link datasets to related research outputs including journal article publications, people, grants and software The Data Director generates metadata that enables persistent links to be established between datasets and related research outputs including journal article publications, grants, software, and people. Linking metadata is produced for researcher review; registration of relationships through PID and repository workflows remains the responsibility of the researcher and the relevant repository. Linking to ORCID and ROR should be supported as part of metadata creation. SHOULD ORCID.40 Persistent identifier for researchers; identified as a relevant linking target.
ROR (Research Organisation Registry).41 Persistent identifier for research organisations; identified as a relevant linking target.
R12 Discover related datasets relevant to a research project Surface relevant existing datasets quickly without relying on general-purpose search engines. Discovery must be optional and must not trigger any changes to existing metadata records. MAY DataCite MCP. In active development at the time of writing; monitor for availability. Identified as a relevant resource for dataset discovery.

7.2 Non-functional Requirements

Non-functional requirements describe how well the system must perform: the quality standards and constraints it must meet across all capabilities, such as how fast, secure, available, and accessible it must be (Table 4).

Table 4. Non-functional requirements for the Data Director, showing each quality standard or constraint, its category, its requirement, and the rationale for its inclusion.

ID Category Requirement
What the system must do or achieve		 Rationale
Why this standard or constraint is necessary
C1 Security Data in transit and at rest must be encrypted at the infrastructure layer, with restricted access as default. Encryption operates at the infrastructure layer and does not restrict access to open data. Access to metadata, datasets and agent actions must be role-based, token-verified and auditable. A recognised framework such as NIST should be adopted as the compliance baseline. The Data Director handles sensitive research data across multiple institutions. Funders, journals and institutions require demonstrable protection against unauthorised access, and audit trails are essential where AI agents act on data. The scope of the security audit trail is infrastructure and access control; AI agent action audit trails are addressed in C13.
Australian Cyber Security Centre.42 Guidance on careful adoption of agentic AI services, directly relevant to agentic AI security baseline requirements
C2 Privacy The Data Director must apply data minimisation principles to all metadata outputs, ensuring that personally identifiable or sensitive information is not exposed in metadata records or documentation. The tool must prompt users to confirm that applicable ethics approvals are in place before any deposit workflow proceeds. Where potential identifiers are flagged or detected in data or metadata, the tool must pause the sharing workflow, alert the human reviewer, and provide guidance on appropriate next steps; it must not attempt anonymisation or deidentification autonomously. Active detection of personal identifiers within datasets is identified as a future capability in Section 4.1; in this iteration the tool's contribution is to ensure that governance steps around personal data are not bypassed. More advanced detection of indirect or contextual identifiers remains a Future Consideration. The Data Director’s role is to detect and flag privacy risks, not to resolve them. Anonymisation or deidentification and ethics compliance are institutional responsibilities that require human judgement and context-appropriate tooling; the tool’s contribution is to ensure these steps are not bypassed.
C3 Compliance The Data Director must support compliance with funder open data requirements, applicable data protection legislation, institutional data policies, journal data policies and relevant disciplinary community standards. Evidence of compliance must be available on demand across all applicable obligations. Funder mandates, journal policies and institutional requirements increasingly require open, FAIR-aligned data as a condition of grant award or publication. The Data Director must enable researchers and institutions to demonstrate compliance across all applicable obligations without significant manual effort.
C4 Sovereignty Data and metadata must be stored and processed in jurisdictions compliant with institutional and national sovereignty requirements. Cross-border data transfer must be policy-controlled and auditable. Physical storage location must be constrainable. Location-based access controls must be supported. Institutions operating under national and regional data regulations require assurance that research data does not move outside permitted jurisdictions without appropriate controls, especially for sensitive, embargoed, commercially restricted or Indigenous datasets where sovereignty obligations may be legally or ethically binding.
C5 Interoperability The system must support established metadata standards, expose open APIs and enable metadata exchange with major repositories and institutional systems without bespoke integration. All Data Director instances must expose a harmonised API for core features to enable inter-Director interactions. The Data Director’s value depends on working across heterogeneous repository and institutional environments globally. Proprietary formats or closed interfaces would undermine FAIR alignment and limit adoption across systems, regions and institutions worldwide.
C6 Accessibility The Data Director must meet recognised international accessibility standards across all user interfaces, including WCAG 2.1 as a minimum baseline. Documentation and guidance must be available in accessible formats and comply with applicable national accessibility legislation. The Data Director will be used by a diverse global research community. Accessibility compliance is a legal requirement in many jurisdictions and reflects a commitment to inclusive research practice.
C7 Reliability The Data Director must achieve a minimum of 99.5% uptime during agreed service hours for service-based deployments. Implementing organisations deploying the Data Director as a local or on-demand tool should calibrate reliability targets to their deployment context and document any departure from this target with justification, consistent with Section 5.5. All metadata submission and deposit workflows must complete successfully or fail gracefully with a clear error state, providing justification and suggested next steps. Researchers rely on the Data Director at critical points in the publication workflow. Unplanned downtime or silent failures at point of submission could delay publication and compromise funder compliance. Reliability and availability are related but distinct: C7 addresses successful completion of workflows and uptime targets; C9 addresses the hours and time zones across which the system must be accessible.
C8 Resiliency The Data Director must recover automatically from component failures without data loss. All AI agent actions on metadata must be reversible, with rollback to the last verified metadata state supported. Any failure mid-process must not result in corrupt or partial metadata records that compromise data integrity. Where an action has been explicitly confirmed as irreversible by an authorised human under C13, recoverability to a prior state may not apply; this must be logged and disclosed to the user at the point of confirmation. Metadata creation and transformation workflows involve multi-step agentic AI processes where partial completion is potentially more harmful than complete failure. Corrupt or incomplete metadata records could propagate errors across repositories and undermine researcher trust in AI-generated outputs.
C9 Availability The system must be available 24/7 to support researchers across time zones and at submission deadlines. Planned maintenance windows must be communicated in advance and minimised. Research publication and data deposit activity is not confined to working hours. Grant deadlines and journal publication schedules require the Data Director to be accessible at any time. 24/7 availability also enables international cooperation across institutions.
C10 Performance Metadata generation, validation and repository recommendation must provide visible progress feedback. Response times must be appropriate to operation complexity. Bulk operations must be processed asynchronously with user notification on completion. Researchers interact with the Data Director at critical points in the publication workflow. Performance must be predictable and transparent. Slow or unpredictable performance without feedback will reduce adoption and create bottlenecks at publication.
C11 Scalability The Data Director must support growing volumes of datasets, metadata records and concurrent users without performance degradation, and must scale horizontally to meet regional or national demand. Infrastructure must be defined and managed as code to ensure consistent, reproducible and auditable deployment across institutional contexts. Infrastructure as Code approaches support version control of deployment configurations, reduce configuration drift between instances, and enable sovereignty-compliant deployment through jurisdiction-specific configuration profiles. The Data Director is intended for adoption across multiple institutions and research communities. Usage will grow significantly as FAIR adoption increases and more repositories are onboarded. Individual Data Director instances will have capacity limits; implementations must be designed to support federation and growth across the wider ecosystem. Infrastructure as Code is particularly important in a multi-institution ecosystem where deployment consistency directly affects interoperability, reliability and data sovereignty compliance. The cost implications of horizontal scaling must be considered alongside C17 (Affordability).
C12 Data Governance The Data Director must enforce institutional data governance policies including retention schedules, access controls, provenance tracking and audit logging. Governance policies must be machine-readable and AI-ready, drawing on frameworks such as ODRL. Compliance with well-recognised international data governance standards must be evidenced. The Data Director operates across institutional boundaries. Each institution must apply and evidence its own governance policies while interoperating with shared community standards. A dedicated governance framework agreement between participating institutions may be required. The scope of the governance audit trail is institutional policy compliance; security audit trails are addressed in C1.
C13 AI Governance All AI agent actions must be logged, attributable to a defined agent identity and subject to human oversight. Irreversible actions including deletion and autocompletion must be blocked by default without explicit human confirmation. The Data Director must comply with recognised international AI governance frameworks and standards. See also Section 6, Principle P4, for the distinction between human-in-the-loop and human-on-the-loop oversight modes. The Data Director uses agentic AI to create, transform and validate metadata. Responsible AI use requires transparent, auditable and controllable agent behaviour in line with emerging national and international AI governance frameworks. Governance must be principle-driven across both data and AI dimensions. See also C14 (Explainability), which addresses human understanding and overrides rights for AI-generated outputs.
C14 Explainability The system must provide human-readable and understandable explanations for all AI-generated metadata, recommendations and decisions. Designated human-in-the-loop roles must be able to challenge and override AI outputs within a defined governance layer. A log of agentic AI reasoning steps and decision points must be maintained alongside metadata records for transparency and improvement. Researchers and data support professionals need to trust and verify AI-generated outputs before submission. Opaque recommendations reduce confidence and increase the risk of errors in published metadata. Override rights must be role-based and governed rather than open to all users. See also C13 (AI Governance), which addresses logging, attribution and oversight of AI agent actions.
C15 Data and Metadata Quality The Data Director must perform quality checks on its own metadata outputs and profile the quality of researcher-supplied input data. AI-generated metadata must meet the same curation standards as manually produced records. The system must evaluate curation readiness before submission. Low-quality or generic outputs must be flagged before submission with human review mandatory. Low-quality AI-generated content is increasing across the internet. Metadata is required to be highly curated and precise. Preventing the propagation of generic, inaccurate, or uncurated AI-generated metadata into repositories is a pressing concern. Quality profiling of both AI-generated and researcher-supplied data ensures the system adds value rather than propagating poor-quality inputs.
C16 Measurability The Data Director must collect usage data to measure the impact and usefulness of the tool, provide data for cost and benefit analysis, and track researcher uptake. Metrics must inform future development and enable institutions to justify involvement and subscription. The effectiveness and impact of the Data Director must be demonstrable to justify institutional investment and inform future iterations. Uptake of digital research infrastructure requires evidence of value added for researchers across participating institutions and communities. Usage data collection must be designed in compliance with C2 (Privacy) and C4 (Sovereignty).
C17 Affordability The Data Director must be modular and configurable to support different funding levels and institutional contexts. Agents must not duplicate work, reusing outputs already created or discovered to reduce AI processing costs. Configurable tiers must ensure the system remains accessible to institutions with limited resources and without dedicated data support professionals. The Data Director must not increase the digital divide. Institutions in lower-resource contexts, including those without human data support, must be able to access and sustain the tool. The balance between costs and advantages must be explicitly considered in architectural decisions. The scaling demands of C11 must be weighed against affordability to ensure infrastructure costs do not exclude lower-resource institutions.

  1. https://www.rfc-editor.org/info/bcp14 ↩

  2. https://fairsharing.org/ ↩

  3. https://mcp.fairsharing.org/ ↩

  4. https://www.re3data.org/ ↩

  5. https://finder.research.cornell.edu/ ↩

  6. https://www.ebi.ac.uk/ols/ ↩

  7. https://terminology.services.base4nfdi.de/provider ↩

  8. https://bioportal.bioontology.org/ ↩

  9. https://agroportal.lirmm.fr/) ↩

  10. https://www.gida-global.org/ ↩

  11. https://doi.org/10.15497/RDA00031 ↩

  12. fair2.ai/spec ↩

  13. https://rocrate-validator.readthedocs.io/en/stable/ ↩

  14. https://frictionlessdata.io/ ↩

  15. https://json-schema.org/ ↩

  16. https://hackolade.com/help/XSDXMLSchemaDefinition.html ↩

  17. https://www.w3.org/TR/shacl/ ↩

  18. https://huggingface.co/spaces/luisoala/croissant-checker ↩

  19. https://doi.org/10.1007/978-3-319-68204-4_10 ↩

  20. https://ontoportal.org/ ↩

  21. https://skosmos.org/ ↩

  22. https://catalogue.fair-impact.eu/resources/foops ↩

  23. https://fairassist.org/ ↩

  24. https://fairsharing.org/5742 ↩

  25. https://doi.org/10.1016/j.cels.2019.09.011 ↩

  26. https://www.f-uji.net/ ↩

  27. https://fairdo.org/ ↩

  28. https://worldfair-project.eu/cross-domain-interoperability-framework/ ↩

  29. https://datacite.org/ ↩

  30. https://fairsharing.org/search?fairsharingRegistry=Standard&recordType=identifier_schema&page=1 ↩

  31. https://fairsharing.gitbook.io/fairsharing/record-sections-and-fields/general-information/globally-unique-persistent-and-resolvable-identifier-schemas ↩

  32. https://ds-wizard.org/ ↩

  33. https://argos.openaire.eu/home ↩

  34. https://damap.org/ ↩

  35. https://www.rd-alliance.org/groups/common-application-programming-interface-api-for-machine-actionable-data-management-plans-madmps/activity/ ↩

  36. https://www.cometadata.org/ ↩

  37. https://www.w3.org/TR/prov-o/ ↩

  38. doi.org/10.1109/eScience65000.2025.00093 ↩

  39. https://github.com/HPCI-Lab/yProv ↩

  40. https://orcid.org/ ↩

  41. https://ror.org/ ↩

  42. cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services ↩