1. The Regulatory Framework

Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonized rules on fair access to and use of data, the Data Act, was published in the Official Journal of the European Union on 22 December 2023, entered into force on 11 January 2024, and applies in full from 12 September 2025 (Article 50). The regulation is directly applicable across all Member States; it does not require national transposition. Enforcement competence is allocated to one or more national competent authorities designated by each Member State under Article 37, with administrative fines up to €20 million or 4% of total worldwide annual turnover under Article 40 (mirroring GDPR enforcement scale).

The scope is unusually broad. Chapter II (Articles 4 to 12) creates a user right of access to data generated by connected products (IoT devices) and related services, and a corresponding obligation on data holders to make that data available to the user and, on the user's instruction, to third parties. Chapter III (Articles 13 to 22) regulates the contractual terms on which data is shared B2B, including a non-derogable list of unfair terms in Article 13. Chapter IV (Articles 14 to 22) creates a public-sector data-access regime for exceptional need. Chapter V (Articles 23 to 31) governs cloud and edge switching, requiring data-processing service providers to enable customer migration with progressively reduced and ultimately zero switching charges by January 2027.

The regulation interlocks with adjacent EU instruments. It complements the Data Governance Act (Regulation (EU) 2022/868) which governs data intermediation services and altruistic data sharing. It cross-references the GDPR for personal-data treatment, the EU AI Act (Regulation (EU) 2024/1689) for AI training data provenance, the NIS2 Directive (Directive (EU) 2022/2555) for security of data-sharing infrastructure, and the EU Cybersecurity Act for certification of trustworthy data-processing services. Compliance with one does not produce compliance with the others; each operates on the same underlying data flows from a different regulatory angle.

2. The Architectural Requirement

Stripped of the regulatory text, the Data Act requires a specific structural property: every unit of data covered by the regulation must be associated with a known authority chain identifying the data holder, the user (whose connected product generated the data), any third-party recipient acting on the user's instruction, and any further downstream recipient. The data must be made available on demand, with the request and the disclosure both being credentialed events that can be reconstructed. The terms on which data is shared must be enforceable structurally, not merely contractually, because Article 13 voids unfair terms by operation of law.

This shape implies four structural properties. First, observation provenance: every data unit carries a credential identifying its origin (the connected product, its sensor, its generating event). Second, authority taxonomy: the data holder, the user, and recipients each have credentialed identities under a published taxonomy that the substrate uses to evaluate disclosure authority. Third, governed actuation: the act of making data available is a graduated decision (disclose in full, disclose with redaction for trade-secret protection under Article 4(6), refuse with reason, defer pending verification) recorded in lineage. Fourth, cross-mesh reconciliation: data flows between data holders, users, recipients, and public-sector bodies pass between substrates operated by different parties without merging, through credentialed exchange.

The cloud-switching obligation in Chapter V adds a further requirement that is not a property of the data record itself but of the architecture that holds it: portability of governance state. When a customer switches data-processing service providers, the credentialed data-flow architecture must move with them. A customer cannot exercise switching rights if the provenance, authority, and lineage records are bound to the source provider's proprietary infrastructure. The Data Act effectively requires that governance state be a portable artifact, which is a structural requirement on the underlying architecture rather than a contractual obligation.

3. Why Procedural and Bolt-On Compliance Fails

The first compliance pattern data holders are reaching for is the data-request portal: a web interface where users can request access to their connected-product data, with backend reconciliation against contracts and trade-secret claims. This pattern fails the architectural requirement because the portal is a presentation layer over a data warehouse that has no structural notion of which records are user-generated under Article 4, which fall outside scope, which carry trade-secret protection under Article 4(6), and which involve third-party rights. The portal can produce data; it cannot produce the credentialed authority chain that the regulation actually requires.

The second pattern is contractual: data-sharing agreements that recite the Article 13 fairness criteria, attach data-use terms, and rely on contract law for enforcement. This fails because Article 13 voids unfair terms by operation of law, regardless of what the contract says, and because the regulation creates statutory rights (user access, third-party access on user instruction, public-sector exceptional access) that contracts cannot displace. A compliance posture that treats the obligation as contractual cannot detect when a data flow has crossed into a regime the contract does not govern.

The third pattern is the cloud-switching project: a one-time engineering effort to enable export of customer data on request. This fails because Chapter V requires functional equivalence after switching, with progressively reduced charges and an obligation under Article 25 to remove contractual, technical, and economic barriers. A switching project that produces a data dump leaves the customer with raw data and no governance state; the customer cannot reconstitute the authority chain at the destination provider, which means the customer cannot continue to comply with the Data Act after switching. The structural mismatch is that governance state is treated as provider-internal when it must be portable.

4. What The Governance-Chain Primitive Provides

The Governance Chain, disclosed in U.S. Provisional Application No. 64/049,409, is a five-property compliance substrate, and those five properties supply exactly the structural shape the Data Act requires. Property 1 (authority-credentialed observation) provides the data-origin credential: every unit of data generated by a connected product enters the substrate as a credentialed observation identifying the device, the sensor, the generating event, and the data holder's authority. Property 2 (evidential weighting) supplies the trade-secret and confidentiality weighting required by Article 4(6) and Article 5(8). Property 3 (composite admissibility evaluation) produces the graduated disclosure decision against the request authority and the regulatory regime in force.

Property 4 (governed actuator execution) is the act of making data available, full disclosure, redacted disclosure, deferred disclosure pending verification, refusal with structural reason. The actuation is reversible at the lineage level (the disclosure event is recorded, future requests can reconstruct what was disclosed, and the data holder can demonstrate the basis for each decision). Property 5 (lineage-recorded provenance) supplies the audit trail that competent authorities under Article 37 will demand: every request, every weighting, every disclosure decision, every actuation, every receiver's onward use is recorded with credentials and is reconstructable.

The recursive closure of the chain, every output re-entering as a credentialed observation, is what makes Data Act compliance tractable across the data ecosystem rather than only inside the data holder. When a third-party recipient receives data on the user's instruction, the recipient's onward use generates new observations that re-enter the chain through cross-mesh reconciliation. When a public-sector body receives data under Chapter IV exceptional-need provisions, the access event is recorded in the data holder's lineage and in the public-sector body's lineage, with structural reconciliation. The chain is what allows the regulation's downstream obligations (purpose-binding, onward-transfer limits, deletion obligations) to be structurally rather than contractually enforced.

For Chapter V switching, the governance-chain substrate is portable because the same provisional discloses a technology-neutrality and future-proofing doctrine: every primitive is claimed at the architectural level, independent of any specific physical-layer, communication-medium, sensing, actuation, or computing technology. The observation taxonomy, authority credentials, admissibility configurations, and lineage records are therefore expressed in technology-neutral form rather than bound to one provider's stack. The same provisional also discloses a customer-pull migration mechanism keyed to statutory data-portability rights and a cross-platform migration mechanism that operates without incumbent-vendor cooperation, which is exactly the posture Chapter V demands. A customer switching providers exports the substrate state and re-instantiates it at the destination, where the destination provider operates the same substrate over its own infrastructure. The customer's compliance posture survives the switch because the governance state is portable, and the migration itself is recorded in the deployment-lineage record so the switch event is itself auditable.

5. Compliance Mapping

Article 3 (design and accessibility of connected products) maps to authority-credentialed observation at the device level: data generated by the product enters the substrate as a credentialed observation by design. Article 4 (user right to access) maps to the request-handling element of governed actuation, with Article 4(6) trade-secret protection encoded in evidential weighting. Article 5 (user right to share with third parties) maps to the cross-mesh reconciliation property between the data holder's substrate and the third-party recipient's substrate, with the user's instruction as the credentialed authority for the transfer.

Articles 8 to 12 (FRAND data-sharing obligations on data holders) map to composite admissibility evaluating disclosure under fair, reasonable, and non-discriminatory criteria, with the criteria themselves encoded as published admissibility configurations. Article 13 (unfair terms) maps to the structural enforcement: terms that would produce admissibility outcomes inconsistent with the regulation are rejected by the substrate regardless of contractual recital. Article 14 to 22 (public-sector exceptional-need access) map to a credentialed regulator-authority class within the taxonomy that produces graduated admissibility outcomes specific to exceptional-need scope.

Articles 23 to 31 (switching of data-processing services) map to the disclosed technology-neutrality doctrine and the customer-pull and cross-platform migration mechanisms, with the substrate state itself as the switching artifact and the migration recorded in deployment lineage. Articles 32 to 34 (interoperability of data spaces and smart contracts) map to cross-mesh reconciliation between substrates operated by different data-space participants. Articles 36 to 40 (enforcement) map to the lineage-recorded provenance property: competent authorities audit the substrate's structural records, not the data holder's claims about its records.

6. Adoption Pathway

Adoption is led by the data holder, typically the manufacturer of a connected product or the operator of a related service, because the primary obligation falls on the data holder. Cloud and edge providers covered by Chapter V are the second adoption tier, because the switching obligations require portable governance state. Users (consumers and businesses owning connected products) are downstream beneficiaries and need not deploy the substrate, but third-party recipients acting on user instruction need to operate a compatible substrate to receive data with its governance state intact.

The transition path from current data-management posture is incremental but architectural. Existing data warehouses, telemetry pipelines, and consent-management platforms are not discarded; they become the source authorities that issue credentialed observations into the substrate. Existing data-sharing contracts are not voided; they become inputs to the admissibility configurations the substrate uses to evaluate disclosure decisions. By 12 September 2025 the substrate is the compliance object; the contracts, portals, and switching projects are documentation of the substrate rather than substitutes for it. National competent authorities under Article 37 will audit the substrate, and operators that have substitutes for the substrate will discover the audit cannot be passed structurally.

7. Disclosure Scope

This article is a freedom-to-operate and defensive publication. The underlying technology, the five-property governance chain (authority-credentialed observation, evidential weighting, composite admissibility evaluation, governed actuator execution, and lineage-recorded provenance, composed hierarchically with recursive closure), together with its cross-mesh reconciliation, incremental-deployment and migration, and technology-neutrality doctrines, is disclosed in U.S. Provisional Application No. 64/049,409. The EU Data Act (Regulation (EU) 2023/2854) and the adjacent EU instruments named here are cited as the regulatory regime that this disclosed architecture can be mapped onto for compliance purposes; they are not claimed as the inventive subject matter and are not commercial products of the applicant. References to regulatory articles, fines, and dates describe the regulation as enacted and are not representations of compliance coverage. This publication establishes a dated, enabling description of how the disclosed governance chain applies to mandatory connected-product data sharing and provider switching under the Data Act.