13. Open Questions and Future Iterations¶

This section documents the current boundaries of the Blueprint. Section 13.1 sets out design questions that remain unresolved in this version, for consideration as the specification develops and section 13.2 identifies considerations deferred to future iterations.

13.1 Unresolved Design Questions¶

Table 10 presents design questions identified during the Blueprint programme that remain unresolved in this version, for consideration as the specification develops.

Table 10. Open questions raised during the development of this Blueprint that remain unresolved in this iteration and require further community discussion, governance decisions, or design work before they can be closed.

Theme	Question	Notes
FAIR evaluation	Should the Data Director support evaluation of already-published digital objects (e.g. via FAIRassist), in addition to metadata produced during the publication workflow?	The community has indicated this would be valuable. Open questions remain about how the tool connects to external evaluation services post-publication, how results are surfaced, and how findings are recorded in the provenance chain.
FAIR evaluation	Should FAIR be assessed at the FIP level rather than FDO level, and separately at repository, dataset, and file levels, given the current architecture conflates these?	Structural issue affecting the uses table (Section 4.1) and reference architecture (Section 9).
Openness and sovereignty	Should P2 (Open First) be reframed as “as open as possible, as sovereign, protected, and accountable as necessary,” conditioned on human rights, consent, and community authority?	Raised as critical for international projects and genuine inclusivity, to avoid widening the digital divide. Needs resolving before national-level deployment.
Openness and sovereignty	Should computation be brought to the data, rather than data moved to computation, where residency requirements prevent central processing?	A recognised pattern in sensitive data environments, but the practical means of achieving it depends on institutional infrastructure and is not specified. Implementers under strict sovereignty or residency constraints should treat this as requiring institutional design.
AI safety, resilience and evaluation governance	How should the safety, transparency and resilience of the Data Director be assessed, reported and governed over time, including where humans remain in the loop, what outputs must always be reviewed, and how escalation and suspension should work?	C13 and C14 set requirements for responsible AI behaviour, but how the tool is audited against emerging governance frameworks, monitored in production, and trusted as capabilities evolve remains open. Identified as the key community governance question; decisions are expected to need review as agent competence grows, with the appropriate level of oversight likely determined by the funder or institution based on resourcing and workload.
Interoperability	How should system-level research data exchange and reuse across institutional boundaries be supported, beyond metadata format alignment (R6)?	Encompasses authentication, authorisation, data transfer protocols, and institutional data governance agreements. Designing a system-level framework is beyond this Blueprint's scope; a question for future iterations and related infrastructure initiatives.
Agent memory and model improvement	Should researcher query data be used to improve the underlying AI model over time?	Involves a balance between privacy and quality improvement; the answer will vary by institution, jurisdiction, and governance framework. Whatever decision is made must be documented, communicated to users, and reviewed periodically.
Scope and data types	Is the Data Director workflow adaptable to dynamic data; continuously produced, high-volume outputs such as environmental sensor streams or geophysical feeds, or does it require adjustment for research infrastructure contexts where data is not static?	The Blueprint is designed primarily with static datasets in mind. Whether the workflow applies as-is or requires adaptation for dynamic data production environments is an open question for future community consideration.

13.2 Roadmap for Future Iterations¶

This section sets out items deferred from v1.0, representing areas of strong community interest that are either technically premature, outside the current scope, or dependent on decisions not yet made.

Evaluation and quality

Permit a first-pass review by another AI agent before human review, to manage scale, with the ability for a human reviewer to revert to a prior agent version if unsatisfied.
Include measurement of hallucination levels in AI-generated metadata as part of quality evaluation under C15, dependent on the state of the art for hallucination detection. Cross-source and internal consistency checking may offer an early, tractable step toward this measurement challenge, ahead of fuller benchmark development.

Scope and lifecycle

Engage researchers at the point of data collection and project planning, not only at publication; automating engagement at the point of award was suggested as a way to address this.

Workflow and architecture

Add pipeline extensibility as a named architectural principle, enabling optional stages such as anonymisation, format conversion, and compliance checking.
Make access procedures interoperable between Data Director instances (per C5), with technical mechanisms to harmonise across a federation of agents, while recognising that access policies (authorisation rules) cannot be identical across organisations.
Extend R12 (Discover related datasets) to include detection of potential duplicate datasets, particularly relevant in large consortia where the same dataset may be deposited more than once by different teams.
Consider whether the linking of datasets to related research outputs via R11 could be extended to surface technology transfer pathways; routes through which research outputs may have commercial, industrial or societal application beyond the original research context, noting that identifying such pathways should remain a conclusion the researcher draws from seeing related outputs, rather than an explicit suggestion made by the tool.

Sovereignty and data residency

Clarify how data sovereignty should be enforced in practice when AI processing, logs, temporary files, and backups may involve external services or cross-border infrastructure, with national research agencies involved in RDA potentially solicited for input.

Accessibility and language

Support multilingual metadata records (C6) and define how the tool should handle datasets containing multiple languages. One view is to leave this as a configurable, agentic capability rather than a default requirement, important for inclusivity. Open questions include the effect on performance, minimum language coverage, and whether outputs should default to an English-language version alongside others.

Naming and terminology

Review whether the name ‘Data Director’ risks implying the tool directs, authorises, or takes responsibility for decisions. Possible alternatives considered include Research Data Assistant, Data Concierge, Data Curator, and Data Curator Agentic AI, with a suggestion that adding ‘agent’ to the name could help convey its role without further explanation.
Consider replacing the term ‘publication’ throughout with a less ambiguous term such as ‘research output’ or ‘digital research object’, affecting precision throughout the document.