Since the previous major revision, data spaces have moved from conceptual pilots to production environments. This shift has exposed ambiguities in governance, trust handling, and role interpretation that the Rulebook now addresses explicitly. The 2026-1 release is therefore less a reinvention than a structural correction, aligning principles, requirements, and practice into a more coherent system description.
Background: why an update was necessary
Several external developments motivated the revision. International standardization has progressed, most notably through ISO/IEC 20151 on data space concepts, providing a stable terminology and reference model. In parallel, open specifications and reference implementations have matured within the Eclipse Foundation, moving core building blocks from experimental to operational quality. Finally, real deployments have generated empirical feedback on governance models that scale and those that do not. The earlier Rulebook increasingly reflected an earlier phase of the ecosystem. Release 2026-1 updates this baseline and reconnects the document more explicitly to the IDSA Manifesto principles of participant autonomy, decentralization, and trust.
Decentralization as a default system property
One of the most consequential changes is the explicit treatment of decentralization as the default architectural assumption. The Rulebook now frames participant autonomy as a primary requirement, rather than an optional design preference. While alternative patterns are acknowledged, decentralized interaction models are positioned as the reference case against which deviations must be justified.
This clarification matters because decentralization affects identity management, policy enforcement, catalogues, and governance responsibilities. By making this assumption explicit, the Rulebook reduces interpretive flexibility that previously allowed centralized platforms to be labelled as data spaces without meeting the underlying intent.
Trust as a continuous, runtime concern
Another structural refinement concerns trust. Earlier interpretations often treated trust as a static onboarding decision. The new Rulebook reframes trust as a continuous, context-dependent process that must be evaluated and maintained during runtime. This includes clearer guidance on claims, policies, and mechanisms for reconciling them in concrete interactions. Trust is no longer implied by membership alone but is operationalized through verifiable behavior and enforceable agreements. For implementers, this shifts attention from certification events to ongoing monitoring and policy evaluation, with direct implications for connector design and governance processes.
Clear separation of mandatory and recommended requirements
Release 2026-1 introduces a more disciplined distinction between mandatory requirements and recommended practices. This separation provides governance bodies and implementers with unambiguous guidance on what is required for conformance and what remains discretionary. The absence of such clarity in earlier versions often led to over-engineering or inconsistent interpretations across data spaces. The revised structure supports proportional implementation, allowing organizations to priorities compliance efforts while still benefiting from best-practice guidance where appropriate.
Release 2026-1 maps more directly to ISO/IEC 20151, the Dataspace Protocol, the Decentralized Claims Protocol, and Eclipse Dataspace Components. This alignment reduces conceptual translation work for architects and developers and makes the Rulebook easier to integrate into existing design and compliance processes.
Functional requirements, not architecture
A deliberate clarification concerns scope. The Rulebook defines functional requirements for governance and participation, not architectural prescriptions. Architectural guidance remains the responsibility of the Reference Architecture Model (RAM). This distinction is reinforced in the 2026-1 release to avoid conflating governance obligations with technical design choices. For practitioners, this means the Rulebook should be used to frame decisions about roles, trust models, and obligations, while concrete system architectures are derived elsewhere. The separation preserves architectural flexibility without weakening normative consistency.
Forward-looking extensions: AI agents in data spaces
The inclusion of a dedicated chapter on AI agents signals an expansion of the Rulebook’s conceptual horizon. The chapter establishes initial requirements and considerations for autonomous or semi-autonomous actors participating in data spaces. This acknowledges emerging usage patterns where AI systems negotiate access, evaluate policies, or act on behalf of participants. By addressing this early, the Rulebook provides a foundation for future refinement without delaying current implementations.
Key takeaways for the data spaces community
The IDSA Rulebook 2026-1 delivers clarity of direction. Decentralization is treated as a default condition, trust as an operational process, and requirements as explicitly tiered. The document aligns more tightly with standards and tooling that organizations already use, while preserving a clear separation between governance requirements and architectural design. For working groups, implementers, and decision-makers, the Rulebook is best approached as a basis for concrete governance and participation decisions, supported by technical specifications elsewhere in the IDSA Knowledge Base. Used in this way, it provides a stable foundation for interoperable and trustworthy data spaces.
