Law as an API: Machine-Readable Rules for Benefits, Permits, and Compliance

The strongest objection is that law is not software. Legal rules contain ambiguity, discretion, equity, exceptions, constitutional constraints, and facts that cannot be reduced to a clean decision tree. A machine-readable implementation could oversimplify law, create false confidence, accelerate wrongful denials, help sophisticated actors game thresholds, or freeze policy into brittle code that excludes edge cases.

That objection is correct if code is treated as the law itself. This issue rejects that. The legal text remains authoritative. The machine-readable layer must disclose authority, assumptions, inputs, exceptions, edge cases, human-review triggers, and appeal paths. Public test suites should include borderline cases and "manual review" outputs, not only simple yes or no answers. The position holds because operational law is already being encoded somewhere. The democratic question is whether the public can inspect, test, and challenge that encoding.

Agencies bear the cost of translating operational rules into schemas, calculators, tests, version histories, and public APIs. States, local governments, tribes, and small agencies may need implementation grants and shared components. Vendors bear the cost of conforming to public tests instead of private interpretations. Program lawyers, policy staff, engineers, and frontline workers bear the cost of making implicit rules explicit.

Users bear risk if rule packages are wrong, incomplete, inaccessible, or used to deny service without human review. Small businesses may bear transition costs as compliance tools update. Those costs are justified only with phased rollout, open-source reference tools, public correction channels, safe-harbor limits, accessibility requirements, paper alternatives, and appeal rights.