Analysis by
Founder, Lex Wire Journal • Technology, Governance & Sovereignty Strategist
Rules No Longer Exist Only in Laws, Contracts, and Policies
Law governs by establishing rules.
Legislatures enact statutes. Regulators issue regulations. Courts interpret legal obligations. Companies adopt policies. Contracts establish rights and responsibilities between parties. Professional organizations create standards governing their members.
But another system of rules increasingly operates alongside them.
Software determines whether a user can enter an account. Permissions determine which information an employee can see. Platforms determine what users can publish, transfer, modify, or remove. Algorithms determine which information appears first. Automated systems determine whether a transaction proceeds, whether an application advances, or whether an activity is flagged for additional review.
These systems do not necessarily create law.
But they can create rules that function in ways that resemble governance because they structure what participants can do within the environments those systems control.
The distinction matters because the institutions of the digital age are increasingly governed not only by rules written in legal documents, but by rules embedded in technological architecture.
The Bottom Line
Digital architecture increasingly does more than support institutional rules. It can implement, interpret, and enforce them. When software determines who can participate, what actions are permitted, which information is visible, and what happens when conditions are not satisfied, architecture begins functioning as a form of governance.
“Law tells us what we are permitted to do. Digital architecture increasingly determines what we are capable of doing inside the systems through which modern life operates.”
Jeff Howell, Sovereignty & Law
Law and Architecture Regulate Differently
Legal rules and architectural rules can produce similar outcomes through fundamentally different mechanisms.
Consider a simple restriction.
A rule might state that a particular employee is prohibited from accessing confidential client information.
One approach is behavioral. The employee is informed of the rule and faces consequences for violating it.
Another approach is architectural. The employee’s credentials simply do not permit access.
The first governs conduct by establishing an obligation.
The second governs the environment by constraining the available action.
Law can prohibit an action. Architecture can sometimes make the action unavailable.
That distinction does not make architecture superior to law. Technical systems can be poorly designed, overly rigid, circumvented, discriminatory in effect, inconsistent with legal rights, or incapable of accounting for exceptions that human judgment would recognize.
It does mean that architecture creates a different form of constraint, one that increasingly matters to lawyers because so much human and institutional activity now occurs inside designed technological environments.
“Code Is Law” Was a Warning About Architecture
Lawrence Lessig’s influential work Code and Other Laws of Cyberspace helped establish the idea that the architecture of digital environments can regulate behavior.
The phrase commonly associated with his argument, “code is law,” is sometimes interpreted too literally.
Code is not legislation. Programmers are not legislatures merely because they write software. A platform rule is not automatically a legal rule, and technical enforcement does not determine whether the underlying rule is lawful.
The deeper insight is about regulation.
Architecture can establish what a digital environment permits, prevents, requires, records, reveals, or makes difficult. As more activity moves into those environments, the regulatory significance of architecture grows with it.
Policy Can Now Be Executable
Modern cybersecurity provides one of the clearest examples.
In NIST’s Zero Trust Architecture, access to resources is mediated through a technical architecture that distinguishes policy decisions from policy enforcement.
A policy engine determines whether access to a resource should be granted, denied, or revoked based on enterprise policy and relevant information. A policy administrator carries out that decision, while a policy enforcement point controls the connection between the requesting subject and the protected resource.
NIST’s 2025 implementation guidance demonstrates that these principles are not merely theoretical. The National Cybersecurity Center of Excellence worked with 24 collaborators to construct 19 example zero-trust implementations using commercially available technology.
In this context, organizational policy is not simply communicated to users. Parts of it are translated into technical decisions and enforcement mechanisms.
“The moment a rule becomes executable, governance acquires an architectural layer.”
Jeff Howell, Sovereignty & Law
Digital Architecture Governs Through Permissions
Permissions may be one of the most important forms of governance in the digital environment.
Who can read?
Who can write?
Who can modify?
Who can approve?
Who can transfer?
Who can revoke?
Who can change the permissions themselves?
Those questions sound technical because they are routinely implemented through software. But they are also questions about authority.
The final question is especially important. The person or organization capable of changing the permission structure occupies a different position from everyone governed by it.
Platforms Demonstrate Governance at Scale
Large digital platforms make architectural governance particularly visible.
A platform can establish rules through its terms of service. But the experience of users is also governed by software: account permissions, content controls, ranking systems, recommendation systems, identity requirements, automated moderation, interface design, and technical restrictions.
Regulators have begun addressing some of these architectural systems directly. The European Union’s Digital Services Act, for example, requires online platforms using recommender systems to explain in plain and intelligible language the main parameters used by those systems and the options users have to modify or influence them.
The law is therefore not disappearing from digital governance.
In some circumstances, law is beginning to govern the architecture that governs users.
The emerging relationship is not law versus code. It is law governing code, code implementing policy, and architecture shaping behavior within the boundaries both create.
AI Adds a Decision Layer to Digital Governance
Artificial intelligence complicates this framework because digital systems are increasingly capable of doing more than enforcing predetermined permissions.
They can classify information, rank alternatives, identify patterns, generate recommendations, retrieve records, summarize evidence, flag anomalies, and assist with decisions.
This creates a spectrum.
Rule
The institution establishes what should happen.
Code
Software translates some part of that rule into technical logic.
Enforcement
The system permits, prevents, records, or conditions an action.
Intelligence
AI may increasingly influence how information is interpreted or which options are presented before a human decision is made.
This does not mean that an AI system possesses legal authority merely because an organization uses it.
It means that the architecture surrounding a decision can influence which information reaches the decision-maker, which alternatives appear available, and which actions the system makes easy or difficult.
Governance therefore increasingly requires attention not only to who formally possesses decision-making authority, but to the technological systems through which that authority is exercised.
Architecture Can Govern Without Being Neutral
Every architecture contains choices.
Someone determines the default settings. Someone decides which permissions exist. Someone determines how identity is established. Someone chooses which data is collected. Someone defines the available categories. Someone establishes the conditions under which an action is accepted or rejected.
Those decisions may be made for sound reasons: security, efficiency, usability, compliance, interoperability, fraud prevention, or operational necessity.
But they remain design choices.
Once embedded in widely used infrastructure, those choices can shape behavior at a scale that an ordinary written policy rarely achieves.
“Every digital system contains an implicit constitution: rules about who can participate, who can decide, what can change, and who ultimately controls the rules themselves.”
Jeff Howell, Sovereignty & Law
The Most Important Permission Is the Power to Change the System
Governance ultimately leads to a recursive question.
Who governs the governance system?
In law, constitutions, statutes, corporate charters, administrative procedures, judicial review, elections, contracts, and other mechanisms establish processes through which rules can be created, challenged, interpreted, and changed.
Digital systems have their own mechanisms of change.
Administrators can change permissions. Developers can change code. Vendors can change product functionality. Platforms can change policies and algorithms. Protocol communities can adopt or reject software changes. Organizations can migrate to different systems, assuming their architecture preserves a realistic ability to do so.
The structure governing those changes may matter as much as the rules operating at any particular moment.
The deepest governance question is not simply who controls the system today. It is who possesses the authority and practical ability to change the system tomorrow.
That is where technological architecture, institutional power, and sovereignty begin to converge.
Governance Architecture Is Becoming a Legal Question
Lawyers do not need to become software engineers to understand the significance of this change.
They do need to recognize that formal legal rights increasingly operate inside technological environments capable of enabling, restricting, recording, prioritizing, or mediating their exercise.
A right to information means something different when access is controlled through software. A contractual right to retrieve data means something different when the format is difficult to use elsewhere. An institutional policy means something different when an automated system implements it. Human decision-making means something different when AI determines much of the information placed before the decision-maker.
Law and architecture are therefore not separate layers that can always be analyzed independently.
Increasingly, they interact to determine how rights and power operate in practice.
From Digital Governance to Decentralization
The first nine analyses in Sovereignty & Law lead to a recurring question.
Where does control reside?
The Architecture of Dependence examined how systems can quietly concentrate control. The Right to Exit asked whether meaningful alternatives remain available. Verification Over Trust examined where trust resides. Whoever Designs the Trust Architecture Designs the Institution connected that architecture to institutional power.
Once architecture is recognized as a mechanism through which control, trust, and governance can be concentrated, another design question naturally follows.
What happens when an architecture deliberately distributes some of those powers instead?
That is the question behind decentralization.
The next Sovereignty & Law analysis will examine it without assuming that decentralization is inherently superior to centralized systems: Why Decentralization Matters to Lawyers: Power, Intermediaries, and the Architecture of Trust.
This article is part of Sovereignty & Law, a Lex Wire Journal editorial initiative examining how technology is changing the relationship between law, ownership, trust, agency, and power.
