OLRF
Part 4 From Vision to Practice

Chapter 18

The Standardisation Strategy

Last updated: 2026-04-10 Open for review

“Standards are the vocabulary of trust between strangers. Without them, every transaction begins with negotiation; with them, it begins with confidence.” Vint Cerf, Testimony before the United States House of Representatives Committee on Science, Space and Technology, 2012

Why Standardisation Is a Constitutional Act

The decision to submit the OLRF to international standardisation is not a technical decision. It is a constitutional one. Understanding why requires understanding what a standard does that a specification published by a single organisation, however credible, cannot.

A specification published by SPRIND, or by any national innovation agency, carries the authority of its publisher. It may be technically excellent. It may be constitutionally rigorous. It may be freely available and openly licensed. But it remains, in a formal sense, the product of a single institutional actor: an actor with its own interests, its own national context, and its own accountability framework. Jurisdictions asked to adopt it must trust not merely the specification’s technical quality but the ongoing governance of its evolution: that the organisation publishing it will not modify it in ways that serve narrow interests, will not abandon it when institutional priorities shift, and will maintain it at the level of quality that production deployment in public administration requires1.

International standardisation addresses each of these concerns structurally rather than by appeal to the trustworthiness of any particular institution. A standard adopted through a multi-stakeholder process is the product of governance that no single national body controls: one in which the interests of adopters from many jurisdictions, commercial sectors, and civil society traditions are represented, in which changes require multi-stakeholder consensus, and in which the standard’s evolution is governed by procedures that are themselves standardised and publicly known. The resulting standard carries a form of institutional authority that no single publisher can confer: the authority of a process that was designed to be resistant to capture by any particular interest.

For the OLRF, this institutional authority matters for a reason that goes beyond the usual arguments for open standards in public procurement. The OLRF is designed to be the publication infrastructure for machine-executable law: the channel through which the sovereign authority of democratic legislatures is expressed in operational form. An infrastructure of this kind, deployed at continental scale across jurisdictions with distinct legal traditions, distinct institutional arrangements, and distinct democratic accountability frameworks, cannot rest on the authority of a single national innovation programme. It must rest on a governance framework that is as international, as neutral, and as multi-stakeholder as the legal orders it serves2.

International standardisation is, in this sense, the institutional completion of the OLRF’s constitutional design: the mechanism through which an architecture designed to be sovereign infrastructure for democratic governance achieves the international legitimacy that such infrastructure requires.

The Definition: Law as Code

Before the standardisation strategy can proceed, the term at its centre must be defined with precision. The language around the digital provision of law is cluttered with overlapping terms: Rules as Code, Law as Code, machine-readable law, computable law, digital legislation, automated regulation. These terms are used inconsistently across projects, jurisdictions, and academic traditions. A standardisation process that does not begin by defining its subject matter will produce a standard whose scope is contested before its content is reviewed.

The OLRF adopts the following definition.

Law as Code is the structured, authoritative, machine-executable provision of law.

It is a specification of how normative content (including conditions, legal consequences, exceptions, parameters, and defined discretion points) is represented in a formally defined structure that digital systems can execute. The definition has four elements, each of which does constitutional work3.

Structured means that the representation follows a formally defined format with explicit semantics. Natural language text that happens to be stored digitally is not Law as Code. A PDF of a statute is machine-readable but not machine-executable. Law as Code requires a formal structure that a system can evaluate, not merely display.

Authoritative means that the representation is published by or under the authority of the institution responsible for the norm’s application. A third-party interpretation of a statute, however accurate, is not Law as Code in the sense relevant to the OLRF. Authoritativeness is what distinguishes the OLRF from general-purpose legal informatics: the Decision Tree published in the Registry is not a commentary on the law. It is the operative specification through which the law is applied.

Machine-executable means that the representation can be evaluated by a conformant system to produce a legally consequential determination. Machine-readability (the ability of a system to parse the content) is necessary but not sufficient. Machine-executability requires that the parsed content can be evaluated against facts to produce effects: the benefit is granted, the licence is refused, the tax is assessed.

Provision of law means that the representation concerns enacted law, not policy guidance, best practice, or contractual terms. Law as Code operates in the domain of binding normative authority. It is the executable form of what the legislature has enacted, not a recommendation about what an authority might consider.

This definition distinguishes Law as Code from the broader category of Rules as Code, which encompasses any structured representation of rules for machine processing (including internal policies, contractual terms, and non-binding guidance). The OLRF operates in the Law as Code domain. Rules as Code projects that do not involve enacted law may still benefit from the OLRF’s infrastructure (the Connector Pattern described in Chapter 17 does not require that the connected system operate on enacted law), but the OLRF’s constitutional argument and its standardisation ambition are anchored in the provision of law, not in the provision of rules generally4.

The definition also distinguishes Law as Code from artificial intelligence. Law as Code, as the OLRF defines it, does not create norms, does not modify normative content, does not replace judicial interpretation or administrative discretion, and is explicitly distinct from AI systems that rely on probabilistic inference. AI systems may assist in the provision of law (as described in the three-model framework), but Law as Code is the normative substrate on which AI systems operate, not the AI systems themselves. This distinction is constitutionally essential. It is the reason why the Decision Tree is deterministic, why the evaluation engine is separated from the AI layer, and why the three models are defined by their relationship to the Decision Tree rather than by their use of AI as such.

The Layered Governance Model

A foundational lesson of two decades of digital infrastructure standardisation is that no single standardisation organisation is adequate for a specification of the OLRF’s architectural complexity. The OLRF operates simultaneously as a legal document standard, an internet protocol, a cryptographic credential infrastructure, an agent certification framework, and an open-source software ecosystem. Each of these dimensions has a different natural standardisation home, a different community of expertise, and a different relationship to the deployment environments it must serve. Concentrating the entire standardisation effort in a single organisation, however prestigious, would mean either accepting the slowest organisation’s timeline for all components, or accepting the narrowest organisation’s community of expertise for all dimensions. Neither is acceptable for an architecture whose constitutional ambitions require both technical rigour and deployment speed5.

The OLRF’s standardisation strategy therefore adopts a layered governance model: each component of the architecture is governed by the organisation best suited to its technical domain and its deployment community, with formal interoperability specifications ensuring that the layers function as a coherent whole. Six organisations, each with a distinct role, together provide the governance architecture that the OLRF requires.

Layer 1: ISO/IEC JTC 1 --- The Normative Core

ISO/IEC JTC 1 is the appropriate venue for the OLRF’s normative core specification: the format of Decision Trees, the structure of the Registry, the Coverage Map’s six classifications, the conformance requirements that define the three classes, the agent certification framework, and the constitutional principles that govern the separation of AI from deterministic legal evaluation.

This is not a concession to tradition. It reflects a genuine constitutional requirement. The machine-executable form of public law requires the institutional authority that only a formally constituted international standards body with national body representation can provide. An ISO/IEC standard is recognised in public procurement law across EU member states and OECD countries in a way that no other publication is. For the component of the OLRF that is most directly an exercise of sovereign authority (the specification of how enacted law is represented in executable form) this institutional recognition is not a bureaucratic nicety. It is the technical form of democratic legitimacy6.

The submission proceeds through JTC 1 Subcommittee 34, which governs LegalDocML (Akoma Ntoso) and related legal document standards, and Subcommittee 38, which governs standards relevant to the Registry’s federated architecture. The OLRF’s relationship to LegalDocML is complementary: LegalDocML standardises the representation of legal text (the legislative source), while the OLRF standardises the representation of the executable specification derived from that text (the Decision Tree and its sub-normative linkage to the LegalDocML source). Together, they form a complete chain from enacted text to executable specification.

The ISO/IEC timeline is the longest in the layered model (typically three to five years from initial submission to published standard). This is acceptable for the normative core, because the core specification must be stable before it is formally standardised: premature ISO submission of a specification that is still evolving would produce a standard that is outdated before publication. The OLRF’s approach is therefore to submit to ISO/IEC JTC 1 only after the specification has been stabilised through the multi-stakeholder review process described in Phase 1 of the roadmap (Chapter 16) and validated through pioneer implementations. The ISO submission arrives at the formal process not as a proposal seeking validation, but as an architecture whose international review and operational testing have already established its credibility7.

Layer 2: IETF --- The Protocol Layer

The Internet Engineering Task Force is the appropriate venue for the OLRF’s protocol layer: the Registry API specification, the MCP interface profile for legal evaluation, the A2A coordination protocol adaptations for legal workflows, and the data format standards on which the architecture rests.

The IETF already governs several standards that the OLRF directly relies on: RFC 8785 (JSON Canonicalization Scheme, used for cryptographic hash computation), RFC 8259 (JSON Data Interchange Format), and the TLS standards that underpin the Registry’s transport security. The IETF’s process (“rough consensus and running code”) is the antithesis of ISO’s multi-year ballot procedures: it is fast, openly participatory without membership fees or national body gatekeeping, and its outputs carry deep credibility in exactly the developer and infrastructure communities that will build OLRF-conformant systems. An IETF RFC specifying the OLRF Registry API would be read and implemented by the engineers building evaluation engines, AI agent frameworks, and cross-jurisdictional coordination infrastructure in a way that an ISO document alone would not be8.

The IETF pathway also provides a governance model that is structurally resistant to commercial capture. No company can block an IETF RFC, and the working group process ensures that the interests of implementers, not just specifiers, shape the final document. IETF engagement begins during the foundational phase of the roadmap, with the submission of individual Internet-Drafts for the Registry API and the MCP legal profile, building the working group relationships that a formal RFC process requires.

The specific IETF deliverables are: an RFC for the OLRF Registry API (discovery, publication, query, version management, federation protocol), an RFC for the MCP legal evaluation profile (the five tools, the security model, the certification verification at Control 5), an RFC for the Decision Package format (the canonical serialisation, the signing model, the explanation register structure), and an RFC for the A2A legal coordination protocol (task delegation, capability attestation, certification verification, composite audit trail assembly).

Layer 3: OpenID Foundation --- The Credential Layer

The OpenID Foundation is the appropriate venue for the OLRF’s credential and authentication layer: the specification of how AI agents authenticate to the Registry and interface server, how human officials authenticate for Discretion Point escalations, how agent certification credentials are issued and verified, and how cross-border credential recognition operates within the federated Registry network.

The OpenID Foundation is not an alternative to the other organisations. It is the organisation that has already solved, in the context of the European Digital Identity Wallet (EUDI Wallet), the specific credential infrastructure problems that the OLRF’s authentication requirements present. The OpenID for Verifiable Credentials (OID4VC) family of specifications (OID4VCI for credential issuance, OID4VP for credential presentation, and SIOPv2 for self-issued identity) provides the technical foundation for the OLRF’s agent certification credential: a verifiable, revocable, domain-specific credential that an agent presents to the interface server at Control 5, and that the server can verify against the Registry without requiring a direct connection to the issuing certifying body9.

The OLRF’s credential requirements extend the OpenID Foundation’s existing work in one constitutionally significant direction: the agent certification credential must express not merely identity (who the agent is) but qualification (what the agent is certified to do, in which normative domain, under which model, for which version). This is a credential type that the current OpenID specifications do not explicitly address, because it arises from the specific requirements of normative AI systems rather than from the general requirements of digital identity. The OLRF’s contribution to the OpenID Foundation is the specification of this credential type: a machine-readable, cryptographically verifiable, domain-specific, model-specific, version-bound qualification credential for AI agents operating in legally consequential environments.

Layer 4: W3C and OASIS --- The Semantic Layer

The World Wide Web Consortium and OASIS provide the standards ecosystem for the OLRF’s semantic infrastructure: the linkage between OLRF Decision Trees and LegalDocML sources (building on Akoma Ntoso, an OASIS standard), the RDF and linked data infrastructure for the Registry’s semantic layer (building on W3C standards), and the accessibility standards that govern the citizen-facing explanation layer.

The W3C and OASIS are not governance venues for new OLRF-specific standards. They are the custodians of existing standards on which the OLRF builds. The OLRF’s engagement with them is therefore different from its engagement with ISO/IEC or IETF. It is not submission of new specifications for standardisation. It is active participation in the communities whose standards the OLRF depends on, ensuring that the OLRF’s requirements are understood and, where necessary, that the existing standards are extended to accommodate them. The most significant such extension is the linkage between LegalDocML and the OLRF Decision Tree: the sub-normative anchor types described in Chapter 6 require a formal vocabulary for expressing the relationship between an element of executable logic and a specific passage of legal text. This vocabulary must be interoperable with Akoma Ntoso’s existing reference structure. The W3C/OASIS engagement ensures that this interoperability is achieved through collaboration with the LegalDocML community rather than through unilateral specification10.

Layer 5: Linux Foundation Europe --- The Implementation Layer

Linux Foundation Europe is the appropriate governance home for the OLRF’s open-source reference implementations, the translation libraries described in Chapter 17 (RUML, OpenFisca, RegelSpraak, Catala), the conformance test suites, the agent certification test infrastructure, and the collaborative development process through which the implementation ecosystem grows.

The Linux Foundation provides a governance model that is specifically designed for open-source projects that serve public infrastructure. Its charter-based governance, its intellectual property frameworks, and its experience with large-scale, multi-stakeholder open-source projects (including the Linux kernel itself, Kubernetes, and Hyperledger) provide the institutional stability that a sovereign infrastructure project requires. Linux Foundation Europe, specifically, adds the European institutional context that the OLRF’s adoption environment demands: proximity to European public sector adopters, familiarity with European procurement and data sovereignty requirements, and alignment with the European open-source strategy11.

The Linux Foundation Europe project is established during Phase 1 of the roadmap, providing the governance home for reference implementations that are developed in parallel with the formal standardisation processes. This parallelism is deliberate. It ensures that the formal standards (ISO/IEC, IETF, OpenID) are informed by implementation experience from the outset, and that the reference implementations evolve in response to the standards process rather than diverging from it.

The specific deliverables under the Linux Foundation Europe governance are: the Registry reference implementation, the evaluation engine reference implementation, the Decision Tree authoring tool (integrating the RUML translation layer as the analytical front-end), the Coverage Map generator, the agent certification test infrastructure, the translation libraries for existing formats, and the MCP-conformant fact-finding agent library that provides open-source building blocks for the AI fact-finding market described in Chapter 19.

Layer 6: Domain-Specific Standards Bodies --- The Vertical Layer

The five layers described above govern the horizontal infrastructure: the components that are common across all normative domains and all jurisdictions. But the OLRF also requires vertical standardisation in specific legal domains: the DataPoint Schemas for specific norm types (social welfare, taxation, licensing, enforcement), the test suites for specific normative domains, and the agent certification requirements for specific areas of law.

These vertical standards cannot be developed by the horizontal organisations, because they require domain-specific legal expertise that no horizontal standards body possesses. They must be developed by the communities that know the relevant law: tax administrations for tax DataPoint Schemas, social welfare authorities for benefit DataPoint Schemas, licensing bodies for licensing test suites. The OLRF’s standardisation strategy accommodates this through a framework of domain-specific working groups, coordinated through the Linux Foundation Europe project but drawing their expertise from the relevant administrative communities. Each working group produces domain-specific standards that conform to the horizontal specification (the DataPoint Schema must conform to the OLRF’s schema format, the test suite must use the OLRF’s test categories) but whose substantive content is determined by the domain experts12.

This vertical layer is where the ecosystem connection strategy of Chapter 17 intersects most directly with the standardisation strategy. The existing projects (OpenFisca, RegelSpraak, Catala, PolicyEngine, Rulemapping) have already developed deep domain expertise in specific legal areas. Their participation in the domain-specific working groups brings that expertise into the standardisation process, ensuring that the vertical standards reflect operational experience rather than abstract specification. An OpenFisca community that has modelled the French tax system for a decade brings irreplaceable domain knowledge to the development of a tax DataPoint Schema standard. A RegelSpraak community that has operated Dutch tax specifications in production brings irreplaceable operational knowledge to the development of a test suite standard for tax norms. The OLRF does not need to recreate this expertise. It needs to create the governance framework through which it is contributed, integrated, and standardised.

Sequencing: The Order in Which It Happens

The sequencing of the six governance relationships is as important as their selection. The wrong sequence produces dependencies that block progress; the right sequence produces momentum that accelerates it.

The OpenID Foundation credential layer specification begins first, because it is a prerequisite for all other layers. The agent certification credential must be specified before the IETF can finalise the MCP legal profile (which verifies the credential at Control 5), before the Linux Foundation Europe project can build the certification test infrastructure (which issues the credential), and before the ISO/IEC core specification can define the conformance requirements for agent certification (which reference the credential format)13.

The IETF protocol specifications develop in parallel with the foundational phase of the roadmap, building working group relationships while the normative architecture is refined. The Internet-Drafts for the Registry API and the MCP legal profile are submitted during Phase 1, providing the implementation community with stable protocol specifications well before the ISO/IEC core specification is finalised. This ensures that the developer community can begin building conformant systems on the basis of IETF specifications, without waiting for the slower ISO/IEC process to complete.

The Linux Foundation Europe project is established during Phase 1, providing the governance home for reference implementations that are developed in parallel with the formal standardisation processes. The reference implementations serve a dual function: they validate the IETF protocol specifications through running code, and they provide the implementation evidence that the ISO/IEC submission requires.

The W3C and OASIS engagement proceeds throughout, as the communities whose standards the OLRF builds on are kept informed and involved at every stage. The LegalDocML/Akoma Ntoso linkage specification is developed collaboratively with the OASIS LegalDocML Technical Committee, ensuring interoperability from the outset.

The domain-specific working groups are established during Phase 2, once the horizontal infrastructure is stable enough to provide the framework within which domain-specific standards are developed.

The ISO/IEC JTC 1 submission comes last in the sequence: after the multi-stakeholder review process has produced a stable version 1.0, after the IETF protocol specifications have demonstrated implementability through running code, after the Linux Foundation Europe reference implementation has demonstrated that the architecture works in practice, and after pioneer implementations have validated the specification in operational environments. The ISO submission thus arrives at the formal process not as a proposal seeking validation, but as an architecture whose international review, protocol standardisation, reference implementation, and operational testing have already established its credibility14.

This sequencing is the OLRF’s answer to the criticism that traditional standardisation organisations are too slow for the AI age. By running the implementation and protocol standardisation in parallel with (rather than after) the formal normative standardisation, the OLRF ensures that version 1.0 enters the ISO process already proven rather than merely proposed. The formal standard, when it arrives, ratifies what the ecosystem has already built rather than initiating what has yet to be attempted.

Governance Safeguards

The standardisation strategy rests on three governance safeguards that protect the OLRF’s constitutional commitments against the risks inherent in any standardisation process15.

Copyleft licensing for the core specification ensures that extensions or derivative forms of the core specification, when distributed for production use, cannot be taken private while continuing to shape the public infrastructure on which others depend. Commercial actors remain free to build services, engines, tooling, and operational offerings around the open core. What they cannot do is alter the core specification and convert those alterations into proprietary control points that others must accept in order to remain interoperable. Competition is therefore directed toward implementation quality, service reliability, performance, and value-added capabilities, rather than toward private ownership of the normative substrate itself.

Multi-stakeholder governance for the specification’s evolution ensures that the standard cannot evolve solely according to the interests of its most powerful adopters. Public authorities, smaller jurisdictions, civil society, academia, and commercial actors must all have a place in its development, and in a form that prevents any one category of participant from shaping the standard to its own structural advantage. The governance procedures through which the standard evolves must be publicly answerable rather than commercially steered. This safeguard is enforced through the governance structures of each standardisation organisation: ISO/IEC’s national body representation, IETF’s open participation, the OpenID Foundation’s working group model, and the Linux Foundation Europe’s charter-based governance all provide structural protections against single-actor capture16.

Extension neutrality as an architectural requirement for conformance ensures that proprietary additions cannot become operationally indispensable even where the core remains formally open. The principle is simple. A conformant implementation of the core specification must remain independently functional and interoperable without requiring proprietary additions. A public authority that expresses its executable norms in the OLRF core should be able to move between conformant vendors, preserve access to its Registry history, and continue operating its legal artefacts without rewriting them into a platform-specific format. That is the technical expression of sovereign freedom of action. It means that the state’s normative layer is not held hostage by any single commercial relationship17.

The Relationship Between Standardisation and Sovereignty

The standardisation strategy and the sovereignty argument of Chapter 14 are not separate concerns. They are two expressions of the same constitutional commitment.

A standard that is governed by a single commercial actor, even if technically open, creates a dependency. A standard that is governed by a multi-stakeholder process, with copyleft licensing, extension neutrality, and transparent governance, creates a commons. The difference matters constitutionally, because the infrastructure through which democratic legislatures express their law in executable form must be a commons, not a dependency.

The layered governance model ensures that no single organisation, no single jurisdiction, and no single commercial interest controls the OLRF’s evolution. ISO/IEC provides formal international legitimacy. IETF provides protocol credibility with the developer community. OpenID provides credential interoperability with the European digital identity infrastructure. W3C and OASIS provide semantic interoperability with the legal document standards ecosystem. Linux Foundation Europe provides open-source governance for the implementation layer. Domain-specific working groups provide legal expertise for the vertical standards. Together, they form a governance architecture that is as federated, as multi-stakeholder, and as resistant to capture as the Registry architecture that the OLRF specifies for the normative layer itself.

That is not a coincidence. The governance of the standard must mirror the governance of the infrastructure the standard describes. A standard for sovereign legal infrastructure must itself be sovereignly governed. The layered governance model is the OLRF’s attempt to achieve that symmetry18.

Footnotes

  1. The institutional trust problem in standard adoption is analysed in: Russell, A., Open Standards and the Digital Age: History, Ideology and Networks, Cambridge University Press 2014, pp. 8 ff. (demonstrating that the adoption of technical standards depends on the perceived neutrality and durability of the governance process, not merely on the technical quality of the specification). ↩

  2. European Commission, “Shaping Europe’s Digital Future”, COM(2020) 67 final, pp. 4 ff. (identifying sovereign digital infrastructure as essential to European strategic autonomy and positioning open standards as the institutional mechanism through which sovereignty is secured without autarky). ↩

  3. The definition builds on: OECD, “Cracking the Code: Rulemaking for Humans and Machines”, OECD Working Papers on Public Governance, No. 42 (Mohun, J. and Roberts, A.), 2020, which provides the most comprehensive international survey of Rules-as-Code and Law-as-Code initiatives. The OECD report uses “Rules as Code” as the umbrella term. The OLRF’s narrower definition of “Law as Code” distinguishes the provision of enacted law (the OLRF’s domain) from the broader provision of rules generally. ↩

  4. The distinction between Law as Code and Rules as Code is not merely terminological. It carries constitutional implications. Rules as Code may involve contractual terms, internal policies, or non-binding guidance, none of which engage the constitutional requirements (promulgation, equal treatment, reason-giving, judicial reviewability) that Part III of this paper has established. Law as Code, because it involves the provision of enacted law, engages all of them. The OLRF’s standardisation ambition is anchored in Law as Code precisely because the constitutional case is strongest and the institutional need most urgent in the domain of binding normative authority. ↩

  5. The principle that complex infrastructure standards require layered governance across multiple organisations is well established. The Internet itself is governed through a layered model: IETF for protocols, W3C for web standards, ICANN for naming and numbering, IEEE for physical layer standards. See: DeNardis, L., The Global War for Internet Governance, Yale University Press 2014, pp. 45 ff. ↩

  6. ISO/IEC JTC 1, Directives, Part 1: Procedures for the technical work, 18th edition, 2023. For the recognition of ISO/IEC standards in EU public procurement: Regulation (EU) 2024/903 (Interoperable Europe Act), Art. 13 (preference for open standards in public sector digital interoperability). An ISO/IEC standard for the OLRF’s normative core would benefit from this procurement preference across all EU Member States. ↩

  7. The risk of premature ISO submission is well documented. Standards that enter the ISO process before their specification is stable tend to produce either a standard that is outdated upon publication (because the specification has evolved during the three-to-five-year process) or a standard that freezes a premature design (because the ISO process is too slow to accommodate the revisions that implementation experience reveals). See: Egyedi, T. M. and Blind, K. (eds.), The Dynamics of Standards, Edward Elgar 2008, pp. 89 ff. ↩

  8. Clark, D., “A Cloudy Crystal Ball: Visions of the Future”, Proceedings of the 24th Internet Engineering Task Force, 1992 (the foundational articulation of “rough consensus and running code” as the IETF’s governance principle). For the IETF’s structural resistance to commercial capture: Hoffman, P., “The Tao of IETF”, RFC 4677, 2006. ↩

  9. OpenID Foundation, “OpenID for Verifiable Credentials” (OID4VC) specification family: OID4VCI (credential issuance), OID4VP (credential presentation), SIOPv2 (self-issued OpenID provider). For the European Digital Identity Wallet context: European Commission, “European Digital Identity Architecture and Reference Framework (ARF)”, Version 1.4, 2024. The EUDI Wallet’s credential infrastructure is based on the OID4VC specifications, which makes the OLRF’s adoption of the same credential framework architecturally consistent with the European digital identity ecosystem. ↩

  10. OASIS, “Akoma Ntoso Version 1.0”, OASIS Standard, 2018 (the international standard for the representation of parliamentary, legislative, and judicial documents in XML). The OLRF’s sub-normative linkage (Chapter 6) references specific elements of Akoma Ntoso documents through typed anchors (derived_from, constrained_by, delegated_by, exception_from, defined_in). The interoperability between these anchor types and Akoma Ntoso’s reference structure must be formally specified to ensure that the linkage is not merely OLRF-internal but interoperable with any system that processes LegalDocML documents. ↩

  11. Linux Foundation Europe, “Charter and Governance Framework”, 2022. For the broader argument that open-source governance is essential for sovereign digital infrastructure: European Commission, “Open Source Software Strategy 2020-2023: Think Open”, COM(2020) 7149; Blind, K., “The Impact of Open Source Software on Competition, Innovation and the Digital Economy”, European Commission DG CONNECT, 2021. ↩

  12. The domain-specific working group model follows the pattern established by HL7 FHIR in healthcare informatics, where a common infrastructure standard (FHIR resources) is extended by domain-specific implementation guides developed by clinical communities. See: Bender, D. and Sartipi, K., “HL7 FHIR: An Agile and RESTful Approach to Healthcare Information Exchange”, Proceedings of IEEE CBMS, 2013, pp. 326 ff. The OLRF applies the same pattern to legal informatics: a common infrastructure (Decision Tree format, Registry, Coverage Map) extended by domain-specific standards (DataPoint Schemas, test suites, certification requirements) developed by legal domain communities. ↩

  13. The dependency analysis that determines the sequencing follows the critical-path methodology: each layer must be sequenced so that its prerequisites are available when needed and its outputs are available for the layers that depend on them. The agent certification credential is the critical-path item because it is referenced by the MCP legal profile (IETF), the certification test infrastructure (Linux Foundation Europe), and the conformance requirements (ISO/IEC). Without a stable credential specification, none of these downstream deliverables can be finalised. ↩

  14. The principle of submitting proven architectures to formal standardisation, rather than submitting proposals for validation, follows the successful pattern of HTTP (specified in IETF RFCs on the basis of a working implementation) and PDF (submitted to ISO after Adobe had demonstrated the format’s adequacy through decades of production use). See: Berners-Lee, T. et al., “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, 1998 (standardising an architecture already in global production use); ISO 32000-1:2008 (standardising PDF on the basis of Adobe’s existing specification and global deployment). ↩

  15. The three governance safeguards (copyleft, multi-stakeholder governance, extension neutrality) correspond to Ostrom’s design principles for long-enduring commons institutions: clearly defined boundaries, collective-choice arrangements, and conflict-resolution mechanisms. See: Ostrom, E., Governing the Commons: The Evolution of Institutions for Collective Action, Cambridge University Press 1990, pp. 90 ff. ↩

  16. The risk of commercial capture in standards governance is well documented: Simcoe, T., “Standard Setting Committees: Consensus Governance for Shared Technology Platforms”, The American Economic Review, Vol. 102, No. 1, 2012, pp. 305 ff. (demonstrating that standards committees can be captured by firms with disproportionate participation). The OLRF’s multi-organisation governance model mitigates this risk by distributing governance across organisations with different participation structures and different constituencies. ↩

  17. The extension neutrality requirement is the OLRF’s defence against the “embrace, extend, extinguish” pattern documented in technology history. See: Simcoe, T. and Watson, J., “Forking, Fragmentation, and Splintering”, Strategy Science, Vol. 4, No. 4, 2019, pp. 283 ff. For the specific risk in the normative domain: a Decision Tree format that remained nominally open while being functionally captured by proprietary evaluation semantics, anchor schemes, or Registry interfaces would reproduce the very dependency the OLRF is intended to prevent. ↩

  18. The proposition that the governance of a standard must mirror the governance of the infrastructure it describes is a specific application of the constitutional principle that the institutions through which public power is exercised must themselves be subject to democratic accountability. See: Bogdandy, A. von, “Founding Principles”, in Bogdandy, A. von and Bast, J. (eds.), Principles of European Constitutional Law, Hart Publishing 2009, pp. 11 ff. The OLRF applies this principle to technical governance: a standard for sovereign legal infrastructure must be governed by a process that is as federated, multi-stakeholder, and transparent as the infrastructure itself. ↩