Mapping Legal Regulation Text As a Citation Graph: DORA vs the Product Liability Directive

Mapping legal regulation text as a citation graph is one of the most powerful techniques available to compliance teams that must navigate the growing web of EU legislation. The method treats every Article, Recital, and Annex as a node and every explicit cross-reference, “pursuant to Article X”, “as referred to in Regulation (EU) Y”, as a directed edge, producing a visual and queryable map of how obligations interconnect.

When I applied this approach to two landmark EU instruments, the Product Liability Directive (Directive (EU) 2024/2853) and the Digital Operational Resilience Act (Regulation (EU) 2022/2554, “DORA”), the results were structurally striking: the PLD produces a monocentric graph with a single dominant hub Article, while DORA yields a polycentric graph with multiple high-degree nodes. In this article I set out the full legal mapping methodology, walk through both case studies, highlight the parser errors that most commonly mis-wire a legal citation graph, and provide a Romania-focused compliance checklist that technology and financial-services teams can act on immediately.

How to Read EU Legislation as a Citation Graph, the Legal Mapping Methodology

A legal citation graph converts the linear text of a statute into a network structure. At Olawru, we use this technique routinely to help Romanian technology clients identify the “load-bearing” provisions in new EU legislation, the Articles that, if misread, cascade errors across the entire compliance programme. The core methodology has three components: defining your node types, extracting your edges, and normalising the data so the graph is accurate and queryable.

Node Types and Normalisation Rules

Every structural unit of the legislative text becomes a potential node. In practice, the most useful node types are:

• Articles. The primary normative provisions. Each Article receives a unique identifier (e.g., PLD Art. 8 or DORA Art. 6).
• Recitals. Numbered paragraphs in the preamble that explain legislative intent. Mapping recitals to their corresponding normative provisions, a technique explored in depth by researchers at the University of Luxembourg, reveals which policy objectives drive which obligations.
• Annexes. Technical schedules that often contain the substantive detail behind a delegated-act reference.
• External instruments. References to other EU legislation (e.g., DORA citing the General Data Protection Regulation) create inter-legislative edges.

Normalisation matters because the same provision can appear in multiple surface forms. “Article 8(1)”, “Article 8, paragraph 1”, and “the first paragraph of Article 8” must all resolve to a single canonical node. Without normalisation rules, the graph fragments and compliance teams draw the wrong conclusions about which provisions are central.

Edge Extraction Rules, Explicit vs Implicit References

An edge exists whenever the text of one provision points to another. Explicit references are the backbone of the EU legislation citation graph: phrases such as “referred to in Article 6”, “in accordance with Article 31”, or “pursuant to Regulation (EU) 2022/2554” create unambiguous directed edges. Implicit references, for example, an Article that uses a defined term without citing the definition clause, are harder to capture automatically and usually require manual review. In my experience, an automated first pass followed by a manual validation layer is the most efficient workflow. A simple pattern-matching rule for explicit references might look like this (expressed in pseudo-regex):

Pattern: (Article|Articles)\s+\d+(\(\d+\))?(\s*,\s*\d+(\(\d+\))?)*

This captures single and comma-separated Article references. A second rule targets external instruments:

Pattern: (Regulation|Directive)\s+\(EU\)\s+(No\s+)?\d{4}/\d+

These two rules, properly applied, will extract the majority of edges in any EU legislative text, forming the basis of a workable legal citation graph.

Data and Tooling: Building a Validator and Avoiding Common Pitfalls

Extracting edges is only half the task. Every mapping legal regulation text as citation exercise must include a validation step, because parser errors legal references silently corrupt the graph. The most dangerous errors are those that create false edges (linking provisions that the legislator never intended to connect) or drop genuine edges (leaving compliance-critical cross-references invisible).

Example Parser Rules and Failing Cases

Two classes of parser error appear with disproportionate frequency in EU legislation:

• Pluralisation mismatch. The text may reference “Regulation (EU) 2022/2554” in one paragraph and “Regulations” (plural, referring to multiple instruments) in the next. A parser that matches only the singular form will miss multi-instrument references; one that matches only the plural may generate phantom edges to instruments not actually cited. Failing input: “…the Regulations referred to in paragraph 2 and in Regulation (EU) 2016/679…”, a naïve parser could treat “Regulations” as a standalone reference or conflate the two.
• Article-token splitting. OCR-rendered or HTML-converted texts sometimes insert line breaks, non-breaking spaces, or soft hyphens between “Article” and its number. The pattern Article\s+6 will not match Article 6 or Arti-\ncle 6. Failing input: a PDF-to-text conversion of DORA that splits “Article” across two lines, causing the validator to report zero inbound edges for Article 6, a provision that is, in reality, one of the regulation’s most-cited nodes.

Best Practices to Test and Validate

From what I am seeing in practice, the following safeguards materially reduce parser errors:

• Unit tests per Article. For each node in the graph, write at least one assertion confirming an expected inbound or outbound edge. If the test fails, inspect the raw text around the expected reference.
• Pin-cite enforcement. Require every compliance obligation in your internal register to carry an exact pin-cite (Article + paragraph + subparagraph). This forces the team to verify the source text against the graph.
• Dual-language check. Run the parser on both the English and Romanian language versions available on EUR-Lex. Structural discrepancies between language versions often reveal parsing artefacts rather than genuine legislative differences.

Case Study 1: The Product Liability Directive (Directive (EU) 2024/2853)

The Product Liability Directive, published as Directive (EU) 2024/2853, replaces the original 1985 product-liability regime and introduces a modernised framework covering software, AI-enabled products, and online platforms. When I constructed a legal citation graph from the final text, a monocentric pattern emerged clearly: Article 8, which sets out the conditions under which a product is deemed “defective” and the related presumptions, functions as the graph’s dominant hub. A disproportionate number of other provisions reference Article 8, either to trigger its presumptions, to carve out exceptions, or to define the burden of proof in relation to defectiveness.

This monocentric structure has a practical compliance implication: any team assessing its exposure under the PLD should begin with Article 8 and trace its edges outward. If your internal compliance register mis-parses or omits even one cross-reference to Article 8, the downstream analysis of defectiveness, burden of proof, and available defences is likely to be incomplete.

Beyond Article 8, the Directive introduces obligations for economic operators along the full supply chain, manufacturers, importers, authorised representatives, and, for the first time, providers of online platforms that allow direct sales to consumers. Article 7 defines the liable persons; Articles 9 and 10 govern the burden and alleviation of proof; and Article 11 addresses the right to disclosure of evidence. Each of these Articles contains explicit cross-references back to the definitions and presumptions anchored in Article 8, reinforcing its hub status.

Compliance Checklist for Romanian Product Teams

• Map Article 8 edges first. Identify every provision that references Article 8 and confirm that your compliance register captures the full chain of defectiveness presumptions.
• Audit your supply chain for “economic operator” coverage. Under Article 7, liability can attach to importers and platform operators, entities that may not have been in scope under the prior regime.
• Check transposition status. As a Directive, the PLD must be transposed into Romanian national law. Monitor the Romanian Parliament and the Ministry of Justice for the implementing legislation and any local adaptations.
• Prepare evidence-disclosure protocols. Article 11 grants claimants a right to request disclosure of evidence held by the economic operator. Romanian teams should review their document-retention and litigation-hold policies now.

Example Extracted Edges

The following cross-references illustrate Article 8’s hub role in the PLD citation graph:

• Article 9 → Article 8. The burden-of-proof provision references the defectiveness criteria in Article 8.
• Article 10 → Article 8. Alleviation of the burden of proof is conditioned on the presumptions established in Article 8.
• Article 7 → Article 8. Liability of economic operators is linked to placing a “defective” product on the market, as defined in Article 8.

Case Study 2: DORA (Regulation (EU) 2022/2554)

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies to financial entities, ICT third-party service providers, and critical ICT third-party service providers across the EU. Unlike the PLD, DORA produces a polycentric legal citation graph. When I parsed its cross-references, three Articles emerged as high-degree hubs, each anchoring a distinct cluster of obligations:

• Article 6, ICT risk management framework. This provision is referenced by Articles governing governance arrangements, incident reporting, and testing, making it the structural foundation of DORA’s risk-management obligations.
• Article 31, Designation of critical ICT third-party service providers. Multiple provisions on oversight, supervisory powers, and contractual arrangements point back to Article 31.
• Article 35, Powers of the Lead Overseer. This hub connects to the supervisory framework, information-sharing obligations, and enforcement mechanisms.

The polycentric pattern reflects DORA’s regulatory design: rather than channelling all obligations through a single definitional gateway (as the PLD does with “defectiveness”), the DORA regulation distributes authority across risk management, oversight, and supervision, each with its own self-contained cluster of cross-references.

DORA-Specific Mapping Considerations

DORA’s graph is more complex than the PLD’s for several reasons. First, the Regulation delegates substantial detail to Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the European Supervisory Authorities. These delegated acts create external-instrument edges that a PLD-only parser would not encounter. Second, DORA’s annexes, which list the types of financial entities in scope, are themselves referenced by multiple Articles, adding annex-to-article edges to the graph. Third, DORA cross-references other EU regulations (including the GDPR and the NIS 2 Directive), generating inter-legislative edges that must be tracked separately to avoid conflation.

Practical Impacts for Romanian Financial and ICT Service Providers

Because DORA is a Regulation, it applies directly in Romania without transposition. Romanian financial entities supervised by the National Bank of Romania (BNR) or the Financial Supervisory Authority (ASF) must comply with DORA’s ICT risk-management, incident-reporting, and third-party oversight requirements. In my advisory work, I have found that Romanian ICT service providers who contract with EU financial entities often underestimate the extent to which DORA’s Article 31 designation process can bring them within the direct oversight of European Supervisory Authorities, even if they are not themselves financial institutions.

Comparison Table: PLD vs DORA, Structural and Compliance Differences

The table below summarises the key structural and compliance differences that mapping legal regulation text as citation reveals between these two instruments:

Practical Validation Checklist and Quick Tests for Legal Ops

Once you have built your citation graph, the following five tests will catch the most common and highest-impact errors. I recommend running them in sequence after every parsing update or when a new consolidated version of the legislative text is published on EUR-Lex.

1. Article-to-article coverage check. Query every Article node in the graph and confirm it has at least one inbound or outbound edge. An Article with zero edges is either a standalone provision (rare in EU legislation) or a parsing failure. Sample query: “List all nodes with degree = 0.” Expected output: empty set, or a short list of genuinely standalone transitional provisions.
2. Missing-pin-cite report. Cross-reference your internal compliance register against the graph. Every obligation entry should carry a pin-cite that maps to an existing node. Flag any obligation that cites an Article not present in the graph.
3. Plural vs singular resolution. Search the raw text for all instances of “Regulation” and “Regulations” (and their Romanian equivalents, “Regulamentul” and “Regulamentele”). Confirm that each instance resolves to the correct external-instrument node. Sample query: “Return all edges where the target node is an external Regulation.” Expected output: a deduplicated list matching the instruments actually cited.
4. Cross-reference density heatmap. Generate a heatmap ranking Articles by total degree (inbound + outbound edges). Hub Articles should appear at the top. If a provision you know to be central (e.g., DORA Article 6) ranks low, inspect the parser output for that Article’s surrounding text.
5. Governance owner mapping. For each hub Article identified in the heatmap, assign an internal governance owner, the person or team responsible for monitoring that provision and all of its connected obligations. This step converts the graph from an analytical tool into an operational compliance asset.

How Romanian Teams Should Prioritise Remediation

In my advice to Romanian clients, I recommend a phased approach, a 7-day, 30-day, and 90-day roadmap, to move from raw citation graph to operational compliance monitoring.

• First 7 days, immediate triage. Identify the hub Articles for each in-scope instrument (Article 8 for PLD; Articles 6, 31, and 35 for DORA). Assign a governance owner to each hub. Run the five-test validation checklist above and fix any parsing errors that affect hub nodes. Escalation trigger: any hub Article with missing or phantom edges should be escalated to legal counsel immediately.
• Days 8–30, validator rule updates. Expand the parser to cover delegated acts, annexes, and external-instrument references. Add unit tests for pluralisation, line-break artefacts, and language-variant discrepancies. Re-run the graph build and compare the output against the 7-day baseline. Recommended owner: legal ops or regulatory-change management team.
• Days 31–90, integrated graph-based monitoring. Embed the citation graph in your compliance management system. Configure alerts for any change in EUR-Lex consolidated texts (corrigenda, delegated-act publications, or national transposition updates). At Olawru, we build these monitoring layers as part of our compliance-technology advisory, and in my view, this is where the graph approach delivers its greatest long-term value.

Conclusion: Why Mapping Legal Regulation Text as Citation Matters Now

The volume and interconnectedness of EU legislation citation is growing. Instruments like the Product Liability Directive and DORA do not exist in isolation, they reference each other, delegate to technical standards, and create cascading obligations that no linear reading can fully capture. Mapping legal regulation text as citation transforms compliance from a document-review exercise into a structured, testable, and auditable process. For Romanian technology and financial-services teams, the immediate next steps are clear: build the graph, validate it against EUR-Lex source texts, assign governance owners to hub Articles, and integrate the graph into your ongoing regulatory-change monitoring.

The methodology I have outlined in this article is the same one I apply in practice, and in my view, it is the most reliable way to ensure that no critical cross-reference is missed and no compliance obligation falls through the cracks.

Sources

1. EUR-Lex, Directive (EU) 2024/2853 (Product Liability Directive)
2. EUR-Lex, Regulation (EU) 2022/2554 (DORA)
3. University of Luxembourg, Jurix 2015: Mapping Recitals to Normative Provisions