Scope of the Discipline · Lifecycle Stage 1 of 8
Rule Design
The governed institutional work of deciding whether a rule should exist, what legitimate result it must serve, and which boundaries and constraints its later construction must preserve.
Stage mandate
Rule Design determines whether an institution should create a rule and what that rule must be capable of accomplishing
Within the scope of Rules Integrity, Rule Design is not a synonym for drafting. It is the governed institutional work that precedes drafting: identifying the condition that requires attention, deciding whether a rule is an appropriate response, defining the outcome that justifies intervention, locating the proposed rule within the surrounding system, and establishing the boundaries within which later engineering may proceed.
The stage exists because a rule can be elegantly written and still be unnecessary, unauthorized, misdirected, disproportionate, incompatible with existing obligations, or incapable of producing the result for which it was created. Rule Design therefore addresses the quality of the institutional decision before attention shifts to the quality of the sentence.
Scope definition: Rule Design is the lifecycle stage in which an institution establishes the justified need, legitimate purpose, governing authority, intended outcome, affected system, material constraints, foreseeable consequences, and decision boundaries of a proposed rule.
1. Entry conditions
The stage should begin with a governed problem, obligation, or institutional objective
Rule Design should not begin merely because someone has drafted language or because a recent event has created pressure for an immediate response. The stage begins when an institution can identify a condition that may justify a durable constraint on behavior, judgment, access, timing, classification, or decision-making.
The initiating condition may be a legal duty, contractual commitment, safety concern, operational failure, ethical requirement, public expectation, strategic objective, technical dependency, recurring dispute, or demonstrated weakness in an existing rule system. Whatever its source, the condition should be stated in a form that can be examined. A vague instruction to “tighten controls” or “prevent this from happening again” is not yet an adequate design basis.
Entry into Rule Design should be supported by enough evidence to distinguish a genuine institutional need from a temporary reaction, individual preference, isolated anomaly, or failure that would be better addressed through training, resources, supervision, technical repair, enforcement of an existing rule, or removal of an obsolete process.
2. The design decision
The first design question is whether a new rule is the correct institutional instrument
Rules impose continuing obligations on institutions as well as on the people and systems they govern. They must be interpreted, communicated, implemented, monitored, reviewed, changed, and eventually retired. A proposal that cannot justify those costs should not advance simply because issuing a rule appears decisive.
The design decision should compare the proposed rule with plausible alternatives. An institution may need to clarify an existing rule, correct a broken workflow, improve information, redistribute authority, redesign an incentive, alter a contract, repair a system, or withdraw a conflicting requirement. The appropriate response may also be a temporary control while the underlying condition is investigated.
Choosing not to create a rule can be a disciplined design outcome. The decision record should explain why regulation is or is not warranted, which alternatives were examined, and what evidence would justify reconsideration. This prevents the absence of a new rule from being mistaken for inattention and prevents the presence of a new rule from being mistaken for resolution.
3. Purpose and outcome
Purpose must be specific enough to guide interpretation, implementation, and later review
The purpose of a rule is not ceremonial introductory language. It is the controlling account of why the institution is justified in constraining future decisions or conduct. A usable purpose statement identifies the protected interest, institutional objective, risk, right, duty, or condition that the rule is intended to address.
The intended outcome should be distinguished from the activity required by the rule. Requiring a review, approval, report, disclosure, inspection, or record is an action. The outcome may be reduced error, protected safety, informed consent, consistent treatment, preserved evidence, lawful access, or timely intervention. Confusing the activity with the outcome creates rules that can be followed mechanically while their purpose remains unfulfilled.
Purpose also constrains interpretation. When several readings are plausible, the recorded purpose helps authorized decision-makers determine which reading preserves the legitimate objective without extending the rule beyond its justification. It later provides the standard against which effectiveness, drift, amendment, and retirement can be assessed.
5. System context
The proposed rule must be examined as an addition to an existing rule environment
Institutions rarely create rules in empty space. A proposed rule enters a network of laws, regulations, contracts, policies, procedures, professional duties, data models, technical controls, informal practices, and expectations established by prior decisions. Design must identify the parts of that network that may authorize, constrain, duplicate, qualify, or conflict with the proposal.
System analysis should reach beyond the department that requested the rule. A purchasing requirement may alter vendor contracts and payment operations. A security requirement may affect accessibility, employment practice, records retention, or customer service. A clinical protocol may change staffing, documentation, technology, and professional responsibility. A rule designed locally can create obligations elsewhere.
The design record should therefore state which rule systems were examined, which owners were consulted, which dependencies are known, and where uncertainty remains. Unknown relationships should not be converted into an unsupported claim that no conflict exists.
6. Boundaries of application
The reason for the rule should determine where the rule begins and ends
Design establishes the governed population, activities, decisions, information, locations, systems, organizational units, relationships, thresholds, time periods, and triggering conditions. These boundaries should follow the purpose of the rule rather than administrative convenience or inherited wording.
Overbroad scope creates unnecessary burden, unintended rights restrictions, conflicting duties, and pressure for informal exceptions. Underinclusive scope leaves materially similar cases untreated and may permit the rule's purpose to be defeated through classification or routing. The design stage must explain why included cases are relevant and why excluded cases are materially different.
Boundary design must also account for institutional change. Mergers, new products, remote work, automated decision systems, cross-border operations, new vendors, changed legal duties, and future technical architectures may expose assumptions that were invisible when the proposal was conceived. Durable design identifies those assumptions and establishes triggers for review rather than pretending to predict every future state.
7. Evidence and participation
Design quality depends upon the evidence considered and the perspectives permitted to challenge it
Rule Design requires more than agreement among senior decision-makers. The stage should draw upon operational records, incident histories, legal analysis, contractual duties, process observation, technical constraints, outcome data, affected-user experience, and professional judgment appropriate to the consequences of the proposal.
Participation is not valuable merely because it is broad. It should be structured to reveal information that the sponsoring group is unlikely to possess. Those who perform the work can identify infeasible steps. Those who administer exceptions can reveal hidden variation. Technical teams can expose data and system limits. Legal and compliance teams can identify authority and conflict. Affected people can identify burdens, access problems, and consequences concealed by aggregate measures.
The design record should distinguish evidence from assumption, contested claims from established facts, and unresolved uncertainty from matters intentionally left to later judgment. A rule need not wait for perfect knowledge, but the institution should know what it does not know and design proportionate review mechanisms around that uncertainty.
8. Consequence analysis
The institution must examine what the rule is likely to change beyond its stated requirement
Rules redistribute time, cost, risk, discretion, access, information, and accountability. They can improve consistency while reducing flexibility, strengthen control while slowing response, or reduce one form of risk while transferring another to a different group. These effects are part of the design problem, not secondary implementation details.
Consequence analysis should consider ordinary cases, edge cases, high-volume conditions, emergency conditions, conflicting duties, incentives to evade or reclassify, burdens on vulnerable populations, and the possibility that compliance evidence will become a substitute for substantive performance. The analysis should also identify who benefits, who bears the cost, and who is authorized to resolve tradeoffs.
Not every consequence can be predicted. The design responsibility is to examine foreseeable effects, document material tradeoffs, and establish mechanisms through which unexpected effects can be detected and corrected after adoption.
9. Required outputs
Rule Design should conclude with a controlled design basis, not merely permission to start writing
A mature design stage produces a record that later participants can rely upon without reconstructing the sponsoring group's intentions. The form may vary by institution and consequence, but the substance should be identifiable and reviewable.
Problem and necessity statement
The condition requiring attention, its materiality, and why a rule is an appropriate response.
Purpose and intended outcome
The protected interest or institutional result that will guide later interpretation and review.
Authority and decision rights
The source and limits of power to propose, approve, interpret, implement, except, enforce, and change.
System and boundary map
The affected rule systems, populations, activities, relationships, technologies, and time boundaries.
Evidence and alternatives record
The material evidence, assumptions, rejected alternatives, unresolved questions, and consultations.
Consequence and review plan
The foreseeable effects, material tradeoffs, implementation dependencies, review triggers, and retirement assumptions.
10. Design gate
The proposal should advance only when its design basis is sufficient for controlled engineering
The design gate is not an approval of final wording. It is a decision that the proposal has a justified institutional basis and enough defined structure to enter Rule Engineering. The gate should confirm that the need, purpose, authority, boundaries, material relationships, expected outcomes, and major constraints are understood at a level proportionate to the rule's consequences.
A proposal should be returned, suspended, or rejected when its purpose cannot be stated, its authority is doubtful, its scope is arbitrary, its burden is disproportionate, its relationship to superior obligations is unresolved, or its implementation assumptions are materially unsupported. Pressure for speed does not remove these defects; it makes their later consequences more likely.
Design gate principle: A rule should not enter engineering until the institution can explain why the rule should exist, what legitimate result it must serve, where it may operate, and which constraints the engineered form must preserve.
11. Handoff to Rule Engineering
The handoff transfers a governed design basis, not an invitation to invent the rule during drafting
Rule Engineering converts the approved design basis into controlled rule structures, authoritative text, relationships, implementation specifications, records, and tests. Engineering may reveal design defects, but it should not silently redefine the purpose, authority, population, risk choice, or institutional tradeoff established during design.
The handoff should identify which design elements are fixed, which remain open to engineering judgment, which require further consultation, and which decisions must be returned to the authorized design body. This distinction prevents technical or drafting choices from becoming unreviewed policy decisions.
The handoff is complete when the engineering team can trace every material construction decision to the design basis and can identify the authority required when the available design record does not support a necessary choice.
12. Integrity risks
Design failure usually appears downstream as ambiguity, contradiction, burden, or drift
Institutions frequently discover design defects only after a rule has been written and implemented. Teams then attempt to repair the problem by adding definitions, exceptions, guidance, training, approvals, or technical controls. Those additions may conceal the fact that the institution never established a coherent purpose or boundary.
- reaction to a prominent event without evidence of a recurring or material condition;
- use of a rule to compensate for absent resources, authority, information, or system capability;
- purpose expressed so broadly that it cannot constrain later interpretation;
- failure to examine contracts, laws, policies, or technical controls outside the sponsoring unit;
- unrecorded transfer of risk or burden to another department, vendor, population, or jurisdiction;
- scope based on administrative categories that do not correspond to the rule's reason;
- approval of a proposal whose success cannot be observed or whose retirement conditions are unknown.
These failures cannot be corrected reliably by better prose alone. They require return to the design decision and, where necessary, withdrawal of the proposal.
13. Professional and research agenda
Rule Design is a field of institutional judgment that should become more explicit, testable, and teachable
The professional practice of Rule Design requires methods for problem definition, authority analysis, stakeholder participation, system mapping, consequence assessment, alternative comparison, decision recording, and lifecycle planning. These methods must be adaptable across public, private, contractual, professional, and technical rule systems without assuming that every domain shares the same source of legitimacy.
Research is needed to determine which design records improve later implementation, which forms of consultation reveal hidden system effects, how design quality can be evaluated without reducing it to a checklist, how uncertainty should affect review intervals, and how institutions can distinguish rules that require amendment from problems that require non-rule interventions.
A mature Rules Integrity discipline should make the design basis of consequential rules visible enough to support criticism, comparison, learning, and responsible change.
Related Education
Education chapters supporting this scope stage
This scope paper defines Rule Design as an institutional lifecycle responsibility. The Education section provides the underlying concepts and analytical instruction in greater detail.