Shared values and principles that define a connected Open Science infrastructure — drafted at a national consultation on July 1, 2026, and published here as a work in progress.
This page is SPII deliverable 1A's feedback and issue tracker. Anyone can open an issue to propose a correction, flag a gap, or suggest an addition.
New, October 2026: POSI, the Principles of Open Scholarly Infrastructure, is now the official assessment framework in the Principles Alignment Tool. A draft that extends POSI with these principles and a four-level maturity scale, POSI+SPII merged v0.5, will be discussed with the POSI community — see the decision.
AI-assisted: the "how these were formed" story, the file conversions, and the POSI+SPII v0.5 overlap analysis, proposal and maturity matrix below were drafted with AI (Claude) from the linked sources, and are pending review by the SPII team and, for POSI+SPII, the POSI community.
Version dated July 8, 2026 — the framework this repository tracks feedback on. Three shared values, grounded in UNESCO's Open Science recommendation and the Dutch NPOS2030 ambition document; five principles, each broken into subprinciples and the actions that put them into practice. See how it was formed below.
| Value | Grounded in |
|---|---|
| Quality and integrity | "Quality and integrity" (UNESCO); "Reproducibility and scrutiny are essential to safeguard the quality and integrity of scientific work" (NPOS) |
| Collective benefit | "Collective benefit" (UNESCO); "Scientific knowledge is a public good and access to it is a universal right" (NPOS) |
| Equity, fairness, diversity and inclusion | "Equity and fairness" (UNESCO); "Diversity and inclusiveness" (UNESCO); "Diversity, equity, and inclusiveness are crucial for the success of Open Science" (NPOS) |
Values can be seen as shared commitments. The values of UNESCO and NPOS are taken as a point of departure for developing the principles below — actionable guidelines that can be made operational as actions, enablers, practices, or consequences.
| Principle | Subprinciples | Actions, enablers, practices, consequences |
|---|---|---|
| Openness Scientific outputs and processes must be as open as possible, but as restricted as necessary1 |
|
|
| Autonomy Academic and digital sovereignty must be safeguarded1 |
|
|
| Sustainability |
|
|
| Interoperability |
|
|
| Researcher-centric |
|
|
Source: values-and-principles-2026-07-08.md (converted from the original .docx).
Sixty people picked apart Open Science infrastructure for an afternoon at SURF's Utrecht office on July 1, 2026. A week later, the arguments had settled into the table above.
The Dutch open-science community agreed on shared ambitions in 2022, when the National Programme Open Science (NPOS) published its NPOS2030 Ambition Document with five guiding principles. Three became this framework's values, quoted almost verbatim: quality and integrity, collective benefit, and equity, fairness, diversity and inclusion. The other two, reworded, became its first two principles — "as open as possible, but as restricted as necessary" became Openness, and "academic and digital sovereignty must be safeguarded" became Autonomy.
Turning ambition into infrastructure took longer. Open Science NL, the funding body set up in 2023, began financing open-infrastructure projects. Sixteen organizations — among them OCW, NWO, Universities of the Netherlands (UNL), NFU and SURF — formed a standing national consultation to coordinate. By November 2024 they had agreed to develop a joint project: the Strategic Plan for Integrated Infrastructure for Open Science, or SPII. A first phase delivered results by mid-2025; a second phase, SPII 2026, started that April with a mandate to build a reference model for the whole landscape. The July 1 consultation was its opening move.
John Doove of SURF chaired the afternoon; Darco Jansen of Universities of the Netherlands introduced the programme. Maurits van der Graaf presented a proposed reference model — guiding principles, a landscape overview, shared terminology and an interoperability framework — before the room split into breakout groups.
Fifty-nine attendees answered a live poll on which infrastructure they represented, with more than one answer allowed. Research data management projects made up the largest group (13, plus 2 more in research software management), followed by disciplinary infrastructures (12), publication and CRIS systems (12 combined), open-science coordination and policy roles (11), infrastructure-as-a-whole roles (6), open research information (3) and hardware (2).
Organizers walked in with a skeleton already sketched: the three NPOS-derived values, Openness and Autonomy as principles, and Sustainability, Interoperability and Researcher-centric proposed alongside them. The breakout groups' task wasn't to invent from a blank page — it was to add or change the subprinciples, and to name the practices that would put each principle into effect. Seven people per table, one poster each.
The eight groups worked from a shared template — principles down the left, subprinciples and consequences across — and filled it in with sticky notes.
"Processes are key. Describe the process of the research journey (interacting with the systems in and outside your uni)."
— breakout poster 1, Openness column
"Risk assessments: using a commercial system might cost more than developing in-house — but you can stop paying, not sack staff."
— breakout poster 1, Sustainability column
"Make sure you have USERS!"
— breakout poster 1, Researcher-centric column
The closing plenary polled the room again on the day's broader challenges: 72 answers, which organizers sorted into themes. Governance topped the list at 22 mentions, ahead of fragmented infrastructure connections (13), sustainability (11), interoperability (6), user needs (6), security (3), closed-source software (2) and shared terminology (2).
The closing feedback wasn't uniformly positive. Among the written remarks organizers recorded:
"We have discussed the principles for years already. Focus on use cases and implementation."
"Please convince me that we need additional principle harmonizing work given that the universities have already signed off the NPOS principles."
"Too abstract."
Other attendees asked for the consultation itself to widen: invite researchers directly, connect to related national projects, and "don't limit review & discussion of the reference model as a whole to the Open Science festival only." That comment turned out prescient — a dedicated review workshop was already scheduled for the Open Science Festival on Oct. 14. All of it is recorded verbatim in the raw Mentimeter export, linked below.
Organizers spent the following week turning eight posters and dozens of Mentimeter answers into a single draft: five principles, their subprinciples, and the practices that would put them into effect. Not every suggestion survived the cut — a table of ideas left out, from "protection layers for AI where needed" to "invest in engagement of board members," is preserved in full in the archive below.
The version published July 8, 2026 — the table at the top of this page — grounds the framework's three values directly in UNESCO's Open Science recommendation and the NPOS ambition document, and its principles in a wider set of existing frameworks: the TRUST Principles for digital repositories, the Principles of Open Scholarly Infrastructure (POSI), the Seven Guiding Principles for Open Research Information — the same 2022 document deliverable 1B's Principles Alignment Tool now offers as its own 7GPRI framework — and a forthcoming national open-access strategy.
In late September 2026 the principles subgroup changed course. Applicants to Open Science NL's upcoming infrastructure call will be asked to look at POSI, the Principles of Open Scholarly Infrastructure, which infrastructures internationally, Crossref among them, are adopting. A separate set of SPII principles risked confusing applicants and meeting little enthusiasm.
The SPII project's external consultant proposed presenting the SPII principles as complementary to POSI: the Principles Alignment Tool covers POSI first, then only the SPII principles POSI does not already cover. The subgroup agreed, and asked for the overlap to be made clear here, in deliverable 1A, first.
POSI self-assessments often use a three-point scale; the draft SPII matrix uses four, so there is always an ambition left to reach for. The POSI+SPII v0.5 proposal and its four-level maturity matrix below combine the two: POSI's three points map onto Levels 1 to 3, and Level 4 goes beyond. Both were drafted with AI and are open for review.
On October 1, 2026, SPII's values and principles working group decided that POSI v2.0 is the official assessment framework in the Principles Alignment Tool. The four-level maturity scale and the SPII additions proposed here will be shown to and discussed with POSI's authors and the wider POSI community. They need careful review there, with the aim of a mandate for POSI to adopt them officially, on a global scale.
The July 8 table and POSI+SPII are both drafts. The July 8 table is the direct basis for the SPII v0.1 framework in deliverable 1B's Principles Alignment Tool, so a correction made here should eventually be reflected there too. In the tool, POSI v2.0 comes first as the approved framework, followed by POSI+SPII. Use the feedback link above to propose a change.
Draft proposal, September 29, 2026. It compares the SPII principles — the July 8, 2026 outcome above and the v0.3 maturity matrix below — with the Principles of Open Scholarly Infrastructure (POSI v2.0, 2025), and proposes a merged set: all twenty POSI principles, unchanged, followed by only those SPII principles that POSI does not already cover. See "From SPII to POSI+SPII" in the story above for why.
Status. On October 1, 2026, SPII's values and principles working group decided that POSI v2.0 is the official assessment framework in the Principles Alignment Tool. The four-level maturity scale and the SPII additions proposed here will be shown to and discussed with POSI's authors and the wider POSI community. They need careful review there, with the aim of a mandate for POSI to adopt them officially, on a global scale. Until then, POSI+SPII is a draft proposal: not a version of POSI, and not published or endorsed by the POSI Adopters. POSI's own text stays verbatim inside it, so an infrastructure's POSI self-assessment stays valid in its own right.
Drafted with AI (Claude) from the sources linked on this page, and not yet reviewed by the SPII team. Every judgement below — which items overlap, where each SPII idea lands, and the wording of the SPII additions — is a proposal for the principles subgroup to accept, change or reject.
Each SPII subprinciple, plus the actions and v0.3 subprinciples that carry a distinct idea, set against its nearest POSI v2.0 principle. "Partly covered" means POSI touches the idea but narrower or differently: typically POSI asks it of the organisation behind an infrastructure, where SPII asks it of the infrastructure's relation to its users and the wider ecosystem.
| SPII item | POSI v2.0 counterpart | Verdict | Where it lands in POSI+SPII |
|---|---|---|---|
| Transparency: governance 1A 1.1 | Transparent governance | Covered by POSI | POSI: Transparent governance |
| Transparency: operations 1A 1.1 | Transparent operations | Covered by POSI | POSI: Transparent operations |
| Transparency: economical 1A 1.1 | Transparent operations (detailed financials, fees, sustainability models) | Covered by POSI | POSI: Transparent operations |
| Transparency: strategical 1A 1.1 | Transparent operations (strategic and product roadmaps) | Covered by POSI | POSI: Transparent operations |
| Transparency: provenance; Transparent processes 1A 1.1; v0.3 | None | Not in POSI | SPII addition: Transparent processes and provenance |
| Accessibility; Results openly available; Open data, APIs, repositories, metadata (actions 12-15) 1A 1.2; v0.3 | Open and secure data; Available and preserved — but only for data needed to run or fork the infrastructure, not findable access to every result it holds | Partly covered | SPII addition: Findable and accessible results |
| Open-source software (action 11); Open source 1A; v0.3 | Open source | Covered by POSI | POSI: Open source (builds on the v0.3 levels) |
| Open licences (action 16) 1A | Open source; Open and secure data (CC0) — licences for software and data, not compatible terms of use across systems | Partly covered | SPII addition: Legal interoperability |
| Public infrastructure stack (action 17); Support for public stack (action 36) 1A | None | Not in POSI | SPII addition: Digital sovereignty |
| Knowledge security, security by design (action 18) 1A | Open and secure data — mentions security requirements in passing only | Partly covered | SPII addition: Security by design and knowledge security |
| Identity and access management with access for citizen scientists (action 19) 1A | None | Not in POSI | SPII addition: Accessible to all |
| Open to new ideas v0.3 | Goal to generate surplus — the ability to adapt and change, not an innovation process | Partly covered | SPII addition: Open to new ideas |
| Open to participation v0.3 | Non-discriminatory participation or membership | Covered by POSI | POSI: Non-discriminatory participation or membership |
| Stakeholder governed / community-led; Community governed 1A 2.1; v0.3 | Stakeholder governed | Covered by POSI | POSI: Stakeholder governed (builds on the v0.3 levels) |
| Discipline-specific; Fit-for-purpose (action 23) 1A 2.2 | None — Coverage across the scholarly enterprise pulls the other way | Not in POSI | SPII addition: Fit for the community's purpose |
| Digital sovereignty; Value-driven procurement (action 20); Balance agency versus costs and risks (action 21) 1A 2.3 | None — the Insurance principles make forking possible, but do not ask who controls critical components | Not in POSI | SPII addition: Digital sovereignty |
| Reduced dependence on single supplier; Contractual clauses and exit strategy (action 22) v0.3; 1A | Open source; Interoperability and open standards — both lower lock-in, neither asks for an exit plan | Partly covered | SPII addition: Reduced dependence on a single supplier |
| Responsibility; Clear responsibilities 1A 2.4; v0.3 | Stakeholder governed — who decides, not who is accountable for operation | Partly covered | SPII addition: Clear responsibilities |
| Regular review of purpose and community value (action 24) 1A | Regular review of purpose and community value (same wording) | Covered by POSI | POSI: Regular review of purpose and community value |
| Financial sustainability; Financially secure; Sustainable funding (action 34) 1A 3.1; v0.3 | Time-limited funds; Goal to generate surplus; Financial reserves | Covered by POSI | POSI: Time-limited funds (builds on the v0.3 levels), Surplus, Reserves |
| Make-or-buy guidelines (action 30); Total cost of ownership (action 31) 1A | None | Not in POSI | SPII addition: Digital sovereignty (folded into its text) |
| Mission-consistent revenue generation (action 32) 1A | Mission-consistent revenue generation (same wording) | Covered by POSI | POSI: Mission-consistent revenue generation |
| Enduring availability; End-of-life policy (action 33) 1A 3.4 | Living will; Available and preserved | Covered by POSI | POSI: Living will, Available and preserved |
| Human capacity sustainability; Human capacity available 1A 3.2; v0.3 | Transition planning; Volunteer labour | Covered by POSI | POSI: Transition planning (builds on the v0.3 levels), Volunteer labour |
| Legal and institutional compliance; Legal and policy compliant 1A 3.3; v0.3 | None — POSI only says "within the constraints of privacy laws" | Not in POSI | SPII addition: Legal and policy compliance |
| Resilient; Sustained maintenance (action 35) v0.3; 1A | Financial reserves (for major unforeseen events) — financial, not operational resilience | Partly covered | SPII addition: Operational resilience |
| Institutionally embedded v0.3 | None | Not in POSI | SPII addition: Institutionally embedded |
| Technical interoperability: open standards (action 40a) 1A 4.1 | Prioritise interoperability and open standards | Covered by POSI | POSI: Interoperability and open standards |
| PIDs (action 40b); Connections to international infrastructures (action 40c); Interconnected 1A 4.1; v0.3 | None | Not in POSI | SPII addition: Interconnected |
| Organisational and social interoperability; Vocabularies and ontologies (action 41a) 1A 4.2 | None | Not in POSI | SPII addition: Semantic and organisational interoperability |
| Legal interoperability; Terms of use (action 42) 1A 4.3 | Open source; Open and secure data — licences, not compatibility | Partly covered | SPII addition: Legal interoperability |
| Seamless user-experience; User-driven design (action 51) 1A 5.1; v0.3 | None | Not in POSI | SPII addition: Seamless user experience |
| Accessible to all v0.3 | None — Non-discriminatory participation is about governance, not use | Not in POSI | SPII addition: Accessible to all |
| Recognition and rewards (action 52) 1A; v0.3 | Volunteer labour — recognises volunteers as a resource, not contributions in careers | Partly covered | SPII addition: Recognition and rewards |
The pattern is clear. POSI already covers most of what SPII says about governance, finance, transparency and enduring availability — two SPII actions (regular review, mission-consistent revenue) even use POSI's own wording. What POSI lacks is almost everything SPII says about interoperability beyond open standards, about researchers as users, and about digital sovereignty, compliance and operational resilience.
Seven POSI principles have no clear SPII counterpart. In POSI+SPII they come along unchanged — a net gain for SPII:
Thirty-seven principles in eight sections. The first three sections are POSI v2.0, quoted verbatim, so an infrastructure's existing POSI self-assessment stays valid as the first part of a POSI+SPII one. The last five hold the seventeen SPII additions, grouped under the SPII principle they come from. SPII's three values — quality and integrity; collective benefit; equity, fairness, diversity and inclusion — have no counterpart in POSI and stay as the shared commitments above all thirty-seven.
POSI v2.0 originally POSI, text verbatim · SPII addition from SPII 1A or the v0.3 matrix, text drafted for this proposal
| # | Principle | Text | SPII counterpart |
|---|---|---|---|
| Governance — originally POSI v2.0, quoted verbatim | |||
| 1 | Coverage across the scholarly enterprise POSI v2.0 | Research transcends disciplines, geography, institutions, and stakeholders. Organisations and the infrastructure they run need to reflect this. | — |
| 2 | Stakeholder governed POSI v2.0 | A board-governed organisation drawn from the stakeholder community builds confidence that the organisation will make decisions driven by community consensus and a balance of interests. | Stakeholder governed / community-led (1A 2.1); Community governed (v0.3) |
| 3 | Non-discriminatory participation or membership POSI v2.0 | We see the best option to be an “opt-in” approach with principles of non-discrimination and inclusivity, where any relevant group may express an interest and should be welcome. Representation in governance must reflect the character of the community or membership. | Open to participation (v0.3) |
| 4 | Transparent governance POSI v2.0 | To foster trust, the processes and policies for governing the organisation and selecting representatives to governance groups should be transparent (within the constraints of privacy laws). | Transparency: governance (1A 1.1) |
| 5 | Cannot lobby POSI v2.0 | Infrastructure organisations should not lobby for regulatory change to cement their own positions or narrow self-interest. However, an infrastructure organisation’s role is to support its community, and this can include advocating for policy changes. | — |
| 6 | Living will POSI v2.0 | To build trust, organisations should establish and communicate clear commitments regarding their long-term stewardship responsibilities, including the principles by which assets, data, resources, services, and staff would be responsibly transferred to a successor or the organisation or service wound down. The commitments should address future governance, with defined criteria for acceptable successor organisations. This should include continued alignment with POSI and any legal or structural constraints. | Enduring availability (1A 3.4); End-of-life policy (action 33) |
| 7 | Regular review of purpose and community value POSI v2.0 | Organisations and services should regularly review their relevance, effectiveness, and the level of community support to determine whether their continued operation is necessary. If no longer needed, they should take responsible steps to transition or wind down operations in consultation with the community and in alignment with their living will. | Regular review of purpose and community value (action 24) |
| Sustainability — originally POSI v2.0, quoted verbatim | |||
| 8 | Transparent operations POSI v2.0 | To enable organisational accountability and openness, the operating policies and procedures, detailed financials, sustainability models, fees, strategic and product roadmaps, organisational charts, and other appropriate operational information should be made openly available (within the constraints of privacy laws). Information should be available for investigation and reuse by the community. | Transparency: operations, economical, strategical (1A 1.1) |
| 9 | Time-limited funds are used only for time-limited activities POSI v2.0 | Operations should be supported by sustainable revenue sources, whereas time-limited funds are used only for time-limited activities. Depending on grants to fund ongoing and/or long-term operations fully makes organisations fragile and distracts from maintaining core infrastructure. | Financial sustainability (1A 3.1); Financially secure (v0.3); Sustainable funding (action 34) |
| 10 | Goal to generate surplus POSI v2.0 | It is not enough to merely survive; organisations and services have to be able to adapt and change. Organisations and services that define long-term sustainability based only on recovering costs risk becoming brittle and stagnant. To weather economic, social and technological volatility, organisations and services need financial resources beyond immediate operating costs. | — |
| 11 | Establish and maintain financial reserves guided by policy POSI v2.0 | Organisations and services should have a clear policy on maintaining financial reserves, including the purpose, minimum and maximum level, and governance of these funds. The actual level of reserves should be determined and periodically reviewed by the governing body, ensuring that resources are available to support Living Will implementation, including an orderly wind-down, transition to a successor, or response to major unforeseen events. A financial reserve policy might include how funds will be held, under what circumstances they will be used, and how much would be necessary for an adequate wind-down or transfer of assets, given the complexity of the organisation’s infrastructure. | — |
| 12 | Mission-consistent revenue generation POSI v2.0 | Revenue sources should be evaluated against the infrastructure’s mission and not run counter to the aims of the organisation or service. | Mission-consistent revenue generation (action 32) |
| 13 | Revenue generated from services, not data POSI v2.0 | Data related to the running of the scholarly infrastructure should be community property. Appropriate revenue sources might include value-added services, consulting, API Service Level Agreements, or membership fees. | — |
| 14 | Volunteer labour POSI v2.0 | Organisations that rely on volunteers and their labour should recognise this as a valuable resource for the organisation’s long-term viability, and factor it into sustainability planning and risk management. | Human capacity sustainability (1A 3.2), in part |
| 15 | Transition planning POSI v2.0 | Organisations that are heavily dependent on a limited number of individuals should take steps to reduce their dependence on these individuals, including via transition and succession planning, so that the organisation is not at risk of collapse in the event of their departure. | Human capacity sustainability (1A 3.2); Human capacity available (v0.3) |
| Insurance — originally POSI v2.0, quoted verbatim | |||
| 16 | Open source POSI v2.0 | All software and non-physical assets required to run the infrastructure should be available under an open-source licence. This does not include other software that may be involved with running the organisation. | Open-source software (action 11); Open source (v0.3) |
| 17 | Ensure open and secure data accessibility within legal and ethical constraints POSI v2.0 | To support potential forking or replication, infrastructure should aim to make all relevant data openly available, following best practices such as applying a CC0 waiver where appropriate. This must be balanced with compliance with privacy, data protection, and security requirements. Organisations should have a clear policy outlining how private or sensitive data will be handled—particularly in the event of a transfer to another organisation—to ensure continuity, legal compliance, and responsible stewardship. | Open data (action 12); Knowledge security (action 18), in part |
| 18 | Available and preserved POSI v2.0 | It is not enough that content, data, and software be “open” if there is no practical way to obtain them. These resources should be made easily available with clear public documentation about where they are and how to access them, as well as an open licence where possible. It is not enough that “open” resources are available. In line with the Living Will, it is essential to deposit content, data, and software with at least one trusted third-party digital archive. | Enduring availability (1A 3.4); Open repositories (action 14) |
| 19 | Patent non-assertion POSI v2.0 | The organisation should commit to a patent non-assertion policy or covenant. The organisation may obtain patents to protect its own operations, but not use them to prevent the community from replicating the infrastructure. | — |
| 20 | Prioritise interoperability and open standards to ensure continuity and resilience POSI v2.0 | Infrastructures should adopt and support widely accepted open standards—both formal and de facto—to ensure that systems, data, and services can be replicated, migrated, or integrated with minimal disruption without the use of proprietary extensions or software. Where relevant, organisations should document dependencies on standards. | Technical interoperability: open standards (1A 4.1, action 40a) |
| SPII+ Openness — SPII addition, drafted for this proposal | |||
| 21 | Transparent processes and provenance SPII addition | The origin, custody and changes of data, content, software and decisions in the infrastructure can be traced. The steps of its processes are documented and recorded when executed, as open as possible and as restricted as necessary. | Transparency: provenance (1A 1.1); Transparent processes (v0.3) |
| 22 | Findable and accessible results SPII addition | Results — any output created by the infrastructure itself or stored in it, such as datasets and content — are described with open metadata, and are findable and accessible through open interfaces (APIs), as open as possible and as restricted as necessary. | Accessibility (1A 1.2); Results openly available (v0.3); Open data, APIs, repositories, metadata (actions 12-15) |
| 23 | Open to new ideas SPII addition | The infrastructure keeps improving: it has a way to collect, weigh and act on new ideas from its users, staff and the wider community. | Open to new ideas (v0.3) |
| 24 | Security by design and knowledge security SPII addition | Security and knowledge security are built into the infrastructure's design and operation, so that openness is restricted only where necessary and access to sensitive data, software and services is managed responsibly. | Knowledge security, security by design (action 18); Identity and access management (action 19) |
| SPII+ Autonomy — SPII addition, drafted for this proposal | |||
| 25 | Digital sovereignty SPII addition | Control over the infrastructure's data, software and decisions stays with the academic community. Critical components are chosen through value-driven procurement, preferably from a public or community-governed stack, and make-or-buy decisions weigh agency against total cost of ownership and risk. | Digital sovereignty (1A 2.3); Value-driven procurement, Balance agency versus costs and risks, Make or buy, Total cost of ownership, Public infrastructure stack (actions 17, 20, 21, 30, 31, 36) |
| 26 | Reduced dependence on a single supplier SPII addition | The infrastructure avoids lock-in to a single supplier: contracts include exit clauses, and it can migrate to realistic alternatives. See also the Digital Autonomy Assessment Framework (utrechtuniversity.github.io/digital-autonomy-assessment-tool). | Reduced dependence on single supplier (v0.3); Contractual clauses and exit strategy (action 22) |
| 27 | Clear responsibilities SPII addition | It is clear who is responsible for the infrastructure's operation, its decisions and their consequences, both within the organisation and between the partners that jointly run or fund it. | Responsibility (1A 2.4); Clear responsibilities (v0.3) |
| 28 | Fit for the community's purpose SPII addition | The infrastructure fits the specific needs, norms and workflows of the research communities and disciplines it serves, and those communities help decide what fit for purpose means. | Discipline-specific (1A 2.2); Fit-for-purpose (action 23) |
| SPII+ Sustainability — SPII addition, drafted for this proposal | |||
| 29 | Legal and policy compliance SPII addition | The infrastructure meets applicable legal requirements, such as privacy, copyright and accessibility law, and the policies of the institutions it serves. | Legal and institutional compliance (1A 3.3); Legal and policy compliant (v0.3) |
| 30 | Operational resilience SPII addition | The infrastructure can withstand and recover from disruption — technical failure, cyber incidents, loss of funding or staff, or geopolitical events — and is maintained continuously. | Resilient (v0.3); Sustained maintenance (action 35) |
| 31 | Institutionally embedded SPII addition | The infrastructure is embedded in the strategy, policies and budgets of the institutions that host or use it, rather than depending on individual champions or projects. | Institutionally embedded (v0.3) |
| SPII+ Interoperability — SPII addition, drafted for this proposal | |||
| 32 | Interconnected SPII addition | The infrastructure connects to other infrastructures, nationally and internationally, using persistent identifiers (PIDs) and two-way exchange, so that information flows without manual re-entry. | PIDs (action 40b); Connections to international infrastructures (action 40c); Interconnected (v0.3) |
| 33 | Semantic and organisational interoperability SPII addition | Shared vocabularies, ontologies and agreements let the infrastructure's data and processes be understood consistently across organisations and communities. | Organisational and social interoperability (1A 4.2); Vocabularies and ontologies (action 41a) |
| 34 | Legal interoperability SPII addition | Clear, compatible terms of use and licences let data, software and content be legally reused and combined across systems. | Legal interoperability (1A 4.3); Open licences (action 16); Terms of use (action 42) |
| SPII+ Researcher-centric — SPII addition, drafted for this proposal | |||
| 35 | Seamless user experience SPII addition | The infrastructure is designed around researchers' actual workflows, so that they can reach their goals with little friction across the systems they use. | Seamless user-experience (1A 5.1; v0.3); User-driven design (action 51) |
| 36 | Accessible to all SPII addition | Everyone who needs the infrastructure can use it — across institutions, countries and roles, including citizen scientists and people with disabilities — with identity and access management that does not exclude them. | Accessible to all (v0.3); Identity and access management with access for citizen scientists (action 19); value Equity, fairness, diversity and inclusion |
| 37 | Recognition and rewards SPII addition | Contributions made through or to the infrastructure — data, software, curation, review, maintenance — are visible, citable and recognised in academic evaluation and careers. | Recognition and rewards framework (action 52); Recognition and rewards (v0.3) |
View as CSV · overlap analysis as CSV · see data/posi-spii/README.md for provenance. POSI text: POSI Adopters (2025), The Principles of Open Scholarly Infrastructure, doi.org/10.14454/G8WV-VM65.
Four levels for each of the thirty-seven POSI+SPII principles, written with the spii-maturity-levels guidance: the same subject at every level, each level including the one before, observable statements in at most about 25 words, and no invented numeric thresholds. The shape of the scale follows the four inspiration frameworks named under the original maturity matrix; some wording reuses concepts from the other frameworks in the Principles Alignment Tool (GORC, FAIR, BD, OSR, 7GPRI), noted per principle in the CSV.
All level texts were written with AI (Claude) for this proposal and are pending curator review. Those marked "Improved from SPII maturity matrix v0.3" rework that matrix's own descriptions; the rest are new. Three principles are marked "close to yes-or-no" (see the considerations above). The "To improve" line under each principle names the most likely next step.
| Principle | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
| Governance | ||||
| 1. Coverage across the scholarly enterprise POSI v2.0Drafted with AI for this proposalTo improve: Map which disciplines, regions and stakeholder groups rely on the infrastructure, and publish where its services or governance do not yet reach them. | The infrastructure serves a single institution, discipline or stakeholder group, and its governance does not consider others. | The infrastructure is used beyond its original community, but its services and governance still mainly reflect that one group. | Services and governance are documented as open to all disciplines, regions and stakeholder types that rely on the infrastructure. | Coverage across disciplines, regions and stakeholders is published and reviewed with the community, and gaps are actively closed. |
| 2. Stakeholder governed POSI v2.0Improved from SPII maturity matrix v0.3 (Community governed) using the spii-maturity-levels definitions; the original is unchanged in the v0.3 matrix belowTo improve: Move from an advisory role to a governing board drawn from the main stakeholder and user groups, with a documented way for the community to elect its members. | Decisions are made by a single party, with no clear way for the community to take part. | Governance is shared by several parties, and an advisory board or similar body represents the community. | A consortium or board representing the main stakeholders and user groups holds decision-making power under documented rules. | The community takes full part in governance through elections and self-governance, and the governance model is published and reviewed. |
| 3. Non-discriminatory participation or membership POSI v2.0Drafted with AI for this proposal (informed by the v0.3 subprinciple Open to participation, which has no levels yet)To improve: Publish opt-in membership criteria that any relevant group can meet, and check whether governance seats reflect the membership. | There is no route for new organisations or groups to join the infrastructure or be represented in its governance. | New participants can join on request, but criteria are informal and representation mainly reflects the founding members. | Documented opt-in membership criteria are open to any relevant group, and governance seats reflect the membership. | Participation is open, non-discriminatory and reviewed with the community, and under-represented groups, regions and disciplines are actively invited. |
| 4. Transparent governance POSI v2.0Drafted with AI for this proposalTo improve: Document and publish how governance representatives are selected and how decisions are made, not only who sits on the board. | How the infrastructure is governed and how representatives are chosen is not documented. | Some governance information, such as board membership, is published, but selection processes and decisions are not. | Governance policies, selection processes and decisions are documented and published, within the constraints of privacy law. | Governance policies, selection processes, minutes and decisions are published, and the community is invited to review and challenge them. |
| 5. Cannot lobby POSI v2.0Drafted with AI for this proposalClose to yes-or-no: this principle is really met or not met, so Levels 2 and 4 are thin. Level 2 is the practice without a formal commitment; Level 4 makes the commitment durable and community-reviewed.To improve: Publish a short policy that separates advocacy for the community from lobbying for the organisation's own position. | The organisation's position on lobbying is unknown, or it lobbies for rules that protect its own position. | The organisation does not lobby for its own position, but has no stated policy on it. | A published policy commits the organisation not to lobby for narrow self-interest, while allowing advocacy for its community. | The published policy is reviewed by the governing body, and advocacy positions are developed with and published to the community. |
| 6. Living will POSI v2.0Drafted with AI for this proposalTo improve: Write and publish a living will that covers the transfer of assets, data, services and staff, including criteria for an acceptable successor. | There is no plan for what happens to assets, data, services and staff if the infrastructure winds down. | Wind-down or transfer has been discussed internally, but no plan is documented. | A living will is documented and published, describing how assets, data, services and staff would transfer to a successor or be wound down. | The published living will names criteria for successors, is reviewed regularly with the community, and is backed by reserves and archive agreements. |
| 7. Regular review of purpose and community value POSI v2.0Drafted with AI for this proposalTo improve: Put a periodic review of relevance and community support on the governing body's agenda, and record its outcome. | The infrastructure's relevance and community support are never formally reviewed. | Relevance is discussed now and then, usually prompted by a funding decision or a crisis. | The governing body reviews relevance, effectiveness and community support on a documented schedule, and records the outcome. | Reviews involve the community, their outcomes are published, and they have led to change, transition or a responsible wind-down where needed. |
| Sustainability | ||||
| 8. Transparent operations POSI v2.0Drafted with AI for this proposalTo improve: Publish detailed financials, fees and strategic and product roadmaps alongside the operating policies, in a form the community can reuse. | Operating policies, financials, fees and roadmaps are not published. | Some operational information, such as fees or an annual report, is published, but detailed financials and roadmaps are not. | Operating policies, detailed financials, fees, sustainability model, roadmaps and organisational chart are published, within the constraints of privacy law. | All of this is published in reusable formats, kept current, and the community can question and reuse it. |
| 9. Time-limited funds are used only for time-limited activities POSI v2.0Improved from SPII maturity matrix v0.3 (Financially secure, Levels 1-3) using the spii-maturity-levels definitions; Level 4 added, as v0.3 has none; the original is unchanged in the v0.3 matrix belowTo improve: Separate core operating costs from project costs, and move core operations onto recurring revenue such as memberships or service fees. | There is no funding now or for the foreseeable future. | There is only time-limited funding, such as a one-off grant or donation, and it also pays for ongoing operations. | Multi-year funding is in place, for example through memberships and recurrent grants, and core operations are budgeted separately from projects. | Core operations run on recurring revenue such as memberships or service fees, and time-limited funds pay only for time-limited activities. |
| 10. Goal to generate surplus POSI v2.0Drafted with AI for this proposalTo improve: Set a target to generate a surplus above operating costs, and agree how the governing body will decide on its use. | The infrastructure does not recover its operating costs. | Operating costs are roughly covered, but nothing is left to adapt, innovate or absorb setbacks. | Revenue exceeds operating costs by a planned margin, and the governing body decides how the surplus is used. | A published surplus policy funds renewal and innovation, and the use of surplus is reported to the community. |
| 11. Establish and maintain financial reserves guided by policy POSI v2.0Drafted with AI for this proposalTo improve: Adopt a reserves policy stating purpose, minimum and maximum levels and governance, sized to cover an orderly wind-down. | There are no financial reserves separate from operating funds. | Some reserves exist, but there is no policy on their purpose, level or use. | A reserves policy sets purpose, minimum and maximum level and governance, and the governing body reviews it periodically. | Reserves meet the policy level, are sized to fund an orderly wind-down or transfer, and the policy and actual level are published. |
| 12. Mission-consistent revenue generation POSI v2.0Drafted with AI for this proposalTo improve: Document a mission check for revenue sources, and have the governing body approve any new type of revenue. | Revenue sources are not assessed against the mission. | Mission fit is considered informally for large revenue decisions. | A documented process checks every revenue source against the mission, and the governing body approves new sources. | The revenue model and its mission check are published, and the community is consulted before new types of revenue are introduced. |
| 13. Revenue generated from services, not data POSI v2.0Drafted with AI for this proposalClose to yes-or-no: this principle is really met or not met, so Levels 2 and 4 are thin. Level 2 is the practice without a formal commitment; Level 4 makes the commitment durable and community-reviewed.To improve: Identify revenue that depends on restricting data, and replace it with revenue from services, memberships or service level agreements. | Revenue depends on selling or restricting access to data about running the infrastructure. | Some of that data is community property, but part of the revenue still depends on restricting access to it. | Data about running the infrastructure is community property, and revenue comes from services, memberships or service level agreements. | This is written into published policy and contracts, and the data stays community property after any transfer to a successor. |
| 14. Volunteer labour POSI v2.0Drafted with AI for this proposalTo improve: Record which work depends on volunteers, and include it in sustainability planning and risk management. | Volunteer contributions are not tracked or considered in planning. | Volunteers are known and thanked, but their labour is not part of sustainability planning or risk management. | Volunteer labour is documented, recognised, and included in sustainability planning and risk management. | Volunteers are supported with onboarding and credit, their contributions are publicly acknowledged, and planning covers the loss of key volunteers. |
| 15. Transition planning POSI v2.0Improved from SPII maturity matrix v0.3 (Human capacity available: Levels 1-2 and the level names "Somewhat staffed", "Dedicated resourcing") using the spii-maturity-levels definitions; the original is unchanged in the v0.3 matrix belowTo improve: Document the knowledge held by key individuals and name a backup for each critical role, as a first step toward succession planning. | No one is working on the infrastructure, now or for the foreseeable future. | One person keeps the infrastructure running, with no backup and little documented knowledge. | A small team shares the work, key knowledge is documented, and each critical role has a named backup. | Dedicated, funded staff cover all key roles with succession plans, so no single departure puts operations at risk. |
| Insurance | ||||
| 16. Open source POSI v2.0Improved from SPII maturity matrix v0.3 (Open source) using the spii-maturity-levels definitions, covering both using open-source components and releasing the infrastructure's own software; the original is unchanged in the v0.3 matrix belowTo improve: Release all software needed to run the infrastructure under an open-source licence, and invite developers from other organisations to contribute. | The infrastructure runs on proprietary software, and its own code is not released. | Some core components are open source, or part of the infrastructure's own code is released under an open-source licence. | The infrastructure mostly uses open-source components, and all software needed to run it is released under an open-source licence. | The infrastructure leads an active open-source community, with contributing developers from other organisations and active users, and contributes back to components it uses. |
| 17. Ensure open and secure data accessibility within legal and ethical constraints POSI v2.0Drafted with AI for this proposalTo improve: Apply an open licence such as CC0 to all relevant data, and document how private and sensitive data is handled, including on transfer. | Data needed to replicate the infrastructure is not openly available, and there is no policy for private or sensitive data. | Some relevant data is openly available, but licences are unclear and private or sensitive data is handled informally. | All relevant data is available under an open licence such as CC0 where appropriate, with a documented policy for private and sensitive data. | Openly licensed data is released regularly, and the sensitive-data policy, including handling on transfer, is published and externally reviewed. |
| 18. Available and preserved POSI v2.0Drafted with AI for this proposalTo improve: Publish where and how to obtain content, data and software, and deposit them with a trusted third-party archive. | There is no practical, documented way to obtain the content, data and software. | Content, data and software can be obtained on request or in part, and nothing is deposited in an external archive. | Content, data and software are easy to obtain with public documentation, and are deposited with at least one trusted third-party archive. | Regular deposits go to more than one trusted archive, and restoring the infrastructure from them has been tested. |
| 19. Patent non-assertion POSI v2.0Drafted with AI for this proposalClose to yes-or-no: this principle is really met or not met, so Levels 2 and 4 are thin. Level 2 is the practice without a formal commitment; Level 4 makes the commitment durable and community-reviewed.To improve: Publish a patent non-assertion policy or covenant, so the community can replicate the infrastructure without legal risk. | The organisation's position on patents is unknown, or it uses patents to stop others replicating the infrastructure. | The organisation holds no patents that restrict replication, but has made no formal commitment. | The organisation has published a patent non-assertion policy or covenant. | The published covenant is legally binding, survives any transfer to a successor, and is referenced in the living will. |
| 20. Prioritise interoperability and open standards to ensure continuity and resilience POSI v2.0Drafted with AI for this proposalTo improve: Document which standards the infrastructure depends on, and replace proprietary formats or extensions with widely accepted open standards. | The infrastructure relies on proprietary formats and interfaces, and its dependencies on standards are not documented. | Open standards are supported for some core data and interfaces, alongside proprietary extensions. | Widely accepted open standards are used for data, metadata and interfaces without proprietary extensions, and dependencies on standards are documented. | The infrastructure helps develop the open standards it uses, and migration or integration based on them has been demonstrated. |
| SPII+ Openness | ||||
| 21. Transparent processes and provenance SPII additionImproved from SPII maturity matrix v0.3 (Transparent processes) using the spii-maturity-levels definitions; the original is unchanged in the v0.3 matrix belowTo improve: Describe the key processes step by step, and start recording provenance when they run, so origin and changes can be traced. | The infrastructure's processes are not documented, and where its data and decisions come from cannot be traced. | Some processes have guidelines, but steps are not recorded when executed, so provenance can only partly be traced. | All process steps are described and recorded when executed, and this provenance record is available with restrictions. | All process steps are described and recorded when executed, and the provenance record is publicly available and reused by others. |
| 22. Findable and accessible results SPII additionImproved from SPII maturity matrix v0.3 (Results openly available) using the spii-maturity-levels definitions; the original is unchanged in the v0.3 matrix belowTo improve: Describe stored data and content with open metadata, and expose it through an open API so it becomes findable and accessible. | Data and content held by the infrastructure are not available to others. | Data and content are described with metadata and are findable, but not yet accessible. | Data and content are well described with open metadata, findable, and accessible through an open API with restrictions. | Data and content are well described, findable, and accessible to everyone through open APIs under open licences. |
| 23. Open to new ideas SPII additionDrafted with AI for this proposal from the v0.3 level names "At a stand still", "Ad-hoc improvements", "An innovation process is in place", "Continously innovating"To improve: Set up a documented way to collect and prioritise ideas from users, and publish the resulting roadmap. | The infrastructure is not being developed further, and there is no way to propose new ideas. | Improvements happen ad hoc and depend on individuals; suggestions from users are not tracked. | A documented process collects, prioritises and acts on ideas from users and staff, and the resulting roadmap is published. | The community co-creates the roadmap, ideas are tracked in the open, and improvements are shared with and adopted by other infrastructures. |
| 24. Security by design and knowledge security SPII additionDrafted with AI for this proposalTo improve: Name a role responsible for security, and run a documented risk assessment that includes knowledge security. | Security and knowledge security risks are not assessed, and no one is responsible for them. | Basic security measures are in place, but risk assessments are ad hoc and knowledge security is not considered. | A named role owns security, risks including knowledge security are assessed on a documented schedule, and access is managed centrally. | Security is independently audited or certified, security is part of every design decision, and incidents and lessons are shared with peer infrastructures. |
| SPII+ Autonomy | ||||
| 25. Digital sovereignty SPII additionDrafted with AI for this proposalTo improve: List the infrastructure's critical components and who controls them, and add public values and sovereignty risks to procurement criteria. | It is unknown who controls the infrastructure's critical data, software and hosting, or under which terms. | Critical components and their providers are known, but control rests with external parties whose terms the community cannot influence. | Critical components are assessed for sovereignty risks, procurement applies documented public values, and control over data and decisions stays with the community. | Critical components run on a public or community-governed stack, and the infrastructure helps build and maintain that shared stack for others. |
| 26. Reduced dependence on a single supplier SPII additionImproved from SPII maturity matrix v0.3 (Reduced dependence on single supplier) using the spii-maturity-levels definitions; the original is unchanged in the v0.3 matrix belowTo improve: Add exit clauses to supplier contracts, and draft an exit plan that names realistic alternatives. | The infrastructure depends mainly on proprietary software from one supplier, with no known way out. | The infrastructure provides an API for most functions, so data and functionality can be reached outside the supplier's own tools. | Gradual migration to another solution is possible, because integrations and data formats follow open standards and contracts include exit clauses. | A documented exit plan exists, several realistic alternatives are known, and the plan is reviewed regularly. |
| 27. Clear responsibilities SPII additionDrafted with AI for this proposal (v0.3 has no levels for this subprinciple yet)To improve: Document who owns operation, decisions and incident handling, and agree this with every partner that runs or funds the infrastructure. | It is not documented who is responsible for operating the infrastructure or for its decisions. | Responsibilities are known informally within the team, but not documented or agreed with partners. | Responsibilities for operation, decisions and incidents are documented and agreed with all partners, with a named owner for each. | Responsibilities are published and reviewed regularly with partners and users, and users know whom to contact for any issue. |
| 28. Fit for the community's purpose SPII additionDrafted with AI for this proposalTo improve: Gather and document the specific needs of each discipline the infrastructure serves, and use them to set priorities. | The needs of the research communities the infrastructure serves have not been identified. | Community needs are known informally, through a few users or anecdotal feedback. | The needs of each discipline served are documented, gathered with the community, and used to set priorities. | Served communities co-decide priorities, fit is evaluated regularly, and discipline-specific solutions are shared for reuse in other domains. |
| SPII+ Sustainability | ||||
| 29. Legal and policy compliance SPII additionDrafted with AI for this proposal from the v0.3 level names "Unknown", "Major gaps", "Bases covered", "Audited or certified"To improve: Make an inventory of the laws and institutional policies that apply, and document where the infrastructure does not yet comply. | Which laws and institutional policies apply to the infrastructure, and whether it meets them, is unknown. | Applicable laws and policies are identified, but compliance has major gaps. | Compliance with applicable laws and institutional policies is documented, with a named owner and no known major gaps. | Compliance is audited or certified by an independent party, and the results are published. |
| 30. Operational resilience SPII additionDrafted with AI for this proposal from the v0.3 level names "Falls over at the first breeze", "Major gaps", "Bases covered", "Can weather a hurricane"To improve: Identify single points of failure, and write and test a recovery plan for the most critical ones. | Single points of failure are unknown, and there are no backups, maintenance plan or recovery procedure. | Backups and basic maintenance exist, but major single points of failure remain and recovery has not been tested. | Risks are assessed, maintenance is scheduled, and a documented recovery plan has been tested. | Recovery from major disruption is rehearsed regularly, critical components are redundant, and lessons are shared with peer infrastructures. |
| 31. Institutionally embedded SPII additionDrafted with AI for this proposal (v0.3 has no levels for this subprinciple yet)To improve: Get the infrastructure into the policies and multi-year budget of its host institution, with a named institutional contact. | No institution has the infrastructure in its strategy, policies or budget. | The infrastructure depends on individual champions or a project within one or more institutions. | Participating institutions include the infrastructure in their policies and multi-year budgets, with a named contact at each. | The infrastructure is part of institutional and national strategy, and institutions jointly steer and fund it as shared infrastructure. |
| SPII+ Interoperability | ||||
| 32. Interconnected SPII additionImproved from SPII maturity matrix v0.3 (Interconnected: Level 1 and the level names "Uses other systems", "Two-way connected", "Part of flourishing ecosystem") using the spii-maturity-levels definitions; the original is unchanged in the v0.3 matrix belowTo improve: Adopt persistent identifiers for people, organisations and outputs, and set up a two-way connection with a key partner infrastructure. | The infrastructure has no integrations with other systems, and even exchanging data with them is difficult. | The infrastructure takes in data from other systems and uses some persistent identifiers, but sends nothing back. | Two-way connections with key national and international infrastructures are in place, using persistent identifiers for people, organisations and outputs. | The infrastructure is part of a flourishing ecosystem: others build on its connections, and it helps maintain shared identifier and exchange services. |
| 33. Semantic and organisational interoperability SPII additionDrafted with AI for this proposalTo improve: Replace local terms for core fields with widely used, openly published vocabularies, and publish the mapping. | The infrastructure uses its own local terms and definitions, and they are not documented. | Local terms are documented, and some widely used vocabularies are adopted for core fields. | Widely used, openly published vocabularies and ontologies are used for data and metadata, and mappings from local terms are published. | The infrastructure helps maintain shared vocabularies with its community, and agreements with partners make processes work across organisations. |
| 34. Legal interoperability SPII additionDrafted with AI for this proposalTo improve: Apply standard open licences to all resources, and check that they are compatible with the terms of key partner infrastructures. | Terms of use and licences are missing or unclear, so reuse is legally uncertain. | Terms of use exist, but licences differ per resource or are incompatible with those of partner infrastructures. | Standard, machine-readable open licences and clear terms of use apply to all resources, compatible with those of key partners. | Licences and terms are harmonised with partner infrastructures, and the infrastructure contributes to shared legal frameworks for reuse. |
| SPII+ Researcher-centric | ||||
| 35. Seamless user experience SPII additionDrafted with AI for this proposal (v0.3 has no levels for this subprinciple yet)To improve: Run usability tests with researchers on the main workflows, and make user research a standard step in development. | Users' workflows and needs are not known, and there is no way for users to give feedback. | Users can give feedback, and some usability problems are fixed ad hoc. | User research and usability testing are part of development, and the service fits the main research workflows it supports. | Researchers co-design the service, user experience is measured and published, and the service works seamlessly with neighbouring systems in the research journey. |
| 36. Accessible to all SPII additionDrafted with AI for this proposal (v0.3 has no levels for this subprinciple yet)To improve: Offer federated login and an access route for citizen scientists, and test the service against the Web Content Accessibility Guidelines (WCAG). | Access is limited to one institution's users, and accessibility for people with disabilities has not been considered. | Users from other institutions can get access on request, and some accessibility issues are addressed. | Federated login gives access across institutions, citizen scientists have an access route, and the service meets the Web Content Accessibility Guidelines (WCAG). | Access for all relevant users, including citizen scientists, is independently checked, and remaining barriers are reviewed with user groups. |
| 37. Recognition and rewards SPII additionDrafted with AI for this proposal (v0.3 has no levels for this subprinciple yet)To improve: Make contributions citable, and link them to contributors' persistent identifiers such as ORCID. | Contributions made through or to the infrastructure are not visible or attributed. | Some contributions are acknowledged, for example in release notes, but cannot be cited or linked to people. | Contributions are citable and linked to contributors through persistent identifiers such as ORCID, so they can count in evaluation. | Contributions feed into institutional recognition and rewards frameworks, and the infrastructure helps shape how such work is valued. |
View as CSV (includes level sources and the concepts reused from other frameworks).
A separate, earlier result: the draft maturity matrix for these values and principles, now at version 0.3, extracted verbatim from a table Till Bey (CC-BY licensed) shared on 2026-09-21 — see the source PDF. It is the precursor to deliverable 1B's Principles Alignment Tool. Scored 0 (not yet assessed) to 4 per subprinciple. This is still an unfinished draft — several subprinciples below have no level descriptions yet (… or "Maturity level N"), kept as-is for faithful extraction rather than filled in.
Till also pointed to four existing maturity matrices as inspiration for filling in the gaps above: the UK Government's Transformation Capability Framework, Australia's Commonwealth Evaluation Maturity Model, the US Office of Management and Budget's Enterprise Architecture Assessment Framework, and Veritis' DevOps Maturity Model.
| Value | Subprinciple | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|---|
| Openness The most crucial principle for Open Science infrastructures. |
Results openly available Results refers to any output created by the infrastructure itself (the software running the infrastructure) or stored in it (e.g. datasets, content). |
Maturity level 1Data and content is not available. | Maturity level 2Data and content is described with metadata. Data and content is findable. | Maturity level 3Data and content is well described, findable and accessible with restrictions. | Maturity level 4Data and content is well described, findable and accessible to everyone. |
| Transparent processes Explanatory text |
Maturity level 1There is no documentation of what is happening or supposed to happen. | Maturity level 2There is some guidelines on the process. | Maturity level 3All steps in a process are described, recorded when executed and made available with restrictions. | Maturity level 4All steps in a process are well described, recorded when executed and made publicly available. | |
| Open source Explanatory text |
Maturity level 1Only proprietary software is used. | Maturity level 2Some core parts are using open source software. | Maturity level 3Mostly open source software is used. Some open source software is contributed back to the community. | Maturity level 4Full engagement in an open source community. | |
| Open to new ideas Explanatory text |
At a stand still… | Ad-hoc improvements… | An innovation process is in place… | Continously innovating… | |
| Open to participation Explanatory text |
Maturity level 1… | Maturity level 2… | Maturity level 3… | Maturity level 4… | |
| Autonomy Who is calling the shots. |
Community governed Explanatory text |
Maturity level 1Decisions are made by a single party, without clear possibility for the community to participate. | Maturity level 2Governance is shared by multiple parties, and there is an advisory board or similar to represent the community. | Maturity level 3The governance is in the hands of a consortium or board that represents well the main stakeholders and user groups. | Maturity level 4Full community participation in the governance through mechanisms like elections and self governance. |
| Clear responsibilities Explanatory text |
Maturity level 1… | Maturity level 2… | Maturity level 3… | Maturity level 4… | |
| Reduced dependence on single supplier Check for example the Digital Autonomy Assessment Framework |
Maturity level 1The infrastructure uses mainly proprietary software. | Maturity level 2The infrastructure provides an API for most functionalities. | Maturity level 3It is possible to gradually migrate to another solution, e.g. adheres to open standards for integrations and data formats. | Maturity level 4A full exit plan has been developed and there is a number of realistic alternatives. | |
| Sustainable Keeping the lights on. |
Financially secure Explanatory text |
Maturity level 1There is no funding at the moment and for the foreseeable future. | Maturity level 2There is time-limited funding, e.g. through a one-off grant or donation. | Maturity level 3There is for a number of years funding, e.g. through memberships and recurrent grants. | Maturity level 4… |
| Human capacity available Explanatory text |
Maturity level 1No one is working on this infrastructure for a forseeable time. | Maturity level 2One hero is keeping the lights on, but there is no backup. | Somewhat staffed… | Dedicated resourcing… | |
| Legal and policy compliant Explanatory text |
Unknown… | Major gaps… | Bases covered… | Audited or certified… | |
| Resilient Explanatory text |
Falls over at the first breeze… | Major gaps… | Bases covered… | Can weather a hurricane… | |
| Institutionally embedded Explanatory text |
Maturity level 1… | Maturity level 2… | Maturity level 3… | Maturity level 4… | |
| Researcher centric Providing a good user experience and letting researchers achieve their goals. |
Interconnected Explanatory text |
Maturity level 1This infrastructure has non integrations with others, and makes it difficult to even exchange data. | Uses other systems… | Two-way connected… | Part of flourishing ecosystem… |
| Seamless user-experience Explanatory text |
Maturity level 1… | Maturity level 2… | Maturity level 3… | Maturity level 4… | |
| Accessible to all Explanatory text |
Maturity level 1… | Maturity level 2… | Maturity level 3… | Maturity level 4… | |
| Recognition and rewards Explanatory text |
Maturity level 1… | Maturity level 2… | Maturity level 3… | Maturity level 4… |
View as CSV · see data/README.md for provenance.
Every file behind the story above — as received or produced on the day, plus a converted copy of each (docx→md, xlsx→csv, pptx→pdf) for easier viewing. See data/consultation/README.md for the conversion notes.
