Analysis by
Founder, Lex Wire Journal • Technology, Governance & Sovereignty Strategist
Institutions Are Increasingly Built From Rules Embedded in Technology
Every institution has an architecture of trust.
Someone is authorized to make decisions. Someone maintains the records. Certain identities are recognized. Particular documents are treated as authoritative. Some people can enter systems that others cannot. Information moves through approved channels. Rules determine who can see, change, approve, transfer, delete, or disclose what the institution controls.
Historically, many of those arrangements were expressed primarily through law, organizational hierarchy, professional roles, contracts, policies, and human procedures.
Increasingly, they are also expressed through technology.
Identity systems determine who is recognized. Permissions determine what each person can access. Software workflows determine which approvals are required. Databases determine where authoritative records reside. APIs determine which systems can communicate. AI systems increasingly determine which information is surfaced, summarized, prioritized, or acted upon.
These may look like technical implementation decisions.
But once technology becomes part of how an institution recognizes authority and executes decisions, architecture begins to participate in governance.
The Bottom Line
Trust architecture determines who and what an institution relies upon to establish identity, authority, access, information, and action. As more of those relationships are implemented through technology, the design of technological systems increasingly influences the practical design of the institution itself.
“Whoever designs the trust architecture does more than design a technology system. They help determine how power moves through the institution.”
Jeff Howell, Sovereignty & Law
What Is a Trust Architecture?
Trust architecture is not a single technology.
It is the collection of mechanisms through which a system determines what participants, information, credentials, processes, and decisions it will recognize as authoritative.
In a traditional organization, that architecture might depend heavily on hierarchy. Employees trust managers to approve decisions. Departments trust designated custodians to maintain records. Customers trust the institution to maintain accurate accounts. Courts, regulators, auditors, insurers, and other outside institutions may provide additional layers of accountability.
Digital systems add another layer.
Identity
What establishes that a person, device, organization, or software agent is who or what it claims to be?
Authority
Who is permitted to make decisions, issue instructions, or approve actions?
Access
Who can reach information, systems, infrastructure, or institutional capabilities?
Information
Which records or data sources are treated as authoritative?
Verification
Which claims can be independently checked, and which must be accepted through institutional trust?
Enforcement
What actually prevents a participant from acting outside the rules?
Together, these mechanisms create an architecture through which trust becomes operational.
Institutions Have Always Had Trust Architecture
Technology did not invent trust architecture.
A courthouse is a trust architecture.
Rules determine who may file documents, which court has jurisdiction, how evidence is authenticated, who may enter an appearance, how decisions are issued, where records are maintained, and which procedures allow those decisions to be reviewed or challenged.
A bank is a trust architecture. So is a corporation, a university, a law firm, a government agency, a securities exchange, and a professional licensing body.
Each creates rules for identity, authority, records, permissions, accountability, and dispute resolution.
What is changing is the degree to which those rules are being translated into technological architecture.
Software Turns Institutional Policy Into Executable Rules
A written policy tells participants what they are permitted to do.
Technological architecture can determine whether they are capable of doing it.
That distinction is fundamental.
A company policy might state that only particular employees may access sensitive information. An access-control system can technically enforce that restriction. A policy may require approval before money is transferred. Software can prevent the transaction from occurring until the required credentials or approvals are present. A records policy may identify an authoritative repository. System architecture can determine which database actually functions as the source of record.
NIST’s Zero Trust Architecture provides a particularly clear example. Its model separates policy decision functions from policy enforcement. A policy engine evaluates whether access should be granted, denied, or revoked, while policy administration and enforcement components implement that decision. NIST’s subsequent implementation guidance demonstrates how these principles can be translated into enterprise systems.
The example is cybersecurity-specific, but the broader institutional point is important.
Architecture can transform a rule from something participants are expected to obey into something the system itself helps enforce.
“Policy tells people what the rules are. Architecture increasingly determines what the rules allow them to do.”
Jeff Howell, Sovereignty & Law
Lawyers Have Been Thinking About This Problem for Decades
The idea that technological architecture can regulate behavior is not new.
More than two decades ago, Harvard Law professor Lawrence Lessig developed one of the most influential formulations of the concept in Code and Other Laws of Cyberspace. His argument, commonly associated with the phrase “code is law,” was not that software and law are literally identical. It was that software and hardware architecture can regulate behavior by creating permissions, constraints, and possibilities within digital environments.
Lessig later summarized the point by explaining that code can set permissions, create affordances, and block uses according to choices made by programmers.
That insight becomes more consequential as institutions become increasingly digital.
If architecture determines what users can access, what information they can see, which identities are recognized, which transactions are permitted, and which actions are technically possible, then system design is no longer merely downstream from institutional governance.
It becomes one of the mechanisms through which governance occurs.
The Designer Is Not Necessarily the Institution
This creates a new governance problem.
The institution operating within a technological system may not be the institution that designed it.
A law firm may establish its own confidentiality policies while relying on outside platforms for identity, document storage, communication, research, artificial intelligence, billing, collaboration, and knowledge management.
A corporation may establish internal governance rules while relying on software vendors to determine the technical capabilities through which those rules are implemented.
A government agency may establish legal eligibility criteria while depending on technical systems that determine how applications are submitted, identities are verified, records are matched, and decisions are communicated.
This does not mean vendors secretly govern their customers or that using third-party technology necessarily undermines institutional authority.
It means that institutional governance and technological design can no longer be treated as entirely separate domains.
An institution may write its own rules while operating inside an architecture whose permissions, dependencies, and constraints were designed somewhere else.
AI Introduces a New Kind of Institutional Gatekeeper
Artificial intelligence makes this relationship even more significant because AI systems do more than store or transmit information.
They increasingly mediate access to knowledge.
An AI system may determine which documents are retrieved in response to a question, which information is summarized, which patterns are identified, which recommendations are surfaced, or which institutional knowledge becomes practically available to a user.
The underlying records may remain unchanged while the practical experience of institutional knowledge changes substantially.
That connects directly to the earlier Sovereignty & Law analysis Who Controls the Intelligence?
If an institution increasingly experiences its own knowledge through an intelligence layer, then whoever controls the architecture of that layer may influence what information becomes visible, actionable, and useful.
Again, influence is not the same as legal authority. But practical institutional power has never depended solely on formal legal authority.
Architecture Can Centralize or Distribute Trust
Trust architecture can take many forms.
A system may concentrate authority in a central administrator. It may distribute responsibilities among multiple departments. It may require several independent approvals. It may rely on an outside provider. It may allow users to verify particular claims independently. It may use cryptographic credentials. It may combine centralized administration with distributed verification.
None of these architectures is inherently correct for every institution.
Centralization can provide efficiency, consistency, accountability, support, and rapid decision-making. Distribution can reduce single points of control, increase resilience, preserve autonomy, or make certain claims independently verifiable. Each creates different risks and different forms of dependence.
The sovereignty question is not whether trust should always be centralized or always distributed.
It is whether the institution understands where trust has been placed and what power accompanies that placement.
Trust Architecture Is Also Power Architecture
The connection between trust and power follows naturally.
If one actor controls identity, that actor may influence who can participate.
If one actor controls the authoritative record, that actor may influence which version of information governs.
If one actor controls permissions, that actor can determine who may access institutional resources.
If one actor controls the intelligence layer, that actor may influence how information becomes knowledge.
If one actor controls the ability to exit, that actor can influence how costly it becomes to choose an alternative.
None of these powers is absolute. Legal rights, contracts, competition, technical alternatives, regulation, organizational governance, and user behavior can constrain them.
But architecture helps determine the starting position from which those constraints operate.
“Where trust is concentrated, power tends to concentrate with it. Where verification and control are distributed, the architecture of power changes.”
Jeff Howell, Sovereignty & Law
The Institutional Question Is Who Controls the Rules Beneath the Rules
Institutions increasingly operate with two overlapping systems of rules.
The first is visible: statutes, regulations, contracts, policies, professional duties, governance documents, and organizational procedures.
The second is embedded: permissions, authentication requirements, database structures, software workflows, APIs, algorithms, model behavior, technical standards, and system constraints.
The first tells us how the institution says it operates.
The second increasingly determines how the institution can operate.
The rules written in policy matter. The rules embedded in architecture matter too.
As institutions become more technological, understanding governance increasingly requires understanding both.
From Trust Architecture to Digital Governance
Verification Over Trust examined how technology can change which claims must be accepted through institutional trust and which can be independently verified.
The next step is recognizing that those choices are themselves forms of institutional design.
Someone determines what the system recognizes. Someone determines what the system permits. Someone determines what the system prevents. Someone determines which rules remain human judgments and which become technical constraints.
As more institutional behavior moves through digital systems, those architectural decisions become increasingly consequential.
The next Sovereignty & Law analysis examines what happens when those technical rules begin functioning as governance: When Code Becomes Governance: The Growing Power of Digital Architecture.
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.
