Architecture
A phased compiler for inconsistent, underspecified amendment sources.
LawVM's architecture follows from the source and state problems it is designed to handle. The essay develops the structural argument; this page describes the implementation boundary.
The compiler model
A jurisdiction frontend is a phased compiler with explicit contracts:
- Acquire and archive source artifacts
- Parse amendment text into a clause surface
- Extract payloads and normalize source-locally
- Elaborate against the declared legal snapshot
- Lower to canonical typed operations
- Replay over a base state
- Materialize point-in-time text
- Compare against declared witness or comparison surfaces
The pipeline separates lowering, target resolution, replay, and divergence accounting so that mismatches are inspectable rather than collapsed into a single opaque failure state.
Two planes
LawVM operates on two simultaneous planes:
Semantic plane: source artifacts → clause surface → payload surface → elaborated intent → canonical effects → timelines → PIT materialization. This is the path from raw legal text to point-in-time state.
Epistemic plane: parse witnesses → observations → obligations → adjudications → claims → evidence bundle. This is the path that records why the result should be trusted — what was observed, what was inferred, what was recovered, and what remains unresolved.
Both planes run together. A replay result without its epistemic trail is not a LawVM result.
Three hard waists
The architecture has three stable interfaces that must not be bypassed:
- Clause surface: an early stable representation of amendment instructions. A typed AST for amendment instruction language.
- Payload surface: the amendment body after source-local normalization, before live-state-dependent meaning recovery. This is where the source text stops being raw and starts being structured, but meaning recovery against the current statute state has not yet happened.
- Canonical execution: replay consumes typed canonical execution artifacts. Meaning unresolved at this boundary becomes a finding, failed operation, or explicit strict-mode barrier.
Why deterministic parsing works
Legislative amendment language is a semi-formal instruction language embedded in ordinary legal prose. In Finland, the Lainkirjoittajan opas (legislative drafting guide) documents recurring forms for the johtolause (amendment preamble), including kumotaan (repeal), muutetaan (amend), and lisätään (insert), followed by the operative text. Target addresses also use hierarchical conventions such as lain 12 §:n 2 momentti (section 12, subsection 2 of the act).
Many recurring forms are parseable with conventional grammars. LawVM uses PEG (parsing expression grammars) to extract clause structure, target addresses, action types, and payload boundaries directly from amendment text. The same input produces the same parse.
Prior research has parsed amendment language and automated parts of consolidation. LawVM's distinct scope is an open replay pipeline that carries admitted parses through typed operations, timelines, provenance, and classified residuals. The parsing article links to selected prior work and states the boundary of the Finnish demonstration.
Selected historical patterns use quirks-mode recovery with explicit provenance; unsupported cases can remain blocked or unresolved. Where a declared grammar path succeeds, its result is deterministic and inspectable for the pinned implementation and inputs.
Owned recovery
Historical legislation contains malformed XML, editorial shortcuts, implicit targets, stale consolidated witnesses, and source defects. LawVM cannot avoid recovery logic. The governing rule is that recovery must be owned.
If a rule deletes, moves, relabels, reroutes, widens, narrows, or otherwise changes legal state, it must have a stable rule id, emit a typed observation or finding, preserve before/after evidence, and be rejectable where strict mode requires it. A heuristic may be necessary; an invisible heuristic is a compiler bug.
This is the boundary between LawVM and ordinary scraping. The system is allowed to say "I recovered this because the source had this shape." It is not allowed to make the tree look cleaner without leaving an evidence trail.
Strict mode and quirks mode
LawVM serves two worlds:
Quirks mode is for the historical corpus. Real legislative text contains omitted context, editorial shortcuts, inconsistent numbering, source encoding oddities, and amendments that only make sense against a specific live consolidated witness. Quirks mode permits owned recovery heuristics with provenance; unowned or unsupported inference should remain visible rather than becoming silent source fact.
Strict mode is an available policy for selected profiles and phases. Where its gate is wired, named unproven recovery or a boundary violation blocks the scoped result instead of becoming an executable operation. It is not a universal publication gate today.
Strict mode is also the target discipline for future legislation authored to compile cleanly: amendments remain human-readable while an approved machine artifact makes targets, actions, temporal effects, and unsupported-input rejection explicit. Quirks mode remains the recovery compiler for historical material.
Future strict-authoring theorem
Strict authoring is a direction for law co-produced with a formally specified, machine-checkable language. A clean result would require a frozen and complete source universe; authoritative source roles; correspondence between the human-approved text and machine artifact; formal grammar, semantics, and rejection rules; sound and complete lowering to typed operations; exact target, identity, and temporal rules; replay/materialization refinement; end-to-end implementation evidence; an independently implemented checker; intact content-addressed artifacts; live guards; and no blocking residuals.
Conditional theorem: under those conditions, a clean dossier could establish that generated text-state matches the declared formal semantics for every accepted input in its jurisdiction, profile, and time query. Unsupported or ambiguous input would be rejected or blocked. The theorem would concern that closed language and domain; the institution would retain authority over source status, legal judgment, and publication.
Current boundary: LawVM has bounded invariants, strictness gates, property tests, formal models, and experimental dossier checking, but it does not yet provide end-to-end source-language entailment or implementation-refinement proof. Historical frontends therefore remain qualified, residual-preserving, or observe-only where their profile says so.
Frontend / kernel boundary
The shared kernel is jurisdiction-agnostic: canonical legal-address and tree model, operation vocabulary, replay execution, timeline semantics, materialization, structural invariants.
Frontends are jurisdiction-local: source acquisition, parsing conventions, drafting idioms, payload extraction, elaboration rules, source pathology, and comparison-surface handling.
The design question is: what is the smallest defensible executable claim for this jurisdiction, and what source family supports it?
Beyond Layer 0
LawVM derives point-in-time textual state within a declared source and profile. Legal meaning, practical application, and economic effect belong to higher layers:
| Layer | Question | Scope |
|---|---|---|
| L0: LawVM | What does the text say? | Text-state compilation, provenance, timelines |
| L1: Legal views | Which view to run? | Territorial, commencement, transitional overlays |
| L2: Interpretation | What do authorities say it means? | Court holdings, guidance, doctrine |
| L3: Praxis | How is it actually applied? | Enforcement, institutional behavior |
| L4: Reasoning | What follows for this fact pattern? | Compliance, simulation, argument |
| L5: Products | What can users do? | Search, Q&A, drafting assistants |
Upper layers attach claims to L0 anchors without mutating the text-state kernel. LawVM is designed as a substrate with typed identities, span-level anchoring, explicit provenance, and overlay hooks; its public APIs are not yet a stable compatibility promise.