I remember overhearing someone exclaim “A Bill is a Bill is a Bill” many years ago. What she meant is that a bill should be treated as a bill in the same way regardless of the system it flows through.

I’m going to borrow her exclamation to refer to something a bit different by rephrasing it slightly. Is a bill a Bill and a akn:bill? Lately I’ve been working in a number of different jurisdictions, and through my participation on OASIS and the LEX Summer School, with many other people from even more jurisdictions. It sometimes seems that everything bogs down when it comes to terminology. In the story of Babel, God is said to have divided the world into different languages to thwart the people’s plans to build the tower of Babel. Our problem isn’t that we’re all speaking different languages. Rather it’s that we all think we’re speaking the same language but our definitions are all different.

The way the human brain learns means that we learn incrementally. I remember someone once telling me that you can only know that which you almost knew before. When we try and learn a new thing, we cling to the parts we think we understand and our brain filters out the things we don’t. Ever learn a new word and then realize that its being used all around you every day – but you seemingly had never heard it before? So what happens when we recognize terms that are familiar, but fail to notice the details that would tell us that the usage isn’t quite what we expect? We misinterpret what we learn and then we make mistakes. Usually, through a slow process of trial and error, we learn from our mistakes and eventually we master the new subject. This takes time, limiting our effectiveness until our competency rises to an adequate level.

Let’s get back to the notion of a bill. Unfortunately in legislation, there is often a precise definition and an imprecise definition for a term and we don’t always know which is being used. What’s worse, if we’re not indoctrinated in the terminology, we might never realize that there is ambiguity in what we are hearing. For instance, I know of three different definitions for the word “bill”:

1. The first usage is a very precise definition and it describes a document, introduced in a legislative body, that proposes to modify existing law. I will call this document a Bill (with a capital B). In California, all legislative documents which modify law are Bills. Subdivision (b) of Section 8 or Article 4 of the California Constitution defines it this way. At the federal level, the same definition of a bill exists, except that another document, the Joint Resolution, has similar powers to enact law, but this document is not a Bill.
2. The second definition is the much looser definition that applies the word to any official documents acted upon by a legislature. I will use the term bill (with a lower-case b) when referring to this usage. In California, the precise term that is synonymous with bill is Measure. At the federal level, the precise term used is either Measure or Resolution. Of course, this opens up more confusion. In California, Measures are either Bills (and will affect law when enacted) or are Resolutions which express a statement from the legislature or house without directly affecting the law. So now the Federal Resolution is a synonym for a Measure while the California Resolution is a subclass of it. The Federal equivalent of a California Resolution is a Non-binding Resolution.
3. The third definition is the Akoma Ntoso definition of a bill which I will refer to as the akn:bill. At first glance, it appears to equate with the precise definition of a Bill. It is defined as a document that affects the law upon enactment. But this definition breaks down. The akn:bill applies more broadly than the precise definition of a Bill but not as broadly as the imprecise definition of a bill. So an akn:bill applies to the federal Joint Resolution, Constitutional Amendments, California Initiatives along with the precise notion of a Bill.

I can summarize all this by saying that all Bills are akn:bills, and all akn:bills are bills, but not all bills are akn:bills, and not all akn:bills are Bills.

As if this isn’t confusing enough, other terms are even more overloaded. As I already alluded to, the term resolution is quite overloaded and the term amendment is even worse. Even the distinction between a bill and an act is unclear. Apparently a Bill, when it has passed one house, technically becomes an Act even before it passes the opposite house, but the imprecise term bill generally continues to be used.

To try and untangle all this confusion and allow us to communicate with one another more effectively, I have started a spreadsheet to collect all the terms and definitions I come across during my journey through this subject. My goal is to try and find the root concepts that are hidden underneath the vague and/or overloaded terminology we use and hopefully find some neutral terms which can be used to disambiguate communication between people coming from different legislative traditions. The beginning of my effort can be found at:

https://docs.google.com/spreadsheet/ccc?key=0ApeIHP2TOckZdHRPZ1pIeVRUcVpJZzZQT1BCSHFqd0E

Please feel free to contribute. Send me any deviations and additions you may have. And if you note an error in my understanding, please let me know. I am still learning this myself.

I just got back from a vacation in Denmark – the land where Legos come from. I thought it might be appropriate to spend some time talking about Flavio Zeni at UNDESA calls Legislative Legos – building blocks that can be used to build legislative systems.

Why is this such an important concept? Well, it’s all about managing risk and building a system that can adapt to change in timely manner. Legislative systems can take years and cost many millions of dollars to develop. As the sophistication grows and automation takes root throughout the organization, these systems become extensive mission critical parts of the organization’s fabric. So failure is not an option.

At the same time as legislative systems become so ingrained, technology cycles are shrinking. Rapid changes in technology ensures that the expected lifecycle of any part of a system will be compressed. Wasting 5 years of a technology cycle to perfect a large system chews up a lot of the viable life of a technology as well. Also, as change occurs, the technology waves are being blurred into streams of constant change. So catching a technology wave at the exact right moment becomes impossible.

Imagine for a moment choosing to build a brand new, built from scratch, system. You’re looking at a multi-million dollar proposition that will take at least 3-5 years to come to fruition. The technologies you choose will all be at various stages of maturity. Some technologies might be well established and stable – but they might also be waning and likely to soon be obsolete. There the risk is building a system now that will be obsolete by the time it is deployed. On the other hand, other technologies will be on the bleeding edge. Choosing to use them might maximize the lifecycle of the result, but it does so at the risk of using a technology that might not yet be ready for prime time. When building a large scale system, the likelihood of all the technologies being optimal for adoption at the same time you need them is very remote.

Think about the infrastructure of a city. The road system has all sorts of problems. Traffic jams, potholes, and aging infrastructure abound. Under the streets are a rat’s nest of utilities from different eras. It might be very tempting to want to simply demolish the city and build a new one. But that’s a preposterous idea. Not only would it not be affordable, the inconveniance and risk would be unthinkable. This is something that becomes true of all systems as them become large and ingrained. They are no longer replaceable. Instead they must evolve constantly – in as smooth and efficient a manner as can be achieved.

So how must legislative systems evolve? The must evolve by being built as interoperable modules. These modules must stand on their own and be able to be deployed, updated, and replaced on their own timetable. These modules must be defined in such a way as to maximize the likelihood that expertise gained elsewhere can be harnessed to reduce risk and lower costs. These modules must be sufficiently independent of the rest of the system that should they fail or become obsolete they do not jeopardize everything else. This is all simply good risk management.

So let’s think about Legos for a moment. When I was a kid they were my favorite toy and I was the champ at the Lego competitions in the small town where I grew up. I would spend hours and hours building all sorts of different things out of them. A consistent standard for how the blocks connect is what made this possible. That standard doesn’t dictate how the blocks go together or what you can build with them. Instead, Lego defines a simple protocol that allows the blocks to connect and then they provide enough variety in their blocks to allow your imagination to run wild.

We need the same concept for legislative systems. Instead of large monolithic, likely to either fail or be obsolete, but always be expensive solutions, we need a simple set of protocols that will allow modules to be built and then mixed or matched to solve all the varying requirements that exist for legislative systems.

So what is the legislative analogue of the Lego standard? First we need the basic protocol for how things connect. That is where XML and something like Akoma Ntoso comes in. It defines the most basic parameters of how the information can be connected. Next we need to define what the basic pieces are. We need an editor, a repository, some sort of metadata management, various publishing engines, and so on. Those are the blocks. Not every system will need the same blocks and not every block will fit every application. With enough forethought and enough industry cooperation, blocks can be made to fit together in a variety of ways to solve every need.

I come from the electronic CAD industry. Our early generation systems in the 1980s were large monolithic solutions. As a vendor, we loved the idea because we locked our customers into our solution. Their investment in our system become so large that replacing us was inconceivable. All we had to do was have our professional services people show up at a prospect, convince them to choose our product suite, and then accept all the custom code we would build to cement the relationship forever. This worked great until our product became obsolete. Not only could our customers not get out from under the monstrosity we had built, neither could we. Smaller companies with new innovative ideas started chipping away at our fortress (that’s what we called it) and we couldn’t adapt. When we tried, the result was more pieces stuck to our monolith which only made the problem worse. Monolothic system thinking nearly killed the business and made a lot of customers very angry. Today that same industry is made up of a myriad of much smaller less tightly coupled products, available from a large selection of venders, and bound by common industry standards. The Lego inspired model made the industry much stronger and served the customers far better. The design efficiency that results is what makes thing like smartphones and tablets, updated every few months, even possible.

The same thing must happen for legislative systems. Modular Legislative Legos will allow this field to flourish – to everyone’s benefit. So let’s work together to make this happen.

Way back in 2002, when I first started building an editor for legislation, the problem looked so simple. We figured it was a quick six month project and we would then have a product we could resell to other jurisdictions. I remember when we first made our modest proposal, having it pushed back at us and being told we needed to go and rethink it. California had already learned, the hard way, that the deceptively simple problem of building a legislative editor was actually much more difficult and complex. What I have come to appreciate, over time, is that California’s approach actually makes the problem easier. It’s even harder elsewhere where the drafting rules are less structured and well thought out. I actually lucked out in starting with California, and it still took over three years to get a deployed solution in place – and that was only the beginning.

So what makes building a legislative editor so difficult? First of all, you need to understand what a bill really is. If you’re a software developer, the easiest way to understand it is to think of it as a document to “patch” existing law. Quite confusingly to software types, that process of patching the law results in something called “compiling codes”. So bills are patch documents containing intricate instructions for how to modify the law. What’s so hard about that? Well, for starters, the law has been built up over many decades or centuries and has accumulated all sorts of errors and odd situations that have to be accommodated. How do you correctly refer to something when, quite by accident, two different things have been numbered the same? How do you deal with the situation that arises when the law is defined to change in some complex temporal way? What happens when something is referred to by one number before a particular date, and then by a different number after that date? Quickly all these complexities start accumulating on top of your clean and simple architecture and the hope you’ll ever be able to solve it starts becoming a panic that perhaps you’ve attempted a problem that cannot be solved.

Let’s add another layer of complexity to the problem. The patch documents, which legislative types like to call bills, are also patched – or amended to use the real terminology. So you’ve got to deal with patches of patches. As a bill winds through the process of becoming law, it might be amended many times. Tracking all those amendments is going to be important to a lot of people. Keeping it all straight is crucial to producing an eventual result that patches the law accurately. Those legislative types aren’t very understanding when you get it wrong.

So now that you understand the complexity of the process, lets add some more complexity. Legislative traditions were defined long before there were computers. The procedures were defined for an era where everything was done using pen and paper. Amendments were made using scissors and glue. In fact, scissors and glue were still a part of the amendment process until quite recently in California. Other jurisdiction still have to resort to these procedures even today. Unfortunately, it is simply not possible to replace these outdated traditions with modern computer-based methodologies overnight. Legal traditions evolve on a deliberately conservative path. Good luck trying to throw out the old way just because the new way will be easier for the software. Chances are, you’re going to have to adapt more to the current process than the current process is going to adapt to you.

So what other aspects of legislative bill drafting are complex? I could go on and on about this subject. First of all, you’re not going to be able to convince the government to throw out all the existing laws and start again. You’re just going to have to deal with all the strange ways things were done in the past. If they numbered things with vulgar fractions (i.e. 1/2, 1/3) once-upon-a-time, you’re going to have to deal with that. If they believe that 100.15 reads as “one hundred point fifteen” and comes somewhere between “one hundred point ten” and “one hundred point twenty”, except when it is found between “one hundred point one and one hundred point two”, then you’re going to have to accept that too. Then there is the whole subject of redlining. Don’t be fooled into believing that redlining is the same as track changes in a word processor. It might look the same and be conceptually similar, but chances are there is a lot more hidden meaning in those strikes and inserts than you realize. When you get to the subject of making references or citations, you’ll discover just how much ambiguity there is in the subject. Quite often, a reference to a person is by last name alone. The only way to know which person with that last name is being referred to is to understand the context in terms of location and time. Even then, you might have to deal with ambiguity. When you get to the subject of tables, you’ll want to throw your arms in the air and walk away. Amending tables is an almost intractible problem. If you’re lucky, page and line numbers won’t come up at all. How on earth do you represent page and line numbers in a document that is explicitly designed to not worry about the physical aspects of the published form?

Okay, so you have found your way through all of that and now your editor is ready to go. Whew, that was hard! Oh, but now they want to be able to tear apart and rearrange the document in arbitary ways that make no sense with the XML hierarchy you’ve defined. Of course, you’re expected to be able to piece together the resulting mess to produce a valid document. Well they can’t do that. That’s just the way it is and you’ll tell them that when they tell you they’re not happy with the editor. Alright, that’s not a very good answer. Well, back to the drawing boards on that. Building an editor that both conforms to the software notions of how a document should be structured and how a non-technical users perceives it to be structured is a very difficult problem.

Legislative XML editors can be built. There are a few successful examples to show that it is possible. I’m proud to have muddled through to success with California, but it was very difficult. At the same time, there have been plenty of failures and projects that have gone way over budget. Having a standardized model, such as is promised by Akoma Ntoso and the standards effort within OASIS, should help by allowing this problem to be solved only a few times and then reused many times afterwards. However, given all the variations that exist, even with a standard in place this is going to be a difficult problem to solve for the foreseeable future.