Principles of Rule Design

1. Design before drafting

A well-written sentence can still be a badly designed rule

Drafting concerns expression: the words, structure, definitions, references, and organization through which a rule is communicated. Design concerns the substance beneath that expression. It determines the problem, purpose, authority, scope, behavioral mechanism, tradeoffs, evidence, and lifecycle of the rule.

Official drafting systems reflect this distinction. The U.S. Office of the Federal Register separates questions of organization, purpose, definitions, ambiguity, clear writing, and cross-references in its regulatory drafting guidance.² ISO drafting directives seek documents that are clear, precise, and unambiguous, but those qualities presuppose that the underlying requirement has been properly conceived.¹

The sequence is not always linear. Testing may expose a defective purpose. Stakeholder review may reveal that the proposed authority is insufficient. A conflict analysis may require narrowing the scope. Design is iterative, but the major decisions should be made consciously and recorded.

2. Define the problem

The rule should address a problem that is real, material, and understood

Rulemaking frequently begins with a proposed solution: require approval, prohibit an activity, add documentation, establish a deadline, or create a penalty. Strong design begins earlier by defining the condition that requires intervention.

A useful problem statement identifies:

• the conduct, failure, uncertainty, risk, or coordination need at issue;
• the people, systems, interests, or obligations affected;
• the frequency, scale, and materiality of the problem;
• the evidence supporting its existence;
• the causes and contributing conditions;
• the consequences of taking no action;
• the boundaries of what is not being addressed.

“Employees are careless with data” is not a sufficient problem definition. It labels behavior without identifying where errors occur, why they occur, which information is exposed, what controls already exist, or whether system design is contributing. A rule based on that diagnosis may impose general restrictions while leaving the actual cause untouched.

Problem definition should distinguish symptoms from causes. Repeated late reports may result from unclear ownership, unavailable source data, conflicting priorities, unrealistic deadlines, or deliberate disregard. Each cause suggests a different institutional response. A deadline rule may address only the symptom.

3. Define the intended outcome

A rule needs a purpose that can guide interpretation and review

The intended outcome explains why the rule exists. It may be to protect a right, prevent injury, preserve evidence, ensure continuity, reduce fraud, coordinate work, improve accuracy, or create fair and predictable treatment.

The outcome should be more precise than a broad aspiration. “Improve security” is too open-ended to guide design. “Prevent unauthorized alteration of approved payment instructions before execution” identifies a more specific risk and allows designers to evaluate whether dual approval, access separation, transaction confirmation, or another mechanism is appropriate.

Purpose also aids interpretation. When wording admits more than one plausible reading, the documented objective can help determine which reading preserves the rule's legitimate function. Purpose cannot override clear superior authority, but it can prevent mechanical interpretations that defeat the reason the rule was created.

Outcomes should be distinguished from outputs. A completed form, an approval record, or a training certificate is an output. Reduced error, informed consent, preserved confidentiality, or dependable service is an outcome. A rule should not be judged successful merely because its administrative outputs are present.

4. Necessity and proportionality

Use no more rule than the problem requires

Necessity asks whether a rule is needed at all. Proportionality asks whether the scope, burden, restriction, process, and consequence are reasonably related to the importance and likelihood of the problem.

Regulatory-impact frameworks commonly require decision-makers to identify the need for intervention, compare alternatives, and examine positive and negative effects before choosing a regulatory response.^{4 5} The same discipline is useful inside private and nonprofit organizations.

Alternatives may include:

• better information or disclosure;
• training and professional development;
• process or interface redesign;
• technical safeguards;
• incentive changes;
• supervision or targeted review;
• a principle or guidance rather than a binding rule;
• a narrower rule limited to high-risk conditions.

Proportionality does not mean weak enforcement. Serious risks may justify strict controls. It means that the strength of the response should be supported by the nature of the risk and should account for competing rights, costs, and operational consequences.

5. Authority and legitimacy

The designer must know who may create the rule and why others should accept it

Authority should be established before detailed drafting begins. Otherwise, an organization may spend substantial effort designing a rule that the proposed issuer has no power to adopt.

The design record should identify:

• the source of authority;
• the subject matter covered by that authority;
• required consultation, approval, notice, or publication;
• limits imposed by superior law, contract, charter, or policy;
• whether authority may be delegated;
• who will own interpretation and amendment after adoption.

Legitimacy also includes the quality of the process. A rule may be formally authorized but poorly accepted because affected expertise was ignored, the rationale was concealed, or the burden was distributed unfairly. Participation does not mean every affected person must agree. It means that relevant knowledge and consequences are considered before authority is exercised.

6. Scope and context

A rule should apply exactly where its reason applies

Scope determines who, what, where, when, and under which conditions a rule governs. Overbroad rules impose unnecessary burdens and create exceptions. Narrow rules leave material gaps or invite avoidance.

Designers should define scope across several dimensions:

Scope should follow purpose. A rule created to control high-risk vendor access should not automatically govern every low-risk supplier. A rule intended for regulated records should not be extended to all information merely because the same storage system is used.

Cross-references and incorporated definitions must be controlled carefully. The Office of the Federal Register's drafting guidance specifically treats definitions, ambiguity, and cross-references as matters affecting clarity and enforceability.² A rule whose scope depends upon inaccessible or unstable references is not operationally complete.

7. Clarity and precision

Readers should be able to identify what the rule requires without reconstructing the author's intent

Clarity is not merely simplicity. A short statement may be vague, while a longer statement may be precise. The goal is language proportionate to the complexity of the subject.

Clear rule design generally requires:

• an identifiable subject or responsible actor;
• a consistent modal verb for requirement, permission, prohibition, or recommendation;
• a defined action and object;
• conditions, triggers, and timing stated near the requirement they qualify;
• defined technical or specialized terms;
• consistent terminology for the same concept;
• limited and controlled cross-references;
• exceptions stated so their relationship to the general rule is visible.

The U.S. Document Drafting Handbook distinguishes must for a requirement, should for a strong recommendation, may for an option, and can for capability or possibility.³ Consistent modal language reduces uncertainty about normative force.

Precision must not create false certainty. Terms such as “reasonable,” “material,” or “promptly” may be necessary where judgment is unavoidable. Their use should be supported by criteria, examples, decision authority, documentation, or review rather than pretending that every situation can be reduced to a number.

8. Consistency and hierarchy

A new rule must be designed as part of an existing rule system

Rules interact through hierarchy, shared definitions, dependencies, overlapping scope, sequence, thresholds, exceptions, and implementation. A proposed rule can be clear in isolation and still damage the system.

Consistency review should compare the proposal with:

• superior law, regulation, contract, charter, and policy;
• rules governing the same actor, activity, information, or decision;
• shared definitions and classification schemes;
• existing permissions and prohibitions;
• deadlines, thresholds, retention periods, and approval levels;
• exception and escalation paths;
• technical controls that currently implement related rules.

A stricter internal rule is not automatically inconsistent with an external minimum. It may be a deliberate risk choice. The designer should record that the stricter position is intentional, authorized, operationally feasible, and not in conflict with rights or obligations that require the less restrictive treatment.

Consistency also requires vocabulary discipline. Two rules may use different words for the same concept or the same word for different concepts. Both forms of semantic inconsistency can produce divergent decisions.

9. Feasibility and operational reality

A rule that cannot be followed reliably is not strengthened by being mandatory

Feasibility asks whether affected actors can perform the rule under real conditions. The question includes more than physical possibility. It includes authority, information, staffing, time, technology, training, cost, workflow, and access to the required evidence.

A rule may be infeasible because:

• the responsible role does not possess the required authority;
• necessary information does not exist or arrives too late;
• systems cannot record or enforce the required distinction;
• deadlines conflict with upstream processes;
• compliance requires resources that were never funded;
• the rule assumes expertise affected actors do not possess;
• high-volume conditions make case-by-case review impossible.

Infeasible rules generate workarounds, concealment, selective enforcement, and disrespect for the broader rule system. Before adoption, designers should observe the real workflow, test representative cases, and speak with those who must apply the rule—not merely those who approve it.

10. Exception design

Exceptions should preserve the rule's purpose when ordinary application would fail

Exceptions are not signs of weak design when they address legitimate conditions that differ materially from the ordinary case. They become weaknesses when they are vague, unlimited, undocumented, or used to avoid confronting an overbroad general rule.

A designed exception should identify:

• the condition that makes ordinary application inappropriate;
• who may request and approve the exception;
• the evidence required;
• the duration and scope of the departure;
• alternative protections or controls;
• documentation, notification, and review;
• whether renewal is permitted;
• when recurring exceptions require revision of the general rule.

11. Measurement and evidence

The rule should define how application and effect can be examined

Designers should know what evidence will show that the rule applied, that the required decision or action occurred, and that the intended outcome was supported. These are separate questions.

Evidence may include records, approvals, timestamps, system events, inspection results, exception logs, outcome measures, complaints, error rates, or review findings. The evidence requirement should be proportionate and should not become the dominant burden of the rule.

Measurement can distort behavior when the measure becomes a substitute for the purpose. If timeliness is measured only by closure, actors may close unresolved cases. If quality is measured only by error counts, people may avoid documenting errors. Designers should identify likely gaming behavior and use multiple forms of evidence where a single metric is vulnerable.

A rule that cannot be measured precisely may still be valid. Professional, ethical, and reasonableness standards often require qualitative judgment. The design should then establish who judges, which factors matter, what record is required, and how consistency is reviewed.

12. Consequences and incentives

People respond to the rule as implemented, measured, and enforced—not merely as written

Every rule creates incentives. Actors may change timing, classification, documentation, routing, or disclosure to obtain a preferred result or avoid a burden. Some responses are legitimate adaptation. Others technically satisfy the rule while defeating its purpose.

Designers should examine:

• which behaviors the rule rewards or discourages;
• whether responsibility and authority are aligned;
• whether consequences are predictable and proportionate;
• whether actors can manipulate thresholds or classifications;
• whether enforcement is likely to be selective;
• whether reporting a problem creates personal disadvantage;
• whether the rule shifts risk to another department or population.

Consequences should support correction and protection, not merely punishment. Repeated failure may require stronger action, but automatic penalties can suppress reporting, discourage legitimate exceptions, and obscure system causes.

13. Durability and adaptability

Design for change without making the rule unstable

Durable rules are anchored in stable purposes and concepts rather than temporary organizational arrangements. A rule that names a specific system screen, office, or job title may become obsolete after a routine reorganization even though the underlying responsibility remains.

Adaptability can be designed through:

• clear ownership and review cycles;
• effective dates and transition periods;
• version control and change records;
• criteria for amendment, suspension, or retirement;
• controlled delegation for technical details;
• temporary emergency provisions with expiration;
• monitoring of legal, contractual, operational, and technological dependencies.

Flexibility should not be achieved by vague wording alone. A rule that says a manager may act “as appropriate” avoids obsolescence by transferring nearly all design to the moment of application. Responsible adaptability preserves defined purpose, authority, factors, evidence, and review while allowing the response to fit changing conditions.

14. Pre-adoption testing

A rule should be tested against cases before it governs them

Rule testing exposes ambiguity, conflict, infeasibility, and unintended effects before they become institutional failures. The test set should include ordinary cases, boundary cases, exceptions, conflicting obligations, incomplete information, high-volume conditions, emergency conditions, and foreseeable future changes.

Testing should involve people from different roles. Authors often understand what they intended and unconsciously fill gaps. Affected users, reviewers, system designers, legal advisers, auditors, and operational staff expose different forms of uncertainty.

15. When a proposed rule should be rejected

Not every draft should be repaired

Revision is appropriate when the purpose is legitimate and the defects can be corrected. Rejection is appropriate when the foundation is unsound.

A proposed rule should ordinarily be rejected or returned for redesign when:

• the problem is unsupported, isolated, or materially misunderstood;
• the proposed issuer lacks authority;
• the rule conflicts with superior obligations and no lawful reconciliation exists;
• a less burdensome alternative would address the problem more effectively;
• the required conduct is operationally impossible or depends upon unavailable information;
• the scope is unrelated to the demonstrated risk;
• the likely incentives would defeat the stated purpose;
• compliance cannot be evaluated fairly;
• the burden or harm is disproportionate to the expected benefit;
• no owner, implementation plan, or lifecycle responsibility exists.

Refusing a poorly designed rule is not resistance to governance. It is protection of the rule system from unnecessary complexity, contradiction, and loss of trust.

16. Common failure cases

Design failures appear before drafting failures

17. Rule design review

Fifteen questions before approval

1. 01

   Problem

   Is the problem defined through evidence rather than assumption or reaction?

2. 02

   Purpose

   Is the intended outcome specific enough to guide design, interpretation, and review?

3. 03

   Necessity

   Has the organization shown that a binding rule is preferable to less restrictive alternatives?

4. 04

   Authority

   Does the proposed issuer possess authority over the subject, actors, and consequence?

5. 05

   Scope

   Does the rule apply only where the purpose and evidence justify application?

6. 06

   Structure

   Are subject, modality, action, object, conditions, timing, and exceptions identifiable?

7. 07

   Clarity

   Would affected readers independently reach materially similar interpretations?

8. 08

   Consistency

   Has the rule been compared with superior authority, related rules, definitions, thresholds, permissions, and prohibitions?

9. 09

   Feasibility

   Can the rule be followed with available authority, information, systems, staffing, time, and resources?

10. 10

    Proportionality

    Are burden, restriction, process, and consequence reasonably related to the need?

11. 11

    Exceptions

    Are legitimate exceptional cases identified with controlled authority, evidence, duration, and review?

12. 12

    Incentives

    How might actors avoid, game, redirect, or technically satisfy the rule while defeating its purpose?

13. 13

    Evidence

    Can application, compliance, exceptions, outcomes, and adverse effects be examined?

14. 14

    Testing

    Has the rule been tested against ordinary, boundary, failure, conflict, scale, and future-change cases?

15. 15

    Lifecycle

    Are implementation, ownership, review, amendment, suspension, replacement, and retirement defined?

18. Worked examples

From reaction to designed rule

The revised rule uses risk characteristics rather than universal approval. It still requires definitions, thresholds, delegation, evidence, and exception design, but the institutional mechanism now follows the reason for intervention.

Conclusion

A trustworthy rule is designed as part of a living system

Strong rule design begins with evidence and purpose, not wording. It determines whether a rule is necessary, whether the issuer has authority, where the rule should apply, how it relates to existing obligations, whether people can follow it, how exceptions operate, what incentives it creates, and how its effects will be measured.

The design must balance clarity with legitimate judgment, consistency with adaptation, protection with burden, and present needs with future change. These balances cannot be resolved by a single universal formula. They can be made explicit, tested, documented, and reviewed.

Rules Integrity treats rule design as a responsibility because every new rule changes the system into which it enters. It may create obligations, remove options, alter authority, shift risk, establish evidence, and affect people far beyond the event that prompted its creation.