Most regulation is discussed as if the work ends when a law is enacted or a rule is published. In practice, that is when the real work begins.
The public does not experience regulation as statutory language. People experience applications, eligibility determinations, inspections, renewal notices, call centers, payment systems, enforcement decisions, and appeals. Regulated organizations experience the same system from the other side: forms, document requests, review queues, deadlines, portals, and changing interpretations.
Those operational details are not separate from policy. They determine what the policy becomes in the real world.
I have seen this from both sides: inside public-sector oversight and inside organizations trying to enter and operate in regulated markets. The same pattern appears repeatedly. A policy can have a sound objective and clear legal authority, yet still fail because the operating system around it was never fully designed.
Good regulation therefore requires more than good intentions and careful legal drafting. It requires operational design.
Every regulation creates an operating model
A regulation assigns responsibilities, whether its authors describe them that way or not.
Someone must decide who is covered. Someone must interpret the standard, collect evidence, review submissions, communicate deficiencies, approve exceptions, conduct inspections, investigate complaints, and impose consequences. Someone must also maintain the technology, staffing, training, and records that support those decisions.
If those responsibilities are unclear, the ambiguity does not disappear. It moves downstream. Frontline staff develop informal workarounds. Applicants receive different instructions from different reviewers. Backlogs grow. Organizations learn to navigate personalities instead of standards. Enforcement becomes inconsistent, and the public begins to experience the system as arbitrary.
The first operational question should therefore be simple: What decisions must this policy produce, and who is responsible for making each one?
That question forces policymakers to move from aspiration to administration. A requirement that providers be “qualified,” for example, is not yet an operating standard. The system still needs to define acceptable credentials, required experience, disqualifying conditions, verification methods, renewal rules, and the process for resolving incomplete or conflicting information.
Until those details are designed, the regulation is not finished.
Standards must translate into observable evidence
Regulation works best when the connection between the public purpose and the required evidence is easy to understand.
If the objective is financial stability, what information actually demonstrates that an organization can continue operating? If the objective is competent leadership, which qualifications predict the ability to manage the regulated service? If the objective is consumer safety, which policies, training records, staffing practices, or outcomes show that the protection exists in practice?
Weak operational design often substitutes documentation for assurance. Agencies request a large volume of material because each document seems relevant on its own, but the complete package does not necessarily answer the central question. Applicants spend time producing paperwork. Reviewers spend time checking it. The public may receive little additional protection.
The answer is not simply to eliminate requirements. It is to make each requirement carry its weight.
A well-designed system can explain why information is needed, what standard it supports, how it will be evaluated, and what happens if it is missing. That clarity improves both compliance and enforcement. It also makes it easier to identify obsolete requirements that create effort without improving outcomes.
Sequence is a policy choice
Many regulatory failures are really sequencing failures.
An organization may need a physical location before it can apply for a license, but may be unwilling to sign a long-term lease without knowing whether the license is obtainable. A worker may need a background check tied to an employer that cannot legally employ the person until another approval is issued. A provider may receive permission to deliver a service but wait months for the separate enrollment required to bill for it.
Each requirement may be reasonable in isolation. The combined sequence can still create unnecessary cost, delay, and risk.
Policymakers should map the entire journey, not just the portion administered by one office. That means identifying dependencies across agencies, local governments, vendors, insurers, and payment systems. It also means deciding which steps can occur simultaneously, which must occur in order, and which forms of provisional approval are appropriate.
This is especially important when multiple public entities regulate different parts of the same activity. From the perspective of the applicant or consumer, government is one system even when authority is divided across several agencies. Fragmentation inside government should not become invisible complexity imposed on everyone outside it.
Friction should serve the public purpose
Good regulation is not frictionless. Some friction is intentional and necessary.
Background checks take time. Inspections require preparation. Financial disclosures can be burdensome. Public comment, notice, appeal rights, and due process can slow decisions. These steps may be justified because they protect safety, fairness, public funds, or individual rights.
The important distinction is between protective friction and accidental friction.
Protective friction advances the purpose of the regulation. Accidental friction comes from unclear instructions, duplicative requests, incompatible systems, avoidable handoffs, unpredictable review practices, or a lack of staffing. Both feel burdensome to the person navigating the system, but only one produces public value.
Operational design makes that distinction visible. It asks where time is being spent, why a step exists, which risks it addresses, and whether a less costly method could provide the same protection.
The goal should not be deregulation by inconvenience reduction. The goal should be regulation that is demanding for a reason.
Administrative capacity is part of policy
New requirements are often adopted without a realistic assessment of who will administer them.
If a rule creates hundreds of additional reviews, the agency needs reviewers. If it requires specialized judgments, staff need training and usable decision criteria. If it depends on data from another system, the systems need to communicate. If regulated organizations must submit information electronically, the portal needs to support the actual workflow.
Under-resourced administration produces predictable consequences: long queues, rushed reviews, inconsistent communication, and delayed enforcement. These are often described as implementation problems, but they originate in policy decisions that failed to account for operational capacity.
This is why fiscal notes, staffing plans, implementation timelines, and technology requirements should be treated as substantive parts of regulatory design. A policy that cannot be administered reliably is not a strong policy merely because its text is strong.
Good systems learn after launch
No regulatory system will be perfect on the day it begins. The better question is whether it can detect and correct its own weaknesses.
Agencies should know where applications stall, which requirements generate repeated confusion, how long each stage takes, why submissions are denied, whether similarly situated parties receive similar decisions, and whether regulated outcomes are improving.
That requires feedback from frontline staff, regulated organizations, consumers, advocates, and enforcement teams. It also requires the willingness to change forms, guidance, workflows, and sometimes the rule itself.
Without those feedback loops, temporary workarounds become permanent. Old requirements accumulate. Reviewers inherit practices without knowing why they began. The system becomes harder to navigate and harder to defend.
Good regulation is not static. It preserves its public purpose while improving the machinery used to achieve it.
Operational design is substantive policy
The strongest regulatory systems share a few qualities. Their standards are understandable. Their evidence requirements are connected to risk. Their responsibilities and sequences are visible. Their agencies have the capacity to administer them. Their enforcement is consistent. Their processes can learn from experience.
None of that replaces democratic debate, legal authority, or subject-matter expertise. It makes those things real.
Policy establishes what society is trying to protect or achieve. Operational design determines whether the system can actually do it.
Good regulation depends on both.