Why Updating One Law Becomes a Distributed-Systems Problem

Updating a legal document sounds like a content-management task.

A publisher receives a new version of an act, stores the document and makes it available to customers. If one section changes, we replace that section. If a new section is introduced, we add it.

The reality is considerably more difficult.

A legal-intelligence platform does not store legislation as a collection of independent files. It maintains a connected, time-sensitive body of knowledge in which:

one legal work can have many editions;
an edition contains a hierarchy of chapters, sections and paragraphs;
every node can have its own HTML content and metadata;
a table of contents represents the same hierarchy in another form;
provisions cite other provisions and publications;
commentary and news can be linked to an act, edition or individual provision;
relationships can cross publications, languages and jurisdictions.

A small legislative amendment can therefore affect much more than one piece of HTML.

The real business problem is:

How can a global legal-intelligence platform apply small, continuous changes without rebuilding entire editions or allowing content, structure and legal relationships to contradict one another?

Legal Content Is a Connected Model

Consider a simplified act:

Companies Act
├── Part 1 — Formation
│   ├── Section 1
│   └── Section 2
└── Part 2 — Governance
    ├── Section 10
    └── Section 11

This hierarchy appears in several representations:

The document graph records the legal entities and their relationships.
The HTML store contains the text presented to the reader.
The table of contents provides the navigational hierarchy.

The three representations describe the same edition, but they may be generated and stored by different systems.

If Section 10 is divided into Sections 10 and 10A, the platform must do more than store a new HTML fragment. It may need to:

create the new provision node;
update the parent-child hierarchy;
place the new section in the correct order;
generate its table-of-contents entry;
preserve the identity of the existing Section 10;
update citations or links affected by the structural change;
ensure commentary still points to the intended provision.

The document is therefore better understood as a versioned graph than as a file.

Changes Arrive Through Different Channels

The platform receives information from multiple vendor systems.

Legislation events arrive through IBM MQ.
Editorial events arrive through Microsoft Event Grid.

These systems have different message formats, delivery guarantees, identifiers and timing behaviour. They may describe different aspects of the same publication, and their events do not necessarily arrive together.

flowchart TD
    L["Legislation vendor<br/>IBM MQ"] --> P["Publication and edition"]
    E["Editorial vendor<br/>Event Grid"] --> P
    P --> H["HTML content"]
    P --> G["Document graph"]
    P --> T["TOC"]

Several small events may belong to one logical editorial operation. Events may also be duplicated, delayed or delivered out of order.

Treating every event as an instruction to reload an entire edition creates unnecessary work and makes consistency failures more likely.

The Cost of Full-Edition Ingestion

In the existing model, even a small change can trigger ingestion of a complete edition.

Suppose an edition contains 8,000 nodes and only one paragraph changes. Reprocessing all 8,000 nodes creates several problems:

unchanged HTML is read and written again;
graph nodes and relationships are unnecessarily recreated;
the TOC may be regenerated repeatedly;
downstream indexing and cache invalidation become much larger than the actual change;
processing time grows with edition size rather than change size;
retries repeat the complete workload;
concurrent updates are more likely to interfere with each other.

For large publications and frequent editorial updates, the amplification becomes substantial.

Actual business change:       1 paragraph
Current technical operation:  1 complete edition
Desired technical operation:  affected nodes and relationships only

The platform should accumulate related events, group them by publication and edition, determine what really changed and update only the affected nodes.

However, incremental processing introduces a harder question: how do we know when the edition is complete and internally consistent?

Three Views Must Tell the Same Story

The customer should never encounter a partially updated edition.

For example, the following state is unacceptable:

Representation	Visible state
HTML content	Contains new Section 10A
Document graph	Contains only Section 10
Table of contents	Links to Section 10A

The TOC Generator is a separate microservice, while the document metadata is stored in Neo4j and the HTML content is stored in a large-scale content platform. A failure or delay in any one of these paths can temporarily produce conflicting representations.

From the reader’s perspective, this can result in:

a TOC link that opens no content;
content that cannot be reached through navigation;
a provision with missing or incorrect metadata;
hierarchy traversal returning a different structure from the displayed TOC;
search results pointing to a node that is not yet published.

This is not only a technical inconvenience. Legal professionals rely on the platform to represent the law accurately. A structurally inconsistent edition can mislead users about what the law contains.

An Edition Is Not an Independent Island

Legal editions are connected to one another.

A new edition may supersede an earlier edition. A provision may be renumbered, amended, repealed or moved. Users may need to understand both the current text and the historical text that applied on a particular date.

flowchart LR
    E1["Edition 2024"] -->|"superseded by"| E2["Edition 2025"]
    E2 -->|"superseded by"| E3["Edition 2026"]
    C["Commentary"] -->|"explains"| E2
    N["News"] -->|"reports change"| E3

Replacing an old edition in place would destroy historical meaning. The system must preserve the distinction between:

the enduring legal work;
a specific edition of that work;
an individual provision across editions;
the text that was effective at a particular time.

A citation created in 2024 may need to continue pointing to the 2024 meaning of a provision, even after a 2026 amendment changes the current text.

Commentary and News Add Another Dimension

Legislation is only one part of a legal-intelligence product.

Editorial commentary may explain an entire act, a particular edition or one paragraph. News may describe an amendment before the consolidated edition is available. Guidance, judgments and related publications may refer to the same legal concepts.

These relationships have different meanings:

Commentary  ──ANNOTATES──▶ Provision
News        ─────ABOUT────▶ Legal work
Edition     ──SUPERSEDES──▶ Earlier edition
Provision  ─────CITES─────▶ Another provision
Judgment    ──INTERPRETS──▶ Legislation

The linked material may arrive before its target. For example, a news article can refer to legislation that has not yet been ingested, or commentary can cite a provision using an abbreviation that is ambiguous across jurisdictions.

The platform must retain unresolved relationships and revisit them when new legal material becomes available. It must not silently attach content to the wrong legal entity.

Citations Are Data, Not Just Text

A citation displayed inside HTML is also a relationship in the legal knowledge graph.

Resolving it requires more than detecting a number. The same textual pattern can mean different things depending on:

jurisdiction;
language;
document type;
issuing authority;
publication date;
effective date;
local citation conventions;
aliases and abbreviations;
historical renumbering.

For example, “Article 10” is not globally unique. It is not even necessarily unique within one country unless the referenced work is known.

A resolved citation must answer three questions:

Which legal work is being referenced?
Which provision within that work is intended?
Which edition or temporal interpretation applies?

When a provision changes, the platform must identify incoming citations and determine whether they remain valid. Reprocessing every document would be prohibitively expensive, but ignoring those dependencies would allow the knowledge graph to decay.

Global Scale Means Local Legal Rules

The platform is intended to operate across developed legal markets. The underlying business concepts are shared, but their representations are not.

Different countries use different:

publication authorities;
document identifiers;
hierarchy structures;
citation formats;
amendment mechanisms;
effective-date rules;
languages and scripts;
source-delivery technologies.

A scalable platform therefore cannot embed every national rule directly into its central ingestion workflow. It needs country and vendor adapters that translate local material into a canonical legal model.

The challenge is to keep the core model sufficiently consistent for global search and linking without erasing legally meaningful differences between jurisdictions.

The Business Risks

If this problem is handled poorly, the consequences extend beyond infrastructure cost.

Users may see provisions in the wrong order or follow links to missing content.

Broken historical research

Updating relationships in place can make old commentary or citations appear to refer to law that did not exist when they were written.

Loss of trust

A legal-intelligence product is valuable only if professionals can trust its content, structure and provenance.

Slow publication

Rebuilding complete editions delays the availability of legally significant updates.

Unbounded operating cost

Processing effort grows with the size of publications instead of the number of genuine changes.

Global expansion bottlenecks

Country-specific logic embedded in the core platform makes every new jurisdiction slower and riskier to onboard.

What the Platform Must Guarantee

Before choosing databases, brokers or cloud services, the business requirements should be explicit.

The platform must:

Accept legislation and editorial events from heterogeneous vendor systems.
Group related changes by publication and edition.
Detect node-level additions, modifications, moves and deletions.
Avoid rewriting unchanged parts of an edition.
Keep HTML, document hierarchy and TOC consistent for readers.
Preserve historical editions and temporal relationships.
Link commentary, news and other legal material to the correct entities.
Resolve citations using jurisdiction-aware rules.
Re-evaluate only relationships affected by a change.
Record provenance, confidence and unresolved references.
Support new countries through adapters rather than core-system rewrites.
Recover safely from duplicated, delayed and partially processed events.

These requirements reveal two different consistency expectations:

An edition’s content and internal structure must be complete before publication.
Links to the wider legal knowledge graph may be enriched asynchronously, but their status and provenance must remain visible.

The Architectural Question

The difficult part is not selecting Neo4j, DynamoDB, IBM MQ or Microsoft Event Grid.

The difficult part is defining the boundaries of a legal publication:

What must change together?
What can be resolved later?
Which identifiers remain stable across editions?
How do we preserve historical meaning?
How do we publish incremental changes without exposing partial state?

That leads to the central architectural question for the next part of this series:

How can we design an incremental, event-driven update process that publishes each legal edition consistently while resolving cross-document relationships at global scale?

The answer requires a canonical legal model, jurisdiction adapters, node-level change plans, versioned publication and a separate relationship-resolution process.

That architecture will be the subject of the next article.