Why Law Is Law-Shaped

I. The Structural Constraint

Law is an incrementally maintained system authored by distributed agents with partial authority over time, requiring stable fine-grained addresses for external reference.

This structure holds across civil law, common law, and hybrid systems. The surface differs — statutes vs. acts, articles vs. sections, codified vs. uncodified — but the structural constraint is the same. Every element of the definition is load-bearing:

Incrementally maintained: Parliament cannot restate the entire legal corpus each session. Amendments modify specific provisions of existing statutes. The legal state at any moment is the accumulated result of thousands of incremental patches applied over decades or centuries.Distributed agents with partial authority: Different parliaments, at different times, with different mandates, enacted different provisions. A subsection added in 2021 coexists with a section from 1995 and a chapter structure from 1972. Each retains its own authority provenance. The current text of a statute is a palimpsest of multiple authors across time.Stable fine-grained addresses: Other laws say “pursuant to Section 12(2) of Act X.” Court decisions cite specific provisions. Contracts reference them. These are external pointers into the legal corpus. If addresses change, external references break silently. The addressing scheme must survive amendments — which is why law uses hierarchical structural paths rather than page numbers or byte offsets.

Software codebases evolved the same structural constraint for the same reason: incremental modification, multiple authors, stable external references (API contracts, imports, URLs). The resemblance between git blame and statutory provenance tracing is convergent evolution from identical structural pressure.

II. The Tree Is a Serialization Format

Statutes are organized as trees: parts contain chapters, chapters contain sections, sections contain subsections. This hierarchy exists because paper is linear — a statute must be printed as a sequence of pages, and the hierarchy provides navigable structure.

But law does not operate as a tree:

• Section 12 says “as defined in Section 4” — a cross-reference, a pointer from one node to another, often across branches.
• Section 30 says “notwithstanding Section 15(3)” — a conditional override, an edge that modifies the meaning of a distant node.
• A tax statute says “as specified in Regulation (EU) 2016/679 Article 4” — a cross-jurisdiction dependency, linking nodes in different legal corpora entirely.
• An EU directive requires member state implementation — the Finnish implementing statute is a derived node whose existence was caused by an EU-level obligation.

These are graph relationships. They connect nodes across branches of the tree, across statutes, across jurisdictions. The tree structure cannot represent them — it only holds the content of each provision and its position within one statute’s hierarchy.

This separation of structure from semantics is not new. Akoma Ntoso (ISO 24679) separated the document structure (the tree) from legal analysis (references, metadata, lifecycle) in the early 2000s. ELI and FRBR provide identification frameworks. LegalRuleML encodes normative content. The contribution here is not the observation that law has graph structure — that’s established — but the argument that computing the text layer correctly as a reproducible, inspectable replay process is a prerequisite for computing the semantic layer correctly.

Law is written as a tree because paper demands it. Law operates as a graph because provisions interact through references, overrides, and dependencies that ignore hierarchical boundaries. A legal state compiler operates on the tree (the text) to produce the substrate that semantic tools operate on.

III. The Amendment Is an Operation, Not an Edit

An amendment act does not say “here is the new text of Section 12.” It says “Section 12, subsection 2 is amended to read as follows.” This is a typed operation with:

• A target address: Section 12, subsection 2
• An action: replace (or: repeal, insert, renumber)
• A payload: the new text
• A source: which act, enacted when, effective when, by whose authority

The vocabulary of text-level operations is small:

| Action | Structural effect | |---|---| | Replace | Node content update | | Repeal | Tombstone version (not deletion — see §III.1) | | Insert | New node at specified position | | Renumber | Address change, identity preserved | | Text-replace | Substring substitution within a leaf | | Text-repeal | Substring removal |

This vocabulary is verified across Finnish, UK, Estonian, and EU amendment systems. The surface language differs (“muutetaan,” “muudetakse,” “is amended to read”) but the structural operations on the text are the same.

III.1: What the vocabulary does NOT cover

The text-level operation vocabulary captures how the serialized text changes. It does not capture how the legal meaning changes. Several classes of legal action operate on meaning rather than text:

Interpretive overlays. “Section 5 shall be read as if ‘the Board’ meant ‘the Council’.” The text of §5 is unchanged. Its meaning changes. This is a semantic operation, not a text operation. Common law “deeming clauses” and reading-down provisions operate this way.

Delegated legislation. An act empowers a minister to make regulations. This creates authority to produce new law — a meta-operation that generates future operations, not an operation on existing text.

Conditional applicability. “This section applies only to entities exceeding a turnover of €10M.” The text exists unconditionally; its legal effect is conditional. The condition is metadata, not a text operation.

Revivor. If a repealer is itself repealed, does the original provision revive? The answer is jurisdiction-dependent (no in some common law systems, yes in others). The tombstone model (repeal = version with null content) doesn’t inherently resolve this — it requires a policy decision at the VM level.

Immutable-base traditions. In systems where the foundational text is sacred or constitutionally entrenched (Sharia, constitutional provisions with supermajority requirements), the operation isn’t “replace” — it’s “layer an interpretation over an immutable base.” The base text cannot be patched; it can only be wrapped.

These are real phenomena. A compiler that claims to capture “what the law says” must either model them or explicitly scope itself to the text layer. LawVM takes the second approach: it compiles the text state — what each provision literally says at a point in time — and leaves the normative state (what the law means, how it applies, what obligations it creates) to downstream semantic tools. This is a deliberate separation of concerns: get the text right first, then build interpretation on a correct textual substrate. The alternative — building semantic models on unverified text — is what produced decades of legal ontology work with no reliable text layer underneath it.

IV. Multiple Time Axes

An amendment published in December 2024 may take effect on January 1, 2026. During the intervening 13 months, the amendment exists — enacted, published, legally valid — but the provisions it modifies have not yet changed for legal purposes.

Law has at least two temporal dimensions:

Publication/enactment time: when the amendment was officially decidedLegal effect time: when the changed provisions enter into force

These axes are independent. “What has parliament decided?” and “what is the law?” give different answers during the gap.

It gets harder:

• A single amendment act can specify different effective dates for different provisions (§§1–5 immediately, §6 next year, §7 “when a decree so provides”).
• Retroactive amendments change the legal effect of provisions for past dates.