The Invisible Interface

On law, software, and the infrastructure nobody notices until it breaks

Bus Commons — May 2026

---

The problem nobody talks about

Law is the last major information system without an API.

Every statute, regulation, and municipal ordinance in every jurisdiction in the United States exists as natural-language text, published in formats designed for human lawyers reading sequentially. When a regulation changes — a zoning setback, a financial reporting threshold, a building code requirement — the change propagates through the system the way it has for centuries: someone reads it, interprets it, and manually updates whatever downstream system depends on it. Eventually. If they notice.

This was adequate when the number of entities making legal-adjacent decisions was small and human. It is not adequate now. AI agents are making compliance-relevant decisions at scale, across jurisdictions, against interpretations someone hard-coded months ago. Every organization that needs to be compliant builds its own interpretation layer — bespoke, expensive, fragile, and invisible to the system it interprets. This is artisanal compliance at industrial scale.

The question is not whether law should be an API. It already is one. Every compliance team, every regulatory technology platform, every AI system that checks a rule before taking an action is treating law as a programmatic interface. The interface is just badly designed — undocumented, unversioned, inconsistent across jurisdictions, and maintained by accident rather than intention.

What “law as an API” actually means

The phrase invites misunderstanding. It does not mean replacing judges with algorithms. It does not mean encoding judicial discretion into if-then rules. It does not mean automating legal interpretation.

It means this: the text of law — the statutes, the regulations, the municipal codes — should be published in structured, versioned, machine-readable formats alongside their natural-language originals. When a regulation changes, systems that depend on it should know. Not eventually. Not when a lawyer notices. Immediately, the way a software dependency updates when its upstream library publishes a new version.

The analogy is precise. Software ecosystems solved this problem decades ago. A library publishes a versioned interface. Downstream systems declare their dependencies. When the interface changes, the dependency graph propagates the change automatically. Breaking changes are flagged. Compatibility is verified. The entire ecosystem coordinates through the interface rather than through manual human effort.

Law has no equivalent infrastructure. A change to Massachusetts General Laws Chapter 40A (zoning) propagates to municipal zoning boards, developers, lenders, title companies, and AI systems through a chain of human reading, interpretation, and manual update that can take weeks to months. During that delay, every downstream system operates on stale information. The gap between the law as enacted and the law as implemented is invisible, unmeasured, and consequential.

The interface is already being built — badly

The vacuum is not empty. It is filling with proprietary interpretation layers built by organizations with the resources to build them. Every major compliance platform — in financial services, healthcare, housing, environmental regulation — maintains its own parsing of the relevant law. These interpretations are trade secrets. They are not auditable. They do not agree with each other. And increasingly, they are the substrate on which AI agents make decisions that affect people who have no visibility into the interpretation being applied.

This is the equity problem that makes the infrastructure argument urgent. When law is only queryable through expensive proprietary systems, access to accurate legal information becomes a function of organizational wealth. A large bank can afford a regulatory technology platform that tracks every change to Dodd-Frank in real time. A community development financial institution in Roxbury cannot. Both are bound by the same law. Only one knows what the law currently says.

The same asymmetry applies to AI systems. A well-resourced AI deployment checks its compliance against a maintained, regularly updated rule base. A smaller deployment checks against whatever interpretation was hard-coded at launch. Both operate with confidence. Only one is operating on current information.

What exists already

This is not a theoretical proposal. Production deployments exist.

OpenFisca, originally developed by the French government, is an open-source platform that encodes tax and benefit rules as versionable, testable code. It is in production in France, New Zealand, Australia, Japan, and Spain. New Zealand’s SmartStart service uses it to calculate citizen entitlements in real time — a citizen answers questions, the system queries the encoded rules, and the result is traceable to the specific statutory provisions that produced it.

Germany’s Modernization Agenda has made machine-readable law a central pillar of government digital infrastructure. The goal: when a legal provision changes, the update deploys like a software patch. The Federal Ministry of the Interior coordinates this work across agencies.

The OECD has published formal guidance on “Rules as Code,” establishing principles for how governments can publish machine-readable versions of legislation alongside the authoritative natural-language text. The key principle: the code is not the law. The code is a representation of the law, versioned and testable, that makes the law’s requirements queryable without replacing the law’s authority.

No U.S. state has done this at production scale.

Why Massachusetts

Massachusetts has the institutional infrastructure to be first.

The FutureTech Act ($1.26B bond authorization) explicitly targets government digital infrastructure modernization, cybersecurity, and AI investment. The Mass Leads Act created a $100M AI Hub at the MassTech Collaborative, with grants up to $1M for AI applications in public-interest domains. The Innovation Infrastructure Fund ($15M) supports entrepreneurship and technology development. These are not hypothetical funding mechanisms — they are enacted, appropriated, and administered.

The legislative committee structure maps directly. The Senate Committee on State Administration and Regulatory Oversight (SARO) has jurisdiction over public records, government operations, state regulations, and open meeting law. A project that makes state law queryable falls squarely within SARO’s subject-matter domain. The Joint Committee on Economic Development and Emerging Technologies oversees AI policy and the MassTech programs.

Massachusetts also has the talent. The Boston-Cambridge corridor has the densest concentration of AI research, computational law, and civic technology expertise in the country. MIT’s Computational Law initiative, Harvard’s Berkman Klein Center, and the Seaport Innovation District’s technology workforce are all within the same metropolitan area.

And Massachusetts has a history. The Commonwealth was the first state to mandate public education, the first to establish a public library system, and among the first to create open-meeting and public-records laws. Making law itself into queryable public infrastructure is consistent with a tradition that treats civic knowledge as a public good.

What we would build

The architecture is straightforward because the hard design problems have already been solved — by OpenFisca, by software dependency management, and by the OECD’s Rules as Code framework.

A schema for statutory encoding. Each provision gets a unique identifier, version history, effective dates, and dependency graph. The schema is open, extensible, and jurisdiction-aware. It does not encode interpretation — it encodes text and structure, making explicit what is already implicit in the published statute.

A versioned API. Query any provision by jurisdiction, domain, effective date, or dependency. Get the current text, the structured encoding, the change history, and the downstream provisions that depend on it. When a provision changes, subscribers are notified through the dependency graph — the same pattern that makes software ecosystems work.

An interpretive accountability layer. This is the piece that most “law as code” proposals miss. When an AI system or compliance platform queries the API, the query and the result are logged. The interpretation chain is auditable: this system, querying this provision, at this version, on this date, received this result. When interpretations diverge — and they will — the divergence is visible rather than hidden inside proprietary systems.

A federation model. Massachusetts does not need to encode federal law, and Boston does not need to encode state law. Each jurisdiction encodes its own provisions and publishes them through a federated API. The dependency graph crosses jurisdictional boundaries: a Boston zoning regulation depends on MGL Chapter 40A, which depends on federal standards. The federation model makes these dependencies explicit without requiring centralized encoding.

Why a Public Benefit Corporation

The entity that builds this infrastructure should not be optimizable for private return. Legal information is a public good. The infrastructure that makes it queryable should be governed accordingly.

A venture-backed company building this infrastructure would face an inevitable tension: the most valuable data is the interpretation layer, and the business model pushes toward making interpretations proprietary. This is exactly the dynamic that created the current problem — legal information is technically public, but practical access to structured, current, queryable legal information is gated by organizational wealth.

A government agency building this infrastructure would face different constraints: procurement cycles, talent competition with the private sector, and the political risk of funding a system that makes regulatory change more visible (not every stakeholder wants that).

A Public Benefit Corporation is chartered to weigh public benefit alongside financial returns. The infrastructure is open-source, released under open licenses, designed to outlive any single vendor. The PBC sustains itself through implementation consulting, domain-specific encoding services, and institutional licensing — revenue models compatible with the public-interest mission. The legal structure binds the mission to the corporate charter, not to the preferences of the current team.

Bus Commons is incorporated as a Massachusetts PBC, in Roxbury, under the legal name CUBE COMMONS, INC. We build open standards, schemas, protocols, and focused institutional software for civic infrastructure. The law API is not a pivot — it is a direct application of the architecture we have already built: federated coordination, cryptographic identity, trust boundaries, and auditable state.

How it starts

Phase one is deliberately small: one domain of law, one jurisdiction, twelve months.

The most natural starting point is Massachusetts housing law — specifically, MGL Chapter 40A (zoning) and its downstream municipal ordinances. Zoning touches every development project, every lender’s title review, every municipal planning decision, and every AI system that evaluates property risk. It is the domain where the gap between law-as-enacted and law-as-implemented is most consequential and most visible. A developer in Boston checking setback requirements today navigates a chain of municipal ordinances, state enabling statutes, and judicial interpretations that has no single authoritative digital source. The API would be that source.

The pilot produces a working system, not a study. Encoded statutes with unique identifiers, version history, and dependency graphs. A queryable API. An interpretive accountability log. A federation protocol connecting Boston’s municipal encoding to the Commonwealth’s statutory encoding. At the end of twelve months, a municipal planning board, a title company, and an AI system can all query the same provision and get the same structured result — traceable to the specific statutory text that produced it.

Phase two is production adoption. Municipal systems query the API instead of maintaining their own copies of enabling statutes. The interpretive accountability layer begins logging how different systems interpret the same provision — making divergence visible for the first time. Additional domains come online: financial regulation, building codes, environmental standards. Each domain follows the same pattern: encode the text, publish the schema, stand up the API, connect the dependency graph.

Phase three is federation. The schema is open. The protocol is published. Other Massachusetts municipalities adopt without permission or licensing fees. Other states can join the federation without asking — the same way a software library joins an ecosystem by publishing to a package registry. The infrastructure grows through adoption, not through sales.

How it sustains

The schema, the API, and the federation protocol are open-source. The infrastructure is a public good. This is non-negotiable — the entire argument depends on it.

Revenue comes from four sources, all compatible with the open-source commitment.

Implementation consulting. Encoding a body of law is skilled, domain-specific work. It requires legal expertise, software engineering, and the judgment to distinguish structural text from interpretive gloss. Jurisdictions that want their law encoded pay for the encoding. The output is open; the expertise is not.

Institutional licensing. Organizations that query legal infrastructure at scale — banks, insurance companies, regulatory technology platforms, AI deployments — need guaranteed uptime, service-level agreements, and support. The API is free. The SLA is not. This is the model that sustains every major open-source infrastructure project, from Linux to PostgreSQL.

Federation infrastructure. Operating the coordination layer between jurisdictions — maintaining the cross-jurisdictional dependency graph, resolving version conflicts, managing subscriber notifications — is ongoing infrastructure work. Jurisdictions that participate in the federation contribute to its operating costs, the way municipalities contribute to shared water and sewer infrastructure.

Domain-specific encoding services. When a new domain of law needs to be encoded — say, a state legislature passes comprehensive AI regulation and wants it queryable from day one — the encoding is a contracted service. The statute is public. The structured encoding is public. The work of producing the encoding is paid.

None of these revenue streams require making the infrastructure proprietary. None of them create the equity asymmetry the project exists to eliminate. And each of them grows as the infrastructure grows — more jurisdictions, more domains, more downstream systems, more demand for the expertise and operational support that keeps the infrastructure reliable.

The honest constraint is timing. Implementation consulting and institutional licensing generate revenue only after the pilot produces a working system. The pilot itself requires seed funding — from the Innovation Infrastructure Fund, the MassTech AI Hub, or direct legislative appropriation. The public funding bootstraps the public infrastructure. The revenue model sustains it.

The invisible interface

The title refers to what is already happening. Law already functions as a programmatic interface — every system that checks a rule before taking an action is treating law as an API call. The interface is just invisible: undocumented, unversioned, maintained by accident, and accessible only to those who can afford to build their own interpretation layer.

Making the interface visible does not change the law. It does not automate judgment. It does not replace lawyers or judges or the interpretive work that makes law a living system rather than a mechanical one. It makes the text — the substrate on which all interpretation depends — structured, versioned, queryable, and available to everyone equally.

The infrastructure that makes this possible is not glamorous. It is not AI. It is not blockchain. It is not a platform. It is a schema, a version control system, a dependency graph, and a federation protocol. It is the kind of infrastructure that nobody notices until it breaks — or until they realize it was never built in the first place.

The window for building it is open now, and it will not stay open indefinitely. AI systems are making compliance-relevant decisions today, against interpretations that were current when someone hard-coded them and have not been checked since. Every month that passes without public infrastructure is another month where the interpretation layer is built privately, by the organizations that can afford it, optimized for their interests, invisible to everyone else. The proprietary alternative is not hypothetical. It is being built right now, by companies that will not open-source it, in jurisdictions that have not yet built the public option.

Massachusetts has the legislative infrastructure, the funding mechanisms, the talent, and the tradition. Five countries have production deployments. No U.S. state has started. The question is not whether this infrastructure will be built. It is whether it will be built as a public good or as a private service — and whether the Commonwealth that invented the public library will also build the public law API.

---

Bus Commons (CUBE COMMONS, INC.) — Roxbury, Massachusetts CC BY 4.0