Legislative Reform

improving the US legal system

Managing Law

The mechanics of writing and maintaining law in the US leave something to be desired. I have some observations about problems, and suggestions for fixing them.

Incorporate Metadata

Laws are written in a specialized language resembling English. It's very difficult to interpret laws accurately without training and a lot of experience in a legal profession. It is very similar, in this way, to computer source code. The language written in the law books is merely a representation, or implementation, of ideas -- not the true form of those ideas. That's why legal battles arise over ambiguities, and the Supreme Court then makes rulings on what it calls the "spirit of the law". Someone encounters an omission, or a bug, in the law, and it becomes necessary to reverse-engineer the code. The court attempts to guess what a law was trying to accomplish, and why it was written, and then decide (based on this speculation) what to do.

I propose that the intent of a law, among other extra data, be included with each law. That way, the law could specify what and why up front, and then later go into the details of how.

I propose including the following extra data with each law:
  • Intent. This explains what the law is designed to accomplish, and why.
  • Implementation. This details, in usual legalese, how to implement the law. It contains the code which makes the law work.
  • Reasoning. Explain why the given implementation will accomplish the law's stated goals.
  • Dependencies. Describe relations to other laws, such as requiring another law in order to be valid, or conflicting with another law.
  • Author(s). A list of people involved with creating the law, and details of their contributions.
  • Notes. Miscellaneous extra data, as appropriate.
  • ID. Each law needs a unique ID, so it can be referenced easily.
  • Dates. Required would be the date the law was proposed, the date it was voted on, the date it goes into effect, and the date it expires. Other dates may be included too, if necessary.
  • Voting Results. After a change is voted on, the detailed results of that vote should be recorded along with the law. For example, if the Senate votes on a proposal, keep a record of what each person's vote was. If it is a public vote, record the end results, perhaps also including data per county.
I feel it's also important to point out that many sections should include references. Linking to appropriate research and such are standard practice in any respectable science, and government should be no different.
Auditing, Verification of Results
Once the extra data is included in each law, the correct functioning of the law should be periodically verified. In short, investigate whether the details of the law match its "spirit", and whether its result is in line with its intended result. If not, revise the law or throw it out.

No Riders

Completely eliminate the practice of "rider laws" attached to other bills.

Many large bills get passed, composed of many related (or unrelated) parts. A standard way of getting a corrupt or unpopular law passed is to simply tack it onto a well-supported bill, and letting it "ride along". This is not the only way, of course, but it seems to be one of the easiest and most common.

The intent of eliminating riders is twofold: To reduce the amount of corrupt proposals which slip into law, and to encourage modularity in law. Modularity is one of the most important concepts in computer science, as a "best practice" and guideline. These "best practices" of information theory should be included in the development and maintenance of law, because the fields are so similar.

Automatic Sunsets

Give each law a duration, after which time it expires. This applies to all laws. In order to keep the law after that time, it must be renewed. To help keep things sane, allow a time window to renew the law... perhaps any time during the last 10% of its current term.

The point of doing this is to cull obsolete and unnecessary laws. The most important ones will stay in effect, of course, but questionable laws, or laws governing minor problems, will not last long. This will probably have other effects as well: Shifting more laws to lower levels, such as federal to state, or state to city. It will also likely reduce the size of the government, by continuously eliminating bloat.
Duration Based on Concordance
A further suggestion is to set the duration of each law based on how well it was supported during a vote. The point of doing this is to avoid constantly re-voting on things everyone agrees on, and spend time re-evaluating controversial issues instead.

This could work in two ways:
  • Determine duration based on popularity. Simply take the percentage of supporters and translate it to a duration. For example, 55% may last for 2 years, while 75% lasts for 6 years, and 95% lasts for 15 years.
  • Require various levels of agreement for each duration. In other words, the person who proposes a law determines how long it will last, but the longer the duration, the higher vote percentage required to pass it. If you are confident that you can get 80% of the votes, propose a duration of 8 years. But if you think you don't have many supporters, propose a 1-year or 2-year duration.

Revision Control

Keep all laws in a revision control system, so that anyone may look up what the complete legal environment was on any date, and see changes made throughout history.
Repository Integrity
Such a system will need to be implemented in a way that is designed to withstand attack, prevent tampering, and recover from failure. This is an area of active research, with good results. Projects such as freenet stand up nicely to almost any attack. Also, distributed backups will help in the case of failure, and provide a way to audit and verify data has not been modified.

Online Public Access

Make all laws available and easily accessible. This probably means putting them online, in various forms: web pages, source documents, etc.

Open-Source Methodologies

Required Reading

Require our elected officials to read laws before voting on them. Bonus points if they also research the bill by polling their constituents about it.

Review process

Slashdot had some interesting ideas on treating the law-making process more like the software development process: link


Last modified: February 11, 2008 @ 1:25 MST
Copyright (C) 1996-2017 Selene Scriven