One million friends
In October 2005, a young programmer named Samy Kamkar made more than a million friends on MySpace.
He didn’t know most of them. They hadn’t decided to become his friends, either. Many had never even visited his profile.
Yet their accounts were adding him as a friend, and then helping recruit more friends on his behalf. The process spread so rapidly that MySpace eventually had to take the site offline.
Kamkar had written a computer worm.
In the early days of social media, MySpace let users personalize their profile pages using HTML and CSS. You could change colors, backgrounds, fonts, and other elements to make your page your own.
It was a popular feature, and it worked remarkably well for what MySpace intended.
But Kamkar discovered that he could insert carefully constructed JavaScript into his profile and get it past the site’s defenses. When someone visited his page, their browser could be induced to perform actions the visitor hadn’t authorized, including adding Kamkar as a friend and copying the malicious code onto their own profile.
Each newly infected profile could then infect others.
The developers hadn’t intended for their customization feature to behave this way. They had implemented safeguards intended to prevent it.
Nevertheless, the system permitted it.
And that is the fascinating thing about software vulnerabilities. The program doesn’t have to malfunction in the ordinary sense for something to go terribly wrong. Sometimes the components behave exactly as implemented, and their interaction produces an outcome the designers never anticipated.
When programmers write software, they use programming languages that people can read and understand. But a computer’s processor doesn’t directly understand those instructions. They have to be translated into a form the processor can execute, a process called compilation.
The compiler doesn’t know what the programmer hoped to accomplish. It translates the instructions that were actually written.
And those instructions can be perfectly valid while producing results nobody anticipated.
That’s what makes the MySpace incident so interesting. The developers intended to let people customize their profiles. But the software also permitted something they never intended: a self-replicating worm.
Understanding what a system was designed to accomplish tells us why it exists. Understanding how it operates tells us what it can actually do. Those are different kinds of knowledge, and confusing them can conceal vulnerabilities even when everyone involved believes they’re following the rules.
That distinction matters far beyond computers.
What did you intend?
Years ago, while hiking with a friend, I got into an argument about the purpose of guns.
I argued that a gun’s function is to propel a projectile at high speed, making it capable of inflicting injury or damage. My friend insisted that guns could serve many purposes, including protection.
I asked how a gun protects someone.
“Because I have a gun.”
But why would having a gun discourage someone from attacking you?
“Because I have a gun.”
Around and around we went.
I was trying to describe the mechanism through which a gun could accomplish something. He was describing what he hoped to accomplish by possessing one.
Neither of us recognized that we were answering different questions.
When I later recounted the argument to my wife, she immediately recognized the misunderstanding.
We had been using the word purpose in two different ways.
Consider a hammer. Its physical function is to transfer force when you strike something. Its designer might optimize it for driving nails. But someone can use that same hammer to break a window.
Those are three different things: what the tool does, what it was designed to accomplish, and what the person using it intends to accomplish.
Usually, those things line up well enough that nobody needs to distinguish them.
But when they don’t, the difference becomes important.
A programmer intends to produce a particular result and designs software for that purpose. A user brings their own intentions. Between them lies the actual program, whose behavior is determined by its implementation and the environment in which it operates.
This is why software engineers test for behavior the developers never intended.
It’s also why security researchers approach software differently from ordinary users. They don’t merely ask what the program is supposed to do. They investigate what it can be made to do under unusual or adversarial conditions.
A feature intended to customize a MySpace profile turned out to permit a self-replicating worm.
That wasn’t a disagreement about the merits of profile customization. It was a discovery about the architecture of the system.
And we ought to be asking comparable questions about our government.
A law is a set of instructions
Congress doesn’t operate the federal government directly. It establishes laws that authorize, constrain, and direct the institutions responsible for carrying out its decisions.
Those laws resemble software in one important respect: they define what the system is supposed to do and the mechanisms through which it is supposed to happen.
Of course, government isn’t a computer. Laws are interpreted by people, exercised through institutions, and constrained by other laws and the Constitution. Ambiguity, discretion, and political judgment are unavoidable.
Nevertheless, every law creates some combination of duties, permissions, powers, conditions, and procedures.
I’ve found it useful to separate three things that ordinarily get bundled together.
The mandate is the political objective: what are we trying to accomplish?
The architecture is the arrangement of authorities, procedures, incentives, and constraints through which government is supposed to accomplish it.
And execution is what the officials and institutions operating under those arrangements actually do.
These distinctions matter because a failure in one doesn’t necessarily imply a failure in the others.
Congress might choose a perfectly clear objective but adopt a mechanism incapable of accomplishing it. An agency might faithfully follow every required procedure and still produce the wrong result. Or an official might use a power for a purpose Congress never anticipated.
One possibility requires reconsidering the objective. Another requires redesigning the mechanism. A third may require changing how the law is implemented or constraining how authority can be exercised.
Blaming everyone involved without establishing which problem occurred doesn’t tell us what needs to change.
And these problems aren’t hypothetical.
A peculiar way to prevent alcohol sales
In 2025, Utah passed House Bill 437, legislation intended in part to prevent certain people convicted of serious alcohol-related offenses from purchasing alcohol.
Courts could designate qualifying individuals as interdicted persons, and their Utah identification documents would indicate that alcohol could not be sold to them.
That sounds like a fairly straightforward policy objective.
Yet when the law took effect in January 2026, businesses and customers encountered something unexpected.
Broad identification-checking requirements meant many adults who were plainly old enough to purchase alcohol had to present identification anyway. Some establishments also had to scan it electronically.
Why require an age-verification scan for someone who obviously wasn’t underage?
Because the purpose wasn’t simply to establish the customer’s age. It was to identify people legally prohibited from purchasing alcohol.
But the electronic age-verification process did not itself determine whether someone had been interdicted. The relevant restriction appeared visibly on the new identification documents.
The mechanism and the objective were not the same thing.
Checking identification could help a business discover the restriction. Scanning identification for age verification, however, was not equivalent to checking whether the customer was interdicted.
The difference may seem minor, but it created real consequences for businesses and their customers, and Utah subsequently revised the requirements.
In software, this would be a familiar kind of problem. A developer implements a procedure believing it will accomplish an objective, only to discover that the procedure doesn’t produce the intended result under actual operating conditions.
The appropriate response is to investigate the mismatch.
Was the requirement necessary? Did it collect the information the business actually needed? Could the same objective be accomplished more reliably with fewer burdens?
Those questions don’t require anyone to oppose the underlying policy.
They require us to examine whether the design works.
And if a comparatively simple identification requirement can produce this kind of mismatch, what happens when the subject is presidential authority over international trade or military force?
The instructions we wrote decades ago
On January 3, 2026, American forces entered Venezuela and captured President Nicolás Maduro.
The operation was an extraordinary exercise of American military power. But what interests me here isn’t simply whether Maduro deserved prosecution or whether removing him served American interests.
It’s how the United States government determined that the president could authorize the operation without first obtaining congressional approval.
The Justice Department’s Office of Legal Counsel had examined that question in a December 23, 2025 memorandum.
Its reasoning depended heavily on a distinction between military operations that constitute war in the constitutional sense and operations that, although involving military force, are considered too limited in their nature, scope, and duration to require prior congressional authorization.
The memorandum argued that the president could reasonably conclude that the proposed operation fell into the second category.
This raises an intriguing question.
When the Constitution gives Congress the power to declare war, what exactly determines whether an operation counts as a war requiring congressional authorization?
Is it the objective? The expected duration? The number of troops involved? The prospect of sustained fighting? The risks of escalation?
And who evaluates those conditions before the operation begins?
The executive branch had developed a body of legal reasoning under which the president could initiate certain military operations based on national interests and assessments of their expected scale.
That reasoning did not originate with Donald Trump.
It reflects legal positions developed and used by administrations of both parties over many years.
The Venezuela memorandum drew on earlier precedents involving American interventions abroad. What changed was the situation to which the reasoning was applied.
Here, the proposed operation involved entering another sovereign country, overcoming resistance, and capturing its sitting head of state.
The administration’s lawyers concluded that it would not constitute constitutional war requiring advance approval from Congress.
Whether that conclusion is legally correct is a serious question, and the executive branch’s interpretation is not the same thing as a definitive constitutional ruling.
But even if we temporarily set aside that dispute, we can investigate the institutional arrangement.
The same branch of government proposing the operation supplied the legal analysis that permitted it to proceed.
Congress possessed constitutional powers related to war, appropriations, oversight, and legislation. Yet those powers did not produce a requirement that Congress approve the operation beforehand.
How did we arrive at that arrangement?
And what would have needed to be different for Congress to exercise an effective check?
A safeguard that depends on being used
Congress anticipated the danger of presidential military action without legislative participation decades ago.
In 1973, over President Nixon’s veto, it enacted the War Powers Resolution.
The law established reporting and consultation requirements and mechanisms intended to limit military engagements that Congress had not authorized.
Congress was trying to preserve its constitutional role in decisions about war.
But writing a safeguard into law doesn’t necessarily establish that it will work as intended.
The resolution operates within a larger constitutional and institutional system. Presidents have disputed aspects of its constitutionality. The meaning of hostilities can be contested. Congress may disagree internally about whether to intervene.
And if Congress attempts to impose a binding legal restriction after military operations have begun, it may need to enact legislation that survives the ordinary lawmaking process, including the possibility of a presidential veto.
The Supreme Court’s 1983 decision in INS v. Chadha, which invalidated a legislative-veto mechanism in another context, complicated the constitutional status of legislative-veto arrangements. Congress later revised the War Powers Resolution’s termination mechanism to rely on a joint resolution.
Think about that arrangement for a moment.
The president initiates military action. Congress seeks to stop it. But the legal instrument Congress uses may require the president’s signature—or enough votes to override the president’s veto.
That doesn’t make congressional intervention impossible. Congress retains important constitutional powers, and the precise legal mechanisms matter.
But it changes what is required for a safeguard to operate.
Congress can have the authority to restrain executive action without having an effective, easily usable mechanism for exercising it in a particular situation.
And congressional decision-making introduces another layer.
Party leadership influences which legislation reaches the floor, which members receive desirable assignments, and what political costs dissenting members may encounter. Members must weigh their individual judgments against electoral pressures, party interests, legislative opportunities, and the preferences of their constituents.
A representative may possess the formal power to oppose an administration and nevertheless face institutional incentives that make doing so difficult.
None of this establishes that every failure to check the president results from coercion or defective procedure. Sometimes lawmakers simply support what the president is doing.
That’s precisely the distinction an investigation should make.
We need to know whether Congress chose not to intervene, whether its members were prevented from producing a collective decision, or whether a decision they managed to produce lacked the legal force needed to change the outcome.
Those are different mechanisms.
And they cannot all be corrected by electing a different president.
What changed when we declared an emergency?
Another revealing example comes from an entirely different area of government: tariffs.
In 1977, Congress enacted the International Emergency Economic Powers Act, known as IEEPA.
The law granted the president substantial authority to regulate specified economic transactions in response to an unusual and extraordinary foreign threat during a declared national emergency.
Its purpose was not to establish an ordinary presidential power to rewrite American tariff policy.
Nevertheless, the Trump administration invoked IEEPA to impose broad tariffs on imports.
The dispute eventually reached the Supreme Court.
On February 20, 2026, the Court held that IEEPA did not authorize the president to impose those tariffs.
Here is an important example of an institutional safeguard operating: the judiciary reviewed an executive claim of statutory authority and rejected it.
Yet the case also illustrates the difference between what a law was designed to accomplish, what the executive claimed it permitted, and what the courts ultimately determined it authorized.
For a period of time, a contested interpretation became the operating basis for consequential economic policy.
The ruling did not eliminate every statutory avenue for presidential tariffs. Other trade laws separately grant tariff-related powers under specified conditions.
So one legal avenue was closed, while the broader question remained: how much authority should Congress delegate to the president to alter trade policy, under what circumstances, and with what safeguards?
The fact that a court eventually rejects a particular application doesn’t answer whether the system’s earlier safeguards were adequate.
Nor does it prove that Congress intended the result.
It tells us that the executive attempted to exercise a power, that litigation challenged the claimed authority, and that the Court ultimately found the statute did not grant it.
Those are findings from which a more complete institutional investigation can begin.
The interactions matter
Now consider what these examples have in common.
Utah established a mechanism intended to prevent prohibited alcohol sales. Its implementation created requirements whose relationship to the objective proved less straightforward than lawmakers apparently anticipated.
The executive branch used a longstanding interpretation of presidential military authority to justify an operation in Venezuela without advance congressional authorization.
Congress’s war-powers safeguards existed, but their practical operation depended on disputed legal interpretations and the institutional capacity to produce binding legislative action.
An emergency economic-powers statute became the basis for a presidential tariff program until the Supreme Court ruled that the law did not authorize it.
These are not identical failures.
Indeed, whether each event represents a failure depends partly on the standard being evaluated. An executive might accomplish its immediate objective while undermining a constraint Congress intended to establish. A court might successfully check an asserted power, but only after the disputed policy has operated. A statute might work as enacted yet impose costs lawmakers failed to anticipate.
That’s why identifying a disliked political outcome is not enough.
We need to reconstruct the sequence.
What did lawmakers intend? What did they actually authorize? How did officials interpret and use that authority? Which constraints applied? Which institutions could intervene? What happened when they tried—or chose not to?
The United States and Israel began military operations against Iran on February 28, 2026. Those operations developed into a wider regional conflict, prompting renewed debate over presidential war powers and congressional authorization.
The question of whether the military campaign was justified deserves its own examination.
But another question runs alongside it.
What institutional arrangements allowed the executive to initiate and sustain these operations, and what means did Congress possess to direct, constrain, or terminate them?
To answer that, we need more than a catalog of presidential statements and statutory provisions. We need to examine the interactions among constitutional powers, executive legal interpretations, congressional procedures, appropriations, and the political incentives affecting legislative action.
An accident investigator would not examine a failed component in isolation from the systems connected to it. Government deserves the same discipline.
What would an accident report tell us?
Imagine an investigation into the Venezuela operation conducted with the rigor we expect from a transportation accident investigation.
It would reconstruct the sequence of decisions, identify the legal authorities invoked, examine the available evidence and contemporary reasoning, distinguish disputed claims from established facts, and assess the institutional safeguards intended to constrain the operation.
It would investigate whether the safeguards operated as designed.
And, importantly, it would not begin by assuming that every presidential action it examined was unlawful or that every unfavorable political outcome reflected a defect.
Its conclusions would follow the evidence.
The resulting report might find an inadequate statutory constraint, a disputed but longstanding interpretation of constitutional authority, a failure of legislative procedure, or an entirely deliberate congressional decision to permit the outcome.
It might find some combination of these.
And its recommendations would depend on what the investigation established.
Perhaps a statute needs a more precise definition or a clearer limit. Perhaps Congress needs a procedure that allows members to exercise an existing constitutional power more effectively. Perhaps the executive should face an additional reporting requirement, or perhaps the existing mechanism worked and the remaining disagreement concerns the political objective itself.
There would also be an important boundary to the investigation. Just as the NTSB doesn’t prosecute pilots or determine criminal guilt after an aviation accident, the GDA wouldn’t determine whether a government official had committed a crime. Evidence of potentially unlawful conduct could be referred to the appropriate authorities, while legal responsibility would remain a matter for prosecutors and courts.
An investigation could reveal serious design problems even if nobody had committed a crime. And prosecuting someone for misconduct wouldn’t necessarily correct the conditions that permitted it.
Those are separate questions, requiring separate institutions.
The GDA’s task would be to understand what happened and identify possible improvements.
Those alternatives could be studied, compared, and made available for public examination.
Citizens could see what went wrong, what remained uncertain, and which institutions were responsible for making changes. They could contribute evidence, question proposed designs, and communicate their preferences to their representatives.
Congress would still make the political decisions.
The executive would still carry out the laws.
The courts would still resolve the legal questions properly before them.
But we would have a better way to distinguish a failure of policy from a failure of design or execution.
We’ve been debugging the wrong thing
Most public discussions about government failure eventually return to the character of the people in office.
If we could elect better politicians, appoint more competent officials, or persuade people to act with greater integrity, perhaps government would work as intended.
Character and competence certainly matter. A good institutional design cannot make every bad decision impossible.
But the reverse is also true.
Good intentions cannot compensate for every defective mechanism. An honest official can operate within a poorly designed system and produce harmful outcomes. A conscientious legislator can possess a constitutional power that is extraordinarily difficult to exercise in practice.
And a system that works acceptably under one administration may reveal dangerous weaknesses when operated by another.
The solution cannot depend entirely on everyone who exercises public authority choosing to behave as we hope.
That was part of the founders’ insight.
James Madison warned that constitutional boundaries alone could become mere parchment barriers. A functioning republic required institutions whose powers and incentives were arranged to make the constitutional structure effective.
Madison was thinking about institutional architecture long before we had the scientific vocabulary and tools available to study complex systems today.
Since then, we have developed remarkable ways to investigate failures and improve the things we build.
When aircraft crash, we reconstruct the sequence of events. When software is compromised, we trace the exploited vulnerabilities. When an engineering design fails, we examine its assumptions and operating conditions.
We don’t always discover a single cause. Sometimes the investigation reveals multiple contributing conditions, each of which appeared manageable on its own.
And we don’t need to abandon the original objective to improve the design.
An aviation accident doesn’t mean that we should stop flying. A software vulnerability doesn’t mean that we should abandon computers.
Likewise, discovering a defect in the mechanisms of representative government doesn’t mean that representative government was a mistake, or that we need to tear the entire system down.
It means we need to understand what failed, why it failed, and how to make it work better.
This is why I founded The Statecraft Blueprint, and why I’ve proposed a Governance Design Agency: an independent institution that would investigate failures of government, evaluate possible remedies, and make its findings available to the people.
The goal is not to replace political judgment with engineering judgment. It’s to give the public and its representatives better evidence about the consequences of the choices they make.
We’ve spent a great deal of time arguing about whether the people operating government are doing what they should.
It’s time we gave equal attention to whether the government we’ve designed allows them to do what we intended.
Because a computer cannot execute what its programmer merely hoped would happen. It can only execute the instructions it was given.
Government is more complicated than software. But the lesson still applies: writing down what we want to accomplish is not the same as creating a system capable of accomplishing it.
Because intent, by itself, doesn’t compile.
Governance Design Agency: an independent institution that would investigate failures of government, evaluate possible remedies, and make its findings available to the citizens. it gives the public and its representatives better evidence about the consequences of the choices they make.