Skip to content

11. Implementation Guidance

This section sets out practical starting points for organisations implementing the Data Director, drawn from reflections contributed by working group participants for each of the three implementer types identified in Section 2.2: research institutions, national research infrastructures, and commercial or non-profit vendors.

Some practicalities apply across all three implementer profiles, for example, considerations around cost transparency, interoperability, and conformance, while others are specific to a particular profile's role, resourcing, and relationship to the Blueprint. Where a consideration is genuinely cross-cutting, this is noted; otherwise, each subsection addresses the practicalities specific to that profile.

11.1 Cross-cutting Practicalities

The following practicalities were raised by more than one implementer profile and apply regardless of which profile an organisation belongs to.

Practical starting points:

  • Find out what information about the tool's safety and security would be needed to satisfy a security team's assessment, including how data leakage is prevented.

  • Establish how costs, including AI processing or token costs, would be estimated and how these would be passed on or absorbed (relevant whether estimating institutional running costs, infrastructure-wide sustainability costs, or end-user costs as a vendor).

  • Understand how open standards and open-source commitments affect vendor lock-in and interoperability between implementations, instances, and institutions.

  • Identify what counts as a valid implementation of the Data Director, including which capabilities are core to the specification versus optional or provided by separate agents, and how conformance with the Blueprint would be assessed or demonstrated.

11.2 Research Institutions

A research institution, in the context of this Blueprint, refers to an individual organisation, such as a university, research institute, or similar body, that conducts research and supports its researchers in producing and sharing research data. Research institutions are a primary deployment context for the Data Director, typically through their library, research support, or IT services, and are responsible for configuring the tool to reflect their own policies, systems, and governance arrangements.

The practical starting points below reflect considerations specific to deploying the Data Director within a single institution's existing systems, governance structures, and support arrangements.

Practical starting points:

  • Identify which systems already deployed in the institution have known integration pathways with the Data Director and check against existing AI governance approval processes.

  • Decide who will train research staff and whether institutional staff will provide day-to-day support; estimate how long it will take staff to get up to speed.

  • Define a scoped minimum viable implementation, potentially as narrow as identifying relevant repositories and metadata standards or focusing first on open-access datasets before sensitive data.

  • For smaller institutions, a first implementation focused on repository recommendation and basic metadata guidance for open datasets may be more achievable than a full deployment, with scope expanded once value and practical requirements are clearer.

  • Plan how outputs feed back into institutional systems (e.g. CRIS, institutional repository) when a researcher deposits data in an external repository rather than the institution's own, so that a record is created locally pointing to where the data has been deposited.

  • Identify what onboarding documentation will be needed for IT staff, administrators, and early users (beta-users) before deployment, for example, prerequisites, setup steps, and getting-started guidance, similar in style to vendor documentation such as learn.microsoft.com.1

  • Clarify whether AI-assisted outputs can be claimed as research outputs or impact in national research assessment exercises (such as the UK's Research Excellence Framework (REF), Australia's Excellence in Research for Australia (ERA), or equivalent frameworks in other countries).

  • For libraries, plan integration with university IT, Office of Research Development, and tools, such as research data repositories.

11.3 National Research Infrastructures

A national research infrastructure, in the context of this Blueprint, refers to a body operating at national (or potentially regional or international) scale that provides shared research data services, systems, or platforms used across multiple institutions within a country or research community. National research infrastructures differ from individual research institutions in that their decisions about adopting and configuring the Data Director have implications for the many institutions and researchers who rely on their services, and they must additionally consider cross-institutional and cross-jurisdictional factors.

The practical starting points below reflect considerations specific to deploying the Data Director at this larger scale, including business case development, integration with existing national services, and the legal and policy implications of acting on behalf of multiple institutions and users.

Practical starting points:

  • Estimate what proportion of the national user base are candidate users, and identify existing infrastructure elements with known integration pathways, to build a business case.

  • Confirm developer availability (in-house or elsewhere in the organisation) and establish a free or low-cost development and testing environment.

  • Decide on the most important formats, vocabularies and schemas to support initially, rather than attempting broad coverage from the start.

  • Plan the transition from the reference architecture to specific workflows, supported by documentation and training for researchers.

  • Consider an SDK (Software Development Kit, a set of pre-built tools and code components that make it easier to build integrations with a system) or integration snippets as a minimum viable implementation.

  • Be aware of the shift from ‘user requests service’ to ‘Data Director requests service on behalf of user’ and its implications for service design and user policy.

11.4 Commercial or Non-profit Vendors

A commercial or non-profit vendor, in the context of this Blueprint, refers to an organisation that develops, packages, hosts, or provides support for an implementation of the Data Director on behalf of research institutions or national research infrastructures, whether as a paid product or service (commercial) or as part of a not-for-profit or community-supported offering (non-profit).

The practical starting points below reflect considerations specific to building and offering an implementation of the Data Director to others, including business model and licensing questions, conformance, and avoiding duplication of existing implementations.

Practical starting points:

  • Understand what business model could be built around the tool, whether it can be extended, and whether the licence constrains rights over your own IP.

  • Identify what ‘valid implementation’ means and how conformance will be assessed for sign-off.

  1. https://learn.microsoft.com./en-gb/ ↩