Regulation patterns

Travis D. Breaux, Assistant Professor of Computer Science, Carnegie Mellon University presented interesting thoughts on regulatory patterns during the Berkeley Center of Law and Technology “Technology, Transforming the Regulatory Endeavor” symposium.

He suggested that the following regulatory “Patterns” that should be followed in drafting regulations. Regulations  should:

  1. Allow suspending the course of a prescribed action when appropriate. An example is suspending required notification during a police investigation.
  2. Allow design alternatives by giving guidance not implementation details. This allows for technology change, for example. An example might be allowing a change of notification from paper mail to email by not being prescriptive in mechanism.
  3. Support thresholds and exceptions. For example, allow substituting a notice on a web site rather than individual notices, to enable scaling.
  4. Enable indemnification. An example is to generally require use of encryption but with exception if credit card processing rules are met.
  5. Support prohibitions. For example disallow use of SSN unless already used, then require notification of continued use and allow people to prohibit its use.

Policy and Programming

I recently participated in a panel (PDF) at the Berkeley Center of Law and Technology, “Technology, Transforming the Regulatory Endeavor“.

Code can be viewed as an implicit form of regulation by embedding assumptions and decisions in the technology.

Interestingly enough, code often does not reflect regulator intent. Travis Breaux from CMU noted that engineers often miss important constraints in regulations and sometimes amplify the requirements when dealing with ambiguity in the regulations. System design can have an impact, for example direct screen writing in an OS might run counter of implicit accessibility assumptions in a regulation. Danielle Citron from the Maryland School of Law reinforced this theme, noting that programmers can distort policy through simplifications or make policy changes of their own. An example is that incorrect rules in a system design resulted in food stamps being denied to those with prior drug convictions – a decision against the law.

Automation is an issue since people tend to believe a  computer result (“automation bias”), notice is lacking, and it is hard to have a hearing without the information implicit in the software.

Has policy been unintentionally been delegated to programmers?