The Four Laws of System Design for Computational Law

In brief

Most engineering domains tolerate graceful degradation. A recommendation engine that is slightly wrong still recommends something useful; a search engine that misses one result still returns a page. This essay argues that computational law cannot afford that tolerance, because a legal conclusion that looks plausible but cannot be defended will be filed, cited and relied on. So it proposes four design laws, ordered in the manner of Asimov's laws of robotics, and states their force without hedging: "a system that violates any of them is defective as a matter of design."

The four laws, in order of precedence

The numbering starts at zero, and precedence runs downward. When two laws conflict, the lower number wins.

The Zeroth Law: no unwarranted confidence. A system must never present an output with more confidence than it can defend. The essay's reasoning is specific to law: "A plausible-sounding answer that cannot be defended is worse than no answer at all," because unreliable conclusions do not stay on the screen. They reach filings and citations, with real consequences for clients and courts. In the author's later isResponsive paper, the same law is stated as: "No output may be presented with greater confidence than the system can defend. Uncertainty must be surfaced, not smoothed over. A refusal is always preferable to a fabrication."

The First Law: full explainability. Every result must be traceable to its inputs, its reasoning and its supporting authorities. Lawyers, the essay argues, appropriately extend zero default trust to AI. Trust is earned only when the chain of reasoning can be reconstructed by the person who has to stand behind it.

The Second Law: grounded authority. Every legal proposition the system surfaces must be grounded in validated authority drawn from a knowledge graph, not in general training data or doctrine the model has reconstructed from memory. Grounding is what keeps answers consistent across jurisdictions and across time, because the authority, not the model's recollection, carries the law.

The Third Law: testable components. Reasoning components must be independently testable and version-controlled as first-class assets, so that engineers can verify each one in isolation instead of trusting the behavior of the whole.

Why the ordering matters

The hierarchy is not decoration. It tells a designer what to give up when goals collide. If a fully grounded answer cannot be produced with defensible confidence, the Zeroth Law prevails and the system should say so rather than answer. If isolating a component would make an output unexplainable, explainability comes first. The isResponsive paper shows the laws working as construction rules in a real system: the Zeroth Law becomes a refusal to certify a document review when a statistical recall bound fails, and the Third Law becomes an architecture of separately testable services.

The laws recur throughout the Institute's work. They are stated as a reusable framework in The Four Laws, and they underwrite the argument in The Verification Layer Is a Smoke Alarm, Not a Building Code that citation checking cannot substitute for systems built so that fabrication is impossible.

This page is a summary, not the essay itself. Read the full The Four Laws of System Design for Computational Law on Medium, where Ross Brodskiy first published it on 21 April 2026.