When we first started implementing California’s bill drafting system in the early 2000s, we were asked to ensure that the system had a redlining capability. California had already chosen XMetal from SoftQuad as their base editor. Finding that XMetaL supported track changes we quickly reported back that supporting redlining would be no problem at all.
We were wrong! XMetaL’s track changes was based on Microsoft Word’s track changes and works like other change tracking systems — to accurately capture the changes that users are making to the document. While that is a very useful capability in a word processor, it’s not what change management in a legislative system is all about at all.
Change management in a legislative system is all about signalling and tracking proposed changes to the law and later on it’s all about tracking those changes once they are enacted. While tracking changes to the document is a part of the problem, it is also about managing changes that will be made to other documents.
For the California system, we went through a tortuous process that required the intrinsic capabilities of XMetaL to be changed (at great cost) and months and months of additional programming adding to our customisation. It was a learning process — but one we made our way through.
For our third-generation LegisPro product, we wanted to make sure that we didn’t make the same mistake twice. Rather than trying to tack legislative change management onto the top of an existing editor, we built an editor with change management as part of its fundamental architecture.
However, when you solve one problem, you often open up all new opportunities which create new problems to be tackled. That has been the case for us here — and we are now being called upon to solve some very sophisticated change management problems.
Fortunately, long ago as a young Boeing design engineer, I worked with a now forgotten document processor that contained a very sophisticated change control capability — Context Doc. Its change control mechanisms were built to a Boeing specification for a document management system to manage the complexities of airliner maintenance manuals. With all the options available to the airlines, the manufacturing changes that occur over time, and the strict regulations imposed by the various regulatory agencies, managing airliner maintenance manuals is a very complex task — and one with many parallels to legislative and regulatory documents.
Context Doc never made it in the market but the capabilities it pioneered later went across town and became, in a very watered down form, the track changes capability of Microsoft Word.
We’ve recreated change management as I used to know it, to apply to three distinct challenges our customers are looking to us to solve:
1. Tracking amendments to bills
This is the original problem that we tackled. Our amendment-in-context capability was able to turn the amending process around by allowing proposed changes to be drafted in the bill and then the amendment document produced as a report of those changes. It has been very successful.
However, as our customers have learned to use this feature, they have expanded on the original model and today want a new round of more sophisticated capabilities. These include the ability to show different amendment sets — either side-by-side or integrated. This allows the reader to see how the amendments affect the bill and can point out any conflicts that might result. Another requested capability has been to be able to associate each change in a bill to the amendment that causes it.
2. Applying enacted amendments to codes or statutes
This is our most recent application, and it is quite the challenge. The requirement here is to allow the amendments found in statutes to be applied to the codes or to other statutes. This is sometimes called consolidation or compilation. Because of the serious nature of this function, it is crucial that there be very rigorous bookkeeping and that every change is controlled to ensure that nothing is erroneously added, deleted, or changed. We do this by showing the origin of all text — original text, statutory text being inserted, or modifications being made by the user.
3. Permitting point-in-time computation of the law
The third application is the classic point-in-time solution that had intrigued us so way back when that we started a company. Up until now, our solutions have focused on recording versions of provisions for each time period of a provision’s lifetime that it differed. Now, with our enhanced change management capabilities, we can solve the problem in a far more granular way — using change management to record time periods within a single version of the provision. It’s a simple idea, but one that has eluded us due to the complexity of overlaying time on top of a semantic model representing the document hierarchy. Now we have a very elegant solution.
Our new change management capability is designed as a first class feature of LegisPro. While it works closely with the implemented XML schema, it is not schema dependent. We will provide a basic implementation for the Sunrise Edition of LegisPro using Akoma Ntoso, but we have also used it with USLM.
If you would like to experience our change management capability for yourself, sign up to receive an invitation to join the early release programme for our Sunrise Edition of LegisPro by click here.