LawVM as Mechanism Engineering

Worked examples: public LawVM snapshot, 12 July 2026. Later LawVM development is not the evidence for these claims.

I. Who must remember what

LawVM reconstructs legal text from published amendments. Fidelity to those sources is the working criterion, with unresolved cases left visible. That reconstruction is one engineering project. A second project organizes the people, models, representations, and checks that build and revise it. A single code patch can change either or both. The distinction is what future work inherits.

A forgotten requirement can be added to a prompt. It can become a regression test. It can also lead to a representation in which the troublesome operation is unavailable, or a separate check that refuses it. Each choice places a different recurring burden on later work.

A rule missing from a confidence registry could receive the most confident classification. The diagnosis was a split update: the rule in one place, its classification in another, and a missing classification treated as certainty. Three repairs were available. A reminder would have told every later contributor to keep the two places in step. A completeness test would have let them forget, then failed visibly. A single catalog would have removed the second place.

The public snapshot records two of those constructions, not a single chronology through all three. In one implementation, an unknown rule now fails explicitly. In a neighboring implementation, the rules and their confidence classifications are derived from one catalog, so that synchronization failure cannot arise through that route. The project's discipline record names the hierarchy: eliminate the trap, make the gap visible, or test for it.¹

The difference is who must remember what. With a reminder, every future contributor must remember to update two places. With a completeness test, the contributor can forget and receive an error. With one authoritative catalog, there is no second update to forget. The gain is not that the two records sit near each other. It is that they are no longer independently maintained. The original judgment about a particular rule may still be wrong. A class of failure has been removed rather than checked.

Later attempts encounter a different work path: the silent default is gone, or the second register is gone. The motivating defect — an uncataloged rule treated as certain — is rejected or cannot be represented. A valid neighboring case, a rule whose classification was entered, still works.

The same question applies when models do much of the work. A model can produce an elaborate candidate without acquiring the right to decide what that candidate proves. LawVM's public Agent Guide states a separation of proposal, validation, and execution. A recovery heuristic may search broadly; a separately defined check is supposed to decide whether a proposed change may enter replay. The existence of that rule is not evidence that every implementation path enforces it.²

A useful requirement is therefore more specific than “be careful”: name the object, the allowed change, the evidence required, and the test that should reject the motivating failure. A guard, in this sense, is a check or restriction that can intercept a specified failure on a named path. Its immediate achievement is to make a previously silent move explicit, rejectable, and open to inspection in the ordinary work path. The maintainer still controls the repository.

II. What the checker never saw

A changed path is still only as strong as the proposition its checks actually establish.

A checker can approve every item it receives while the system has already lost part of the work. Asking another reviewer to inspect the same items leaves the missing part just as invisible.

One of LawVM's public accounting checks starts with a declared list of source effects — amendment instructions in that list — and records what happened to each. An effect must produce operations, a named rejection, or an observation. Saying that an effect was handled while emitting nothing is an error; so are duplicate records and records for effects outside the declared list.³

The boundary is easy to demonstrate on the public module. Declare two source effects, account for only one, and the checker rejects the result. Remove the missing effect from the declaration as well, and the checker accepts the remaining account. Both behaviours are correct for the question the checker was given. The second input contains no evidence that anything is missing.

Accounting for every declared input is a different task from establishing that every relevant input was declared.

A public development change addresses this blind spot in document ingestion. In the affected paths, checks examined the units extracted from a document; a dropped section or column could produce no unit and therefore no unresolved item. The snapshot includes an optional coverage comparison for born-digital material: text regions on the source page against the regions claimed by extracted units. Unclaimed text and gaps in section sequences become findings. Tests for that pass were inspected, not executed here. The comparison changes later attempts only on paths that actually run it. It is not the default production path, and it cannot see omissions that never appear as text or geometry.⁴

Where it does run, the object under inspection has changed. Instead of asking only whether the extracted work was acceptable, the pass asks what happened to the source material from which that work should have come. That is a construction of the same family as the catalog. It is also a reminder that a passing check, including a new one, still proves only the proposition it was given.

III. The checker is also on trial

A recorded explanation can be empty ceremony. A field named “evidence” does not establish that the evidence supports the result.

LawVM's public receipt checker requires a nonempty source-warrant pointer for an emitted operation. A minimal test can supply a meaningless nonempty string and satisfy that requirement. The checker has established that a pointer was supplied, not that its target exists or justifies the operation.³

The same issue appears when a blocking finding is downgraded. Sometimes a finding is mistaken: a structural rule can misread a numbering convention, for example. LawVM permits reclassification but requires a named rule and a reason. Its small public checker rejects a missing rule or missing reason. It accepts an arbitrary nonempty explanation, because judging the explanation is outside that check.⁵

A reclassification procedure must retain the decision for inspection and determine whether its reason defeats the original finding. This checker establishes only that the supplied record contains the required fields. Preserving the record and evaluating the reason remain separate operations.

The test machinery must be developed with the same care as the machinery it tests.

This work includes discovering the proposition a check should establish. Is the input population complete? Does the source support this operation? Did the operation stay within its permitted target? Is an earlier result still applicable after its dependencies changed? These are different questions. Agreement on one cannot silently authorize a conclusion about another. Reusing a result introduces another: whether the inputs and conditions under which it was checked still hold.

Code can exist before it is wired into the production path. A test can pass before the broader claim it was meant to support is settled. A design can specify a needed account before that account is implemented. Preserving those states lets construction continue without pretending that every remaining question has already been answered. Later work should inherit exact checks and the limits of those checks, rather than a general reputation for having been tested.

IV. The cost of a guard

A process that rejects everything can make a defect count look excellent. Useful construction has to preserve the work the mechanism was built to enable.

LawVM's discipline record includes rejected guard designs. A broad static rule against swallowed exceptions matched many legitimate best-effort operations and was dropped as too noisy. The retained rule targeted a narrower operation: changing a blocking finding to nonblocking without recording why. Tests exercised both its firing case and its permitted case.¹

A protective rule creates maintenance work, exceptions, false positives, and incentives to route around it. If those costs overwhelm its function, keeping the rule can reproduce the original problem in a different form.

The relevant comparison is between possible repairs to the same failure. A reminder may be sufficient for a rare, reversible mistake. A test may protect a stable invariant. A redesigned representation may eliminate an entire synchronization problem. An explicit exception path may preserve legitimate work that an overbroad ban would suppress.

A guard also needs a test of its own operation. Introducing the motivating defect should make it fire; a valid neighboring case should pass. If the guard belongs on the production path, a direct call to its helper function is insufficient evidence that production actually reaches it. If an override remains possible, the override must preserve enough of the original finding to be challenged later.

The method therefore includes retiring machinery. A bad check should not become permanent merely because it was introduced in response to a real failure. The lesson worth retaining is the reason for the protection, together with a way to detect when the protection has ceased to serve that reason.

V. Inventing the acceptance machinery

The difficult work is not limited to implementing a known specification. The missing-input example required discovering that the successful output population was the wrong denominator. The reclassification example requires distinguishing the presence of reasons from their validity. The process has to invent part of the acceptance machinery while it invents the system being accepted.

That is why a newly exposed failure is already a construction task. “This checker cannot see that omission” names the next object. So does “this guard rejects the valid case,” or “these two supposed authorities answer different questions.” Increasing participant capability is one lever. Changing the task representation, access to evidence, division of labor, admissible operations, and cost of checking can make a different range of work possible.

These practices have close counterparts in existing engineering work. Proof-carrying code separates an untrusted producer from checking. CompCert composes explicit preservation guarantees across compiler passes. Continuous-assurance research treats evidence, arguments, and their possible defeaters as maintained objects. Ryan Lopopolo's OpenAI note on harness engineering, and Nicholas Carlini's Anthropic report on a C compiler built with parallel agents, describe redesigning environments, tests, and coordination so agents can perform longer and more complex work.⁶

The examples here show particular changes to the work path and the limits of the checks involved. One further construction problem is to keep a result attached to the exact question and conditions under which it was checked: reject an account that does not justify that result, and reconsider reuse when a relevant dependency changes.

I pursue LawVM for substantive learning and invention, as well as for the prospect of an inspectable demonstration. Learning, demonstrated capability, and adoption are different results. A builder can reproduce a boundary case, supply an independent check, or help construct the next one without endorsing a finished institution.

VI. One institutional question

A proposed public arrangement for testing mechanisms, preserving findings, and connecting them to an answerable correction process would also be produced by fallible participants. They would need to know which question they are answering, what population their evidence covers, what follows from a finding, and who may authorize the next action. Those are design problems, not qualities conferred by calling a body independent.⁷

The LawVM cases are a source of candidate methods for that work, not a demonstrated institutional implementation. One exact transfer question is already live in the software examples:

When an institution reports that every finding received a disposition, who establishes the population of findings against which that completeness claim is checked?

A source inventory can be finite and machine-readable; a public problem population may be disputed or only partly observable. A software check can reject an operation immediately; a policy evaluation may require competing causal models and years of observation. A repository owner can authorize a merge; public authority has to come from the relevant institutional arrangement. A public body that copies the labels has acquired none of those functions. Whether any such transfer works has to be shown with its own cases.

LawVM is a research setting in which some of this work can already be made exact. Each attempt can leave behind something more capable of producing, checking, and revising the next attempt.

The enduring product of a repair is what the next attempt no longer has to rediscover.

Related:

• Mechanism Realism — why a lasting repair concerns the machinery and its continued correction.
• How I Work — the distinction becoming usable by someone other than its author.
• Composite I — generated criticism, discriminating checks, and answerable judgment.
• There Is No Exception Handler — inputs that never acquire an owned case.
• The Corrigible State — the complete public path from challenge to verified correction.
• The Fourth Branch — one proposed institutional form, distinct from the methods tested here.
• Essay Engineering — how a distinction is installed as a corpus node.