6. Architecture Principles¶
The following 14 principles govern all architectural decisions in this Blueprint and should be applied consistently across all layers and components (Table 2). They should be read alongside the Blueprint Considerations in Section 5, which set out the conditions that any implementation must satisfy before these principles can be meaningfully put into practice. The two are complementary: where the principles set direction and design intent, the considerations define the boundaries within which that direction must be pursued. Where principles pull in opposing directions, Section 5.3 sets out how to resolve them. Implementers may extend this list but should not remove or contradict these principles without community agreement.
Table 2. The 14 architecture principles governing all design decisions in this Blueprint, showing the governing rule, what each principle requires, and what it means for implementers in practice.
| ID | Principle Name of the governing rule |
Statement What the principle requires |
Implication What this means for implementers in practice |
|---|---|---|---|
| P1 | FAIR and CARE | All Data Director capabilities must actively support the Findability, Accessibility, Interoperability and Reusability of research data as a primary design objective. Where data relates to Indigenous or community-held knowledge, CARE principles (Collective Benefit, Authority to Control, Responsibility, Ethics) must be applied alongside FAIR. | All workflows, metadata schemas, PID assignment and repository recommendations must be designed and evaluated against FAIR criteria, with each FAIR dimension explicitly supported in implementation from the outset. While connection to community-recognised evaluation tools and RDA-approved benchmarks is a future capability, the architecture must be designed to support this connection when it becomes available. Where CARE principles apply, particularly in contexts involving Indigenous data or community-held knowledge, they must be treated as context-specific rather than universal. Their application requires direct engagement with the relevant Indigenous and community stakeholders and cannot be reduced to a checklist assessment. |
| P2 | Open First | Data and metadata should be openly available unless a justified reason to restrict exists, respecting the principle of open as possible, closed as necessary. Being FAIR-aligned or technically shareable does not make data lawful to share. Legal and regulatory compliance is a condition for all data processing, sharing, and reuse actions. | Default sharing must be open; restrictions must reference a legitimate legal basis (for example, health data, national security, or data protection law). Closed-by-default is not compliant. Where restricted, a non-sensitive metadata record must remain openly accessible. Legal compliance must be verified before any sharing action. Regulatory obligations must be institutionally configurable. Where P2 conflicts with P10 (Data Sovereignty) or applicable legal obligations, Section 5.3 applies. |
| P3 | Security by Design | Security must be built into every component of the Data Director from the outset, not added retrospectively. Sensitive data handling constraints must be embedded in the architecture. The secure path must always be the easiest path for the user; where security and ease of use conflict, security takes precedence. | Default configurations must enforce encryption, role-based access, and audit logging. Provenance and infrastructure access are restricted by default. Restricted data must not be produced or accessible without explicit human-enabled access controls. Opt-out of security controls is not permitted. User roles must be explicitly defined before access controls are specified. |
| P4 | Human in the Loop | AI agents may draft and suggest, but no consequential action may proceed without explicit human approval. The Data Director may assist and recommend but must not decide, authorise, or take responsibility for consequential decisions. Human-in-the-loop (requiring explicit approval before an action proceeds) and human-on-the-loop (ongoing monitoring with override capability) are distinct modes of oversight that must be differentiated and documented per workflow. | Human-review triggers must be defined for all consequential actions. Every irreversible action requires explicit human confirmation. Implementers must document whether human-in-the-loop or human-on-the-loop applies to each workflow. The tool must never operate as an autonomous authority over governance or responsibility. |
| P5 | Full Traceability | Every action taken by an agent and every artefact produced must be traceable to its inputs, agent version, scripts, paths, and human authorisations. Provenance must be recorded as a directed graph, enabling full traceability across processes including large language model prompts, with export and import functionality. | Provenance must be recorded using a recognised community standard such as PROV-O (see Section 5.4). Digital fingerprints and signatures must be assigned to all resources and actions. Where human roles are recorded, a recognised taxonomy such as CRediT1 must be used. Human identifiers must use persistent identifiers (PIDs) such as ORCID. Provenance access is restricted by default. Dataset versions must be individually traceable. Records must support compliance evidence on demand. |
| P6 | Open Standards | The system must consume and produce metadata using open, community-maintained standards and specifications rather than bespoke formats, to facilitate interoperability and reusability across systems, disciplines, and scientific domains. It must align with RDA Recommendations and Outputs. | New schema requirements must be sought in existing open standards. Agents must distinguish between general-purpose and community-specific standards when making recommendations. Crosswalks and semantic mappings between standards must be documented to enable cross-domain data transition. Agents should recommend domain-appropriate standards drawing on community resources such as GO FAIR. |
| P7 | Open Source | Implementations of the Data Director should be developed and distributed as open-source software under a permissive licence such as MIT or Apache 2.0. Open source is strongly preferred because it enables community contribution, independent audit of AI behaviour, and global reuse without access barriers. | Source code must be published in a publicly accessible repository following recognised coding standards. Contributions must be accountable. Dependencies should favour open-source components. Proprietary components must be explicitly justified, documented, and must not create lock-in. The open-source preference reflects P6 (Open Standards) and the Blueprint's technology-agnostic framing: openness is the default; this preference does not prohibit proprietary implementations. |
| P8 | Explainable AI | All AI-generated recommendations, metadata records, and decisions must be accompanied by a human-readable explanation of how the output was reached. Explanations must be accessible to non-technical users. All prompts used in agentic AI and sources for metadata schemas must be transparent and publicly available. | Every AI action must surface a contextualised summary with links back to sources, including a visible chain-of-thought reasoning window. Explanations must be exportable for review. Agents must provide feedback on what can be improved or is missing for the targeted repository. Black-box outputs are not acceptable. |
| P9 | Locally Adaptable | The Data Director must support meaningful configuration at the institutional level to reflect local policies, funder and journal requirements, and disciplinary practices, including approved repositories and PID systems, without requiring changes to the core specification. | Configuration points must be exposed for metadata schemas, repository preferences, access controls, protection levels, retention, storage backend, draft and publish workflows, review access, and integration with existing tooling. Core and configurable components must be architecturally separated. Policy inconsistencies must be surfaced explicitly. Core FAIR and security requirements cannot be overridden. |
| P10 | Data Sovereignty | The Data Director must respect national sovereignty and data residency requirements, ensuring that data remains within required jurisdictional boundaries. This applies particularly to nationally funded research and sensitive data contexts. Sovereignty requirements extend beyond the primary dataset to include AI processing, prompts, logs, temporary files, backups, embeddings, telemetry, and any derived artefacts generated throughout the workflow. | Implementations must support local and edge deployment to meet data residency mandates without dependence on foreign cloud infrastructure. Compliance with national sovereignty requirements must be configurable at the institutional level and documented. |
| P11 | Deploy Anywhere | The Data Director must be deployable across edge, local, and cloud environments, ensuring researchers can access and use the system regardless of their available infrastructure, technical resources, or institutional support. This principle is in direct tension with P10 (Data Sovereignty) in contexts where cloud deployment may be available but is jurisdictionally prohibited; Section 5.3 requires implementers to document how this tension has been resolved. | Implementations must not require cloud infrastructure as a prerequisite. A minimum viable deployment must be defined and documented for resource-constrained environments. No single deployment environment should be privileged in the core architecture. |
| P12 | Inclusive Access | The Data Director must be designed to include rather than exclude, across data sources, communities, users, and digital access needs. FAIR principles must be informed by CARE principles from the outset, ensuring that Indigenous and community voices shape how their data is represented and acted upon. | Implementations must assess data source readiness to identify exclusion risks. Digital accessibility standards must be met across all interfaces. Indigenous and community stakeholders must be included in governance and design. Autonomous agent data source selection must be governed to prevent unintended exclusion of relevant datasets or communities. |
| P13 | Built to Last | The Data Director must be built on actively maintained, community-supported tools and architectures that do not create unsustainable operational burdens. External services, repositories, PID services, and vocabulary services represent risks outside the Data Director's control. When external dependencies are temporarily unavailable, the system must continue to function for unaffected workflow steps, alert the user clearly, and allow work to be saved and resumed without data loss. | Dependencies must be evaluated for long-term viability before adoption. No single vendor or platform should be a single point of failure. Deprecated components must have documented migration paths. Workflows must queue or pause rather than fail silently when external services are unavailable. |
| P14 | Low Impact | The Data Director must minimise its environmental footprint. Edge data centres near end-users are the preferred default for compute tasks over centralised cloud infrastructure. The Data Director must not place unsustainable demands on community repository infrastructure. | Edge deployment is the default unless centralised infrastructure is demonstrably more efficient, which must be justified and documented. Repository recommendations must consider the capacity and funding status of target repositories to avoid contributing to submission overload. Where cloud deployment is adopted under P11, implementers should document how the environmental impact has been considered and why edge deployment was not viable. Energy footprint should be captured in provenance records at the component and workflow step level to support evaluation and optimisation over time. |