Legis Info

Blog

  • Six Commitments for AI in Legislative Drafting

    Over the past few months, I’ve written about government’s responsibilities in the age of AI and about how AI is eroding the rigor of legislative drafting. It’s only fair that I hold Xcential to the same standard.

    So today we’re publishing six commitments that govern every AI feature in LegisPro, now and in the future. They aren’t marketing language. They are rules we have built into the architecture, and we expect our customers to hold us to them.

    Why now? Every legislative body I talk to is asking the same questions. Will AI write our laws? Where do our confidential drafts go? What happens if an AI vendor changes its terms, or disappears? Those are the right questions, and drafting offices deserve clear answers before they turn on a single AI feature.

    AI Never Authors the Law

    Let me start with where we stand. LegisPro does not generate legislation. Attorneys and drafters author every word.

    The software that drafts, amends, compiles and publishes law in LegisPro is a deterministic core. Give it the same inputs and it gives you the same result, every time, using the rules from your own drafting manual. That is what you want from a system that produces the law.

    AI sits beside that core, not inside it. It can suggest a change, find a reference or explain a provision. But it only ever proposes. A drafter decides.

    The Six Commitments

    The six commitments: 1. The drafter stays in charge; 2. The deterministic core never requires AI; 3. Confidentiality comes first; 4. Processing stays within your boundaries; 5. No dependence on any one AI vendor; 6. Authoritative data first
    1. The drafter stays in charge. AI returns proposals, never edits. Each proposal shows the provision it relied on and why. A drafter accepts, changes or rejects it, and nothing reaches the text without that decision.
    2. The deterministic core never requires AI. Everything needed to draft, amend, compare and publish law works with AI switched off. Each AI feature has its own switch, and turning AI off changes none of the core’s results.
    3. Confidentiality comes first. Drafts are confidential until they are introduced. We require zero data retention, and customer material is never used to train a model without written consent. Prompts and responses are treated as privileged, not open to the whole office.
    4. Processing stays within your boundaries. By default, AI runs where you say it runs. You may choose otherwise; Xcential never will. If a policy check fails, the AI does nothing.
    5. No dependence on any one AI vendor. AI models change fast, and your drafting system shouldn’t have to change with them. Models sit behind one gateway, so they can be replaced without rework, and each is tested on your documents before use.
    6. Authoritative data first. AI answers from your own official text, not from whatever a model happens to remember. Every proposal cites a provision that resolves and quotes the words it relied on, so a drafter can check it in one step.

    Why We Start with Open-Weight Models

    If you haven’t come across the term, an open-weight model is an AI model whose trained settings are published. That means it can be installed and run on your own computers, rather than reached over the internet on someone else’s.

    The difference matters. With a hosted AI service, your text travels to the vendor. With an open-weight model, the model travels to you. That one change makes several of the commitments above practical:

    • Residency. Your drafts stay where you keep them.
    • Privilege. No outside party sees prompts or responses.
    • Isolated operation. It works with no internet connection at all, including in an emergency facility.
    • Freedom of choice. You can move to a better model whenever one comes along.
    • Predictable versions. The model changes only when you decide it should.

    That’s why our default is an open-weight model running inside the customer’s own boundary.

    Your Choice, Never Ours

    A default is not a mandate. Some customers will prefer a commercial AI provider, and that is their right. LegisPro supports it: the customer chooses the provider, the choice is recorded, and every other safeguard still applies. Proposals stay proposals, AI still can’t write to the law, and the drafter still makes every change.

    What we will never do is make that choice for a customer. Where your legislative text is processed is a policy decision for your institution, not a business decision for your software vendor.

    Built In, Not Bolted On

    Promises are easy to make. What gives these ones weight is that the architecture enforces them:

    • AI features return proposals as output. There is no path for them to write to a bill or a compilation.
    • The connection AI uses to read the law, MCP Services, which we are building now, is read-only and runs with the user’s own permissions.
    • All AI requests go through AI Services, which checks policy before every call and refuses anything that fails.
    • The drafting office decides which AI features are allowed, which models are used, and where they run, and that record is kept.
    • New AI features arrive as packages of instructions and data rather than new code, so every one passes the same checks.

    AI has a real role to play in legislative drafting. It can take on slow, mechanical work, such as converting existing law into structured text, and leave drafters more time for the judgment only they can provide. But the law is too important to hand over to a tool that can’t be held accountable.

    The drafter decides. Always.

    If you’d like to talk about any of these commitments, or how they would apply in your own office, I’d be glad to hear from you.

  • Rethinking Legislative Drafting for the Age of AI

    Rethinking Legislative Drafting for the Age of AI

    Recently there have been a few articles on how AI slop is creating problems for legislative drafting, including this one.

    I’ve been giving this problem a lot of thought. Although I am not a drafter, I’ve been in the field for 24 years now – starting in the State of California and expanding around the world.

    The basic problem, as I see it, is that AI is contributing to a breakdown in the rigor of legislative drafting. Rather than having highly skill legislative attorneys do the task, AI agents are being used, often without disclosure, to craft legislation. The result is legislation riddled with errors that have to be cleaned up.

    Given my drafting experience in California, this doesn’t make a lot of sense. In California, the swim lanes are clear. Lobbyists and other special interests influence policy, but don’t define it. Politicians define policy, but don’t draft legislation to implement it. Only the team of highly skill drafters in Legislative Counsel get to draft legislation.

    However, I have learned that these strict swim lanes don’t always apply and solutions must be devised to work in this environment.

    To me, there are three solutions to the problem of AI drafted legislation:

    1. Like California, implement stricter swim lanes. This might be difficult to achieve. In California, it took a constitutional amendment in 1966 to overcome all the resistance.
    2. Another obvious answer is to provide more robust legislative drafting capabilities to those drafting legislation outside of the Legislative Counsel, building in some level of tolerance for AI concocted language being part of the mix. Knowing what I know of how complex legislation can be, I remain skeptical.
    3. So, perhaps there is a third option, one that takes a very different path to finding a solution – having legislation be specified as policy intent rather than as concrete legislative language.

    I’m sure this sounds like the idealistic ramblings of a software developer but hear me out.

    How do you specify policy intent? How do you describe exactly what you want if you don’t want to take the laborious route of getting enough bandwidth from a team of lawyers in Leg. Counsel that simply aren’t funded to the extent necessary to be at your beck and call?

    The answer today is simple; you tell an AI chatbot what you want, and it drafts the bill for you – throwing all caution to the wind. The result may even look pretty good – it’s a plausible bill. It is only when someone actually analyzes the bill closely that the cracks begin to reveal themselves, the original legal text isn’t right, the references aren’t correct, consequential amendments are missing, and so on. There is a myriad of things that could be wrong – and likely are.

    This all means that the result of having an AI chatbot generate a bill is throwaway rubbish – a suitable prototype for a bill but certainly not a draft that can stand up to scrutiny.

    But what if it was the process that created the flawed bill that was valuable rather than the end result? Chances are, someone using AI to draft a bill took considerable time and effort to explain to the AI chatbot what they wanted. The conversation probably looked very similar to the conversation they would have with a drafting attorney if one were to be assigned to them. Why not capture that conversation rather than just the faulty end result.

    It turns out that there is a way to capture a conversation like this and bottle it up as a reusable or replayable task – and one that is easily deliverable. It is a new technology called a “skill” — a reusable package of instructions, workflows, and supporting resources that teaches an artificial intelligence agent how to perform a specific, multi-step task.

    A skill is quite easy to create in a platform, like Claude or Skill.yo. You simply explain to the chatbot what you are trying to get, get a response, and then iterate providing more and more information and instructions until you get the result you think is right. Then you save that conversation as a skill.

    Skills can be quite sophisticated. They can have a UI. And they are reusable.

    Now, imagine that the skill is the description of policy intent. They’ve refined it as far as they can, even though it’s not perfect. But rather than delivering an imperfect result, they instead deliver the skill to Leg. Counsel as their expression of policy intent.

    Leg. Counsel, with a skill enabled drafting editor, can then take the policy intent skill they receive, run it against the official texts they have, and under the stewardship of a qualified drafter, refine the result taking into account all the considerations that are invisible to someone trying to draft on the outside.

    What is more, a skill enabled drafting editor would have other abilities as well – allowing the drafters in Leg. Counsel to create their own library of skills to perform all the dreary tasks that hamper their productivity without surrendering the overall responsibility for drafting over to an AI chatbot.

    There are some very serious concerns that needs consideration and guardrails that need to be implemented. Whenever someone interacts with an AI chatbot, there is a risk of piercing any confidentiality bubbles that might be in place. While the conversation won’t immediately be used by the LLM, the AI vendors don’t guarantee that they won’t use the chats for future training. This is called Vendor Data Retention. The problem can be circumvented by paying for Zero Data Retention (ZDR), but it’s very costly – reflecting the value of using chat conversations for future training. This has to be given a lot of consideration.

    All of this is just food for thought…

  • Government’s Responsibility in the Age of AI

    I’ve recently seen several articles on how AI is affecting government. It’s something I’ve been thinking about for a while, and my involvement in Bussola Tech events has pulled me further into it.

    It’s time to weigh in. While the world debates the policies and regulations needed to address AI’s risks and opportunities, I want to focus on something more fundamental: the responsibilities governments have right now.

    It’s easy to get swept up — excited about what’s possible, or fearful of the consequences. But governments need to focus on the immediate responsibilities in front of them. I’ll break these into three categories: what governments must do, what they should do, and what they could do.

    What Government Must Do

    When AI platforms are trained, they ingest large volumes of static information from sources like websites, databases, and user chats. Where that information comes from, and how credible it is, matters. Governments have a responsibility to publish AI-ready information in a way AI platforms can use.

    Years ago, it was fine to publish information online in a format only a human could read. Search engines changed that by requiring machine-readable formats. Now AI is changing the bar again. That creates new responsibilities:

    • Be the source of official information. Governments must be the primary source for official information and must publish it so AI platforms can discover it, understand it, and ingest it accurately.
    • Be discoverable and accessible. Information hidden behind a login or a form is invisible to AI platforms looking for static content. Unstructured formats have the same effect: a human might understand the document, but an AI platform training on a huge corpus of text will likely skip over it.
    • Be meaningful. Governments need to understand how AI platforms learn. The way information should be structured and presented varies by content type — there’s no single right answer, and the right answer keeps changing.
    • Be accurate, timely, and clean. Published information must be current, correct, and free of anything sensitive that shouldn’t be learned by an AI platform. Legislative documents can contain sensitive material — for example, notes protected by attorney-client privilege hidden in invisible comments. That needs to be stripped out before publication.
    • Be trustworthy. Governments are responsible for being the trusted source of official information. That’s a serious responsibility: publishing misinformation undermines government credibility and can cause AI engines to rank the government’s information lower — accurate or not. And if government isn’t a reliable source, unofficial and less authoritative sources will fill the gap.

    What Government Should Do

    The list above covers the minimum. Beyond that, governments should also:

    • Be authentic. Being the source of truth isn’t just about providing information — it means guaranteeing that what’s delivered matches what was enacted into law or officially published, unaltered. Usually, it means providing digital signatures and ensuring encryption throughout the pipeline. However, this is a nuanced problem, and as far as I know, today’s AI platforms don’t verify digital signatures during training.
    • Be authoritative experts. Government websites often provide bare facts without the supporting context that establishes expertise. Governments should consider how this affects whether AI platforms favor a less official but more authoritative-seeming source instead. That might sometimes be fine — but it can also open the door to harmful exploitation.
    • Be genuine. Governments carry inherent public trust, so it’s essential they avoid publishing synthetic or AI-generated content under the banner of being a source of truth.

    What Government Could Do

    AI platforms are trained on a large corpus of static information, producing a language model with general understanding. But for many tasks AI is used for today, that’s not enough — platforms also need up-to-date information, real-time events, and the ability to act through the services they connect to.

    The Model Context Protocol (MCP) addresses this. Servers that implement MCP give AI applications three core capabilities:

    1. Access to resources (note that this does not enable real-time learning)
    2. Tools to execute APIs
    3. Reusable prompt templates for specific tasks

    This unlocks a lot for AI applications — but it also means governments need to carefully think through their responsibilities in offering agent-ready services:

    • Be harmless. Any time programmatic services are exposed — to humans or to AI agents — there’s potential for exploitation. Appropriate safeguards need to be built in to ensure against an AI application going rogue.
    • Be secure. Closely related to the last point, MCP servers need to be designed with security and privacy in mind. Information that is available to an MCP server should be separated from the internal operations entirely. The same considerations that apply to separating trusted internal networks from untrusted networks like the Internet using techniques like a DMZ (demilitarized zone) should be applied with building MCP servers if those servers are to be made public.
    • Be useful. Exposing real-time information without thinking through how it will be used doesn’t solve a real problem. It’s worth noting that MCP servers aren’t used to train an LLM — they only answer specific runtime questions. This means they can’t be used to teach a model a new corpus of documents. Designing MCP servers that work well with AI platforms is a distinct skill that takes careful thought.
    • Be cautious. Programmatic capabilities can reduce AI hallucinations by giving platforms access to information they weren’t trained on. But this also creates the risk of AI answering questions it shouldn’t — for instance, generating an artificial interpretation of the law that goes beyond what’s officially published. Some things should still be handled by qualified humans. It is better to error on the side of caution.

    In Conclusion

    Governments have a responsibility to provide AI-ready information to the AI platform in a way that ensures the information is accurate, timely, and trustworthy. What is now emerging is the added need to provide AI-agent-ready services that provide access to real-time information and capabilities to AI-based applications. Rather than rushing to take advantage of these new capabilities, governments need to exercise caution to ensure that the new functionality they provide through these capabilities are useful and don’t have unintended consequences.

  • Report on the Bússola Tech AI Conference in Brasília, Brazil

    This past week I attended a conference in the Brazilian capital of Brasilia, hosted by the Brazilian Senate and organized by Bussola Tech and the Organization of American States (OAS). The theme of the conference was “Structuring the Digital Legislative Process for Integration with Public Artificial Intelligence Interfaces”.

    This conference was one in a series of conferences I have attended over the past couple of years where the emergence AI has been the focus.

    I gave a talk on some of the AI projects we are working on at Xcential and how structured data enables them. Later, I participated in a panel discussion with many familiar faces. The panel was chaired by Wade Ballou, the former Legislative Counsel for the U.S. House of Representatives along with Monica Palmirani from the University of Bologna, Fotis Fitsilis from the Hellenic Parliament, and Juliano Bringer from Agape Consulting. The topic explored the theme of the conference from our various perspectives.

    There were a number of interesting points made at the conference ranging from how AI is already being used in support of legislative drafting and to improve citizen engagement to the concerns of how AI will affect human critical thinking skills and the environmental impact of the massive electrical and cooling resources needed to maintain the data centers that provide AI services.

    All these points got me thinking more about what our response to AI should be. AI is clearly the next big thing and is already profoundly changing how we, as humans, live our lives. As with every development, there will be winners and losers. Those who adapt and take advantage of the new capabilities will profit while those who can’t adapt will find themselves sidelined by progress.

    However, there is also a more insidious side to the emergence of AI in our society. Like social media before it, despite all the positive changes it can bring, it can easily be exploited to harm society. How we prepare for AI will determine whether it ends up being a net positive or net negative to the world.

    In my coming blogs, I’m going to explore these points further.

  • Changing the way the world legislates. Together.

    I got my start, like my father before me, as a draftsman. I worked for the Cleveland Switchboard Company drawing power distribution switchboards and panel boards while earning my engineering degree at university. That experience led to me getting a job at the Boeing Company supporting drafting tools as an electronics design engineer.

    It was a pivotal time at Boeing, and indeed for the entire industry. When I started, we were supporting drafting tools which used computers to emulate drafting boards. But within a few years, drafting tools gave way to design tools. The reason was simple. Computers enabled a whole different way of thinking. It wasn’t just a matter of putting pencil to paper anymore. Design tools allowed you to use a computer to do the intellectual engineering work behind the schematics that would be produced. My focus shifted from schematic drawings to fault simulations – being able to identify the many ways a system might fail such that those failure modes would never happen (a skill Boeing seems to have lost of late).

    The pace of change in legal informatics has been much slower — something that has been frustrating to me. The transformation I witnessed in electronic design today allows me to have a virtual supercomputer in my pocket. It’s time for legislation to make the same leap into the future.

    We need to get beyond legislative drafting and rethink the process by which policy initiatives become legislation which ultimately become law. There’s much more to that process than just writing the text for the documents that become bills.

    There are many stakeholders in the legislative process – constituents, special interests, politicians, government representatives, and even the lawyers that draft the legislation. Synthesizing all the information they provide into a bill draft is a complex process. This is something I’ve been thinking about for a very long time. In fact, it was realizing that XML was the best medium for transforming the legislative process, in a way like what I had experienced in electronics design, that led me to start Xcential.

    We now have the tools, technologies, and the standards to make this transformation a reality. We have tools that allow the lawyers who draft legislation to focus on the intellectual process rather than the technical process of getting the formatting or wording right. We have tools that allow all the stakeholders to work together rather than individually. And we have technologies and standards that ensure the precise representation and handling of the law.

    When I left Boeing, I took a job working at a design automation company to revolutionize how engineers work – something we called “concurrent design”. I was the product manager for the design management component at the very heart of that system. The company tagline reflected the vision: “Changing the way the world designs. Together.” It’s time for a such big vision in our field.

  • Transparent legislation should be easy to read — part II

    Over a decade ago, I wrote a blog questioning why federal bills are written the way they are. For someone experienced with state legislation, federal legislation is quite cryptic and difficult to understand. It turns out that the style of amending law found in federal legislation is the common form and can be found around the world. In the U.S. Congress, this style is known as cut and bite1 amending. With this style, individual word changes are spelled out in a narrative form. For example, here is a section from California Assembly Bill 2748 from the current session:

    SECTION 1.  Section 21377.5 of the Water Code is amended to read:

    21377.5.  (a) Notwithstanding Section 21377 of this code or Section 54954 of the Government Code or any other provision of law, the Board of Directors of the Tri-Dam Project, which is composed of the directors of the Oakdale Irrigation District and the South San Joaquin Irrigation District, may hold no more than four regular meetings annually at the a Tri-Dam Project offices. The Board of Directors of the Tri-Dam Project shall adopt a resolution that determines the location of the Tri-Dam Project offices. office that is located in Sonora, California, or Strawberry, California, or within 30 miles of either city.

    (b) The notice and conduct of these meetings shall comply with the provisions of the Ralph M. Brown Act (Chapter 9 (commencing with Section 54950) of Part 1 of Division 2 of Title 5 of the Government Code).

    You can clearly see what changes are being made. However, if written using cut and bite amending, this equivalent section would read something like:

    SECTION 1.  Section 21377.5 of the Water Code is amended by:

    (a) Deleting the sixth “the” and replacing it with “a”.

    (b) After “Tri-Dam Project”, deleting to the end of the subsection and replacing with “office that is located in Sonora, California, or Strawberry, California, or within 30 miles of either city.”

    This very terse form of amendment gives no context for the change being made. The change in subsection (a) is completely meaningless without any context. What this all means is that a politician tasked with approving these changes must do a significant amount of work to understand what the changes are all about and why they are being made.

    Back in 2013, I questioned why the form found most of the U.S. states including my state of California wasn’t used. As seen in the example above, the U.S. states use a different approach to amending – known as amending in full. In this style of amending, the entire section containing the change is restated and the change is shown (some of the time) as stricken and inserted text, as you would find with track changes in a word processor. This approach has the benefit of making the change much clearer by providing the complete context of the change. In California, this approach is mandated by the State Constitution as amended by Proposition 1-a of 1966. This proposition was overwhelmingly approved by the voters of California. The Speaker of the California Assembly at the time, Jesse Unruh, had pushed through this constitutional amendment to establish professional legislature less beholden to special interests that other pressures that were undermining the effectiveness of the legislature at the time. His reforms were quite sweeping. Among the many changes, one part of this initiative was to make legislation more transparent.

    The specific provision that was added, Section 9 of Article IV of the California Constitution, reads:

    “A statute shall embrace but one subject, which shall be expressed in its title. If a statute embraces a subject not expressed in its title, only the part not expressed is void. A statute may not be amended by reference to its title. A section of a statute may not be amended unless the section is re-enacted as amended.”

    This section of the California Constitution contains two rules. The first is the single subject rule, which limits the scope of each statute. The second is the re-enactment rule, which mandates the amendment in full approach, requiring that each section amended by re-enacting the whole section (essentially a repeal of the prior section and enactment of a new amended section as a single action). Most U.S. states have these same rules or very similar rules. These two rules go together. One of the worries of the re-enactment rule is that, by opening an entire section for re-enactment, unwelcome amendments might be added as part of the political process of winning votes. The single-subject rule is a guard against that behavior.

    At the time of my original blog, I learned that adopting these rules in Congress would be impossible. For one thing, the U.S. Code is less regular than state codes or revised statutes, especially in the non-positive titles, and that re-enacting an entire section would be quite complex and could cause other difficulties. Re-enactment rules require consistently bite-sized sections. In addition, the House’s equivalent of the single subject rule, the germaneness rule adopted in 1789, didn’t have quite the same effectiveness as the single subject rule of California. Apparently, the Senate’s equivalent rules, found in the Senate Standing Rule XVI and Rule XXII had even more limited applicability.

    As a result, I proposed in my blog that amendments in context be used. With amendments in context, a proposed bill is drafted using the amendments in full style that U.S. states use, from which a cut and bite style bill is generated using automation. With this approach, you get the best of both worlds. The bill is drafted in a form that is easy to understand and easy to manage while the worries of unleashing this amending style are circumvented by retaining the existing amending style for parliamentary procedures. However, at the time, the technology just wasn’t available. Under contract to the Law Revision Counsel, Xcential was just beginning down the path of converting the U.S. Code to processable XML that could feed the automation tools. While we had tools to offer that could do amendments in context, we were constrained by our agreement with California as to how much of our technology could be reused – they had been worried we could inadvertently undermine the successes of Proposition 1-a by empowering the special interests with our technology.

    Today, more than a decade later, much has changed. The U.S. Code is available in an XML format we designed and a new more modern LegisPro is available that is both web-based and much more powerful than what we had back then. But there have been other changes too. The Posey Rule has been adopted requiring that a comparative print be provided alongside all proposed law showing how the law will be affected. This comparative print is also generated by Xcential technology and alleviates much of the problem by allowing politicians to understand more easily what it is they are voting on. However, it leaves the complexity of drafting and managing the process of creating and managing the cut-and-bite amendments still to be addressed.

    This problem isn’t limited to U.S. federal bills. It’s a common problem wherever cut and bite amending is employed, particularly in Commonwealth countrie or countries with Westminster based legislative traditions, even if the term cut and bite isn’t used.

    At Xcential, we’re going to return to our core mission – to make government processes better through technology. Our goal is improved efficiency, increased accuracy, and most importantly, better transparency for the benefit of the citizens.

    1. The term cut and bite is also sometimes used to refer to the form of amending used to propose amendments to bills themselves. Another term for these types of bill amendments are page and line amendments as they usually are expressed as references to page and line numbers rather than to provisions. ↩︎

  • Building an Agile Team

    We’ve recently built our first true Agile development team. It’s been quite a learning experience, but now we’re seeing the results.

    At Xcential, we have lots of waterfall process experience. Our backgrounds come from big waterfall companies like Boeing and Xerox. Over the years we’ve worked on very large projects in very traditional ways. In more recent years, we’ve also had a few Agile projects, largely initiated by customers, that have been good training grounds for us — for better or worse.

    Like many companies, in recent years we’ve fallen victim to what the U.S. Department of Defense calls Agile BS — when you apply Agile terminology to your existing way of doing business. It’s a way to dilute Agile and turn it into nothing but a series of buzzwords. We’ve had sprints, standups, product owners, backlogs, and all the other bits of Agile — but we haven’t had the mindset that is necessary to make the Agile process work.

    To build an Agile Team, we have needed to make a few key changes. First, we had assemble a team of developers who would gel together to become a performing team as fast as possible. Then, in order to overcome the inertia of the old way of doing things, we had to ensure that the team was trained to tackle the challenge in front of them. Finally, we have had to ensure that all the team members felt empowered to rise up and take ownership for their project.

    An Agile team must be self-managing. This means that all the team members must feel the responsibility to deliver and have a commitment to do their part. Getting to that point has been a challenge — from getting management to let go and trust the team to getting the team members to step up and trust that their responsibilities are real.

    I like to think of managing a team as being a game of chess. In a traditional arrangement, the managers are the back row while the developers and the interchangeable pawns in the front row — to be assigned here, there and everywhere.

    In an Agile team, the roles are different. The team is self-managing. There is no front row and back row. Everyone has an important role in the team. This means that everyone should be challenged to step up to a bigger role than they would have had in a traditional team. While some team members are timid at first, having everyone feel empowered to play an important role is a key to the success of Agile.

    We still have some challenges. Developers are still bouncing from one project to another. This discontinuity of effort shows as a reluctance to commit to the story points that will ultimately be necessary to complete the project in a timely way. It also distracts from our efforts to form team bonds. It’s hard to consider the team your home team when you’re feeling like a visitor to every team you work on.

    Nonetheless, we’re starting to see real results from our prototype Agile team. Continuous integration procedures have been put in place ensuring a “done” product increment at the end of each sprint. For various reasons, delivery of these iterations to customers have not yet started, but this will be rectified at the end of the next sprint. We have peer reviews which are both improving the quality of the product with providing some degree of cross-training. The team’s velocity is improving, albeit at a slow rate. Over the next few sprints we will start integrating more and more with the other projects — and hopefully drawing them all into our new and more efficient way of building software.

  • Mapping Amending Language to Akoma Ntoso Modifications

    In my last blog, I talked about Xcential’s long history working with change management as it applies to legislation and my personal history working in the subject in other fields.

    In this blog, I’m going to focus in on change management as it is used in Akoma Ntoso. I’m going to use, as my example, a piece of legislation from the California Legislature. As I implemented the drafting system used in Sacramento (long before Akoma Ntoso), I have a bit of a unique ability to understand how change management is practiced there.

    First of all, we need to introduce some Akoma Ntoso terminology. In Akoma Ntoso, a change is known as a modification. There are two primary types of modifcations:

    1. Active modifications — modifications in which one document makes to another document.
    2. Passive modifications — modifications being proposed within the same document.

    The snippet I am using for example is a cropped section from AB17 from the current session:

    In California, many changes are shown using what they call redlining — or you may know as track changes. However, it would be a mistake to interpret them literally as you would in a word processor — a bit of the reason why it’s difficult to apply a word processor to the task of managing legislative changes.

    In the snippet above, there are a number of things going on. Obviously, Section 1 of AB17 is amending Section 1029 of the Government Code. Because California, like most U.S. states, only allows their codes or statutes to be amended-in-full. The entire section must be restated with the amended language in the text. This is a transparency measure to make it more clear exactly how the law is being changed. The U.S. Congress does not have this requirement and Federal laws may use the cut-and-bite approach where changes can be hidden in simple word modifications.

    Another thing I can tell right away is that this is an amended bill — it is not the bill as it was introduced. I will explain how I can tell this in a bit.

    From a markup standpoint, there are three types of changes in this document. Only two of these three types are handled by Akoma Ntoso:

    1. As I already stated, this bill is amending the Government Code by replacing Section 1029 with new wording. This is an active change in Akoma Ntoso of type insertion.
    2. Less obvious, but Section 1 of AB17 is an addition to the bill as originally introduced. I can tell this because the first line of Section 1, known in California as the action line, is shown in italic (and in blue which is a convention I introduced). The oddity here is that while the section number and the action line are shown as an insertion, the quoted structure (an Akoma Ntoso term), is not shown as inserted. The addition of this section to the original bill is a passive change of type insertion.
    3. Within the text of the new proposed wording for Section 1029, you can also see various insertions and deletions. Here, you have to be very careful in interpreting the changes being shown. Because this is the first appearance of this amending section in a version of AB17, the insertions and deletions shown reflect proposed changes to the current wording of Section 1029. In this case, these changes are informational and are neither an active nor passive change. Had these changes been shown in a section of the bill that had already appeared in a previous version of AB17, these these changes would be showing proposed changes to the wording in the bill (not necessarily to the law) and they would be considered to be passive changes.

    The rules are even more complex. Had section 1 been adding a section to the Government Code, then the quoted text being added would be shown as an insertion (but only in the first version of the bill that showed the addition). Even more complex, had the Section 1 been repealing a section of the Government Code, then the quoted text being repealed would be shown as a deletion (and would be omitted from subsequent versions of the bill). This last case is particularly confusing to the uninitiated because the passive modification of type insert is adding an active modification of type repeal. The redlining shows the insertion as an italic insertion of the action line while the repeal is being shown as a stricken deletion of the quoted structure.

    The lesson here is that track changes, as we may have learned them in a word processor, aren’t as literal as they are in a word processor. There is a lot of subtle meaning encoded into the representation of changes shown in the document. Being able to control track changes in very complex ways is one of the challenges of building a system for managing legislative changes.

  • Xcential is a Change Management Company

    At Xcential, we typically describe ourselves as a legislative technology company. While that is correct, the true answer is more nuanced than that. We purposefully don’t solve problems that are mainstream and relatively easily solved by other off-the-shelf software. Instead, we say that we focus on drafting but, in saying that, we understate what we do. In practice, we focus on a very complex and high-value problem called change management — as it relates to legislation. Few people truly know how to solve this problem.

    Twenty years ago, the founders of Xcential worked at an XML database company that was a subsidiary of Xerox. We started Xcential because we thought the legislation was one of the best applications for XML we had ever come across. It was the change management aspects that fascinated me, in particular. While my knowledge of legislation was based on high school civics class, I had a lot of experience in the field of change management.

    At the start of my career, I was an electronics design engineer at the Boeing Company. While there, I worked on a very sophisticated form of change management — concurrent fault simulation of behavioral representations of electronic systems. Fault simulation is a deliciously complex differencing problem. In legislation, we think of changes as amendments to the text and we record them as insertions and deletions. In fault simulation, the changes aren’t textual, they are behavioral. We record those changes as observable differences from expected results in something called a fault dictionary. With this dictionary of simulated faults, you are able to backtrack to predict which likely faults are causing the problem.

    While managing amendments and managing faults in an electronic system might seem a world apart, algorithmically they are surprising similar. In an amended bill, the objective is to efficiently record changes to a document as deltas (differences) recorded inline within the original text. When simulating an electronic system, the objective is to record thousands of potential failures as shadow circuits (differences) against a single good simulation executing concurrently. The shadow circuits, while a dynamic part of a simulation run, are very analogous to the changes recorded in a document. It’s a very clever techniques for efficiently simulating the behavior of thousands of things that might go without having to run thousands of individual simulations.

    Getting my head around the complexities of concurrent fault simulation taught me how to think in a world of asynchronous recursion — electronic systems are inherently asynchronous. Complex recursion in legislative documents is something I must frequently wrestle with, from parsing and responding to complex requests for documents or parts of documents in the URL Resolver to managing the layers of sets of changes that exist in the U.S. Code as laws are amended.

    Change management has a lot of applications — not just in managing faults in an electronic circuit or amendments in legislation. Another project at Boeing that I was not directly involved with involved allowing every airliner coming off the assembly line to have it’s own unique document configuration that would evolve through the thirty or so years the aircraft was in service. So many possibilities…

  • Legislative Terminology — The Same but Different

    In my last blog, I covered a lot of the variations I find around the world. I do a lot of document analysis, working to map various legislative traditions into Akoma Ntoso. Doing the job right sometime means understanding nuances and resisting the temptation to apply rules learned elsewhere.

    There are a number of terms that often require very careful consideration:

    • In legislation in the English speaking world, the “middle” layer is usually the Section. Numbering is sequential starting at the beginning of the document and continuing to the end of the document regardless of the hierarchy above. In non-English speaking countries, this level is the Article and the Section is a upper level like a Part or Chapter.

      However, there are exceptions. In the US Constitution, this practice is not followed. In the US Constitution, sections are found in articles. This arrangement is the opposite way around to European legislation where articles are found in sections. This doesn’t really make a lot of sense. In a newspaper, articles are found in sections of the paper like the business or sports section. This same structure exists in HTML5. Perhaps Thomas Jefferson and the other framer’s of the US Constitution were trying to add a bit of European flair to their work, but got the order backwards. Many Constitutions around the world are modelled on the US Constitution and adopt the same unusual Article/Section arrangement.

      One quirk I came across lately was most confusing and presented an interesting conundrum. While the prevailing practices in the jurisdiction were British in tradition, a few statutes adopted a more European style. The sections were numbered sequentially and always referred to as sections. However, the numbering never explicitly calls out the level type (e.g. the section number is “2.” rather than “Sec 2.”) Nonetheless, knowing that this level is a Section, we had modelled the sections as akn:section. However, we then discovered a small handful of statutes that had upper level sections as found in European legislation (e.g. SECTION 3). So, in these documents, there were two complete difference types of constructs both called sections. While this was probably an error caused by drafting rules not being enforced properly, the result was enacted law containing this error. We ended up using an akn:hcontainer with a @name = section to create another distinct type of Section.
    • One common area of confusion is the use of plurals. We see this all over the place. For example, in some jurisdictions, the Section type construct is known as a Regulation and the document containing them is called Regulations. Other jurisdictions refer to the sections as Section, and the document itself is the Regulation.

      This same practice is found with rules, but in that case, the section type construct is called a Rule and the document is known as Rules. In this case, this naming practice is nearly universal.

      We find this same inconsistency with Bill Amendments. In some jurisdiction, each individual change is referred to as an Amendment and the collective whole are Amendments or an Amendment List. In other jurisdictions the individual changes are known as Instructions and the collective whole is the Amendment. This difference can be confusing when mapping to Akoma Ntoso as that schema implies the former convention as this is more common in Europe while the latter approach is more prevalent in the U.S.
    • Another area of confusion is the difference between an Annex and a Schedule. The European concept of an Annex is separate document treated somewhat as an attachment to the base document. However, a Schedule is different — it clearly a part of the Body of the document. While it is most often found at the end of the body of the document, in some jurisdictions which complex hierarchical structures, schedules can also be found at the end of any upper hierarchical level. This construct is one that cannot currently be modelled in Akoma Ntoso without resorting to akn:hcontainer although the proposed next version includes akn:schedule to rectify this.

    Mapping a jurisdiction’s legislation into Akoma Ntoso can be tricky. The mapping isn’t always straightforward and almost always an exhaustive analysis of the entire body of existing laws will reveal that there are no hard and fast rules. As existing law can’t just be “fixed” to be consistent, it is often necessary to come up with creative ways to handles the oddities that are found.