Legislative Drafting Software: Why a Bill Is a Patch Against the Code, Not a Document

The session clock does not care that your drafting tool is Word

It is week three of a 90 day session. A drafting attorney in legislative counsel has three bills in front of her, and a request that came in an hour ago from a member who wants an exemption added to a licensing statute. She opens the current code section in a browser window, copies the text into Word, applies a macro that somebody in the office wrote in 2011 to make deletions strike through and insertions underline, and starts editing. The macro breaks on the subsection that has a table in it. She fixes the formatting by hand. Two weeks later the bill gets a committee substitute that rewrites half of it, and she has to regenerate the whole strike and insert view against a base that a different bill has already amended.

Every legislature runs some version of this. The tooling varies from genuinely good XML systems to Word with macros to, in a few places, a mainframe text system that one retiring employee understands. What does not vary is the shape of the problem: a bill is not a document. It is a patch against a body of codified law, and the value of the drafting system is entirely in how well it understands that.

The cost of getting it wrong is not measured in staff hours. It is measured in defective law. A strike and insert that references a subsection that was renumbered by a bill enacted the previous session produces a statute that does not say what the legislature voted for, and the fix is another bill next year, or litigation.

Problem 1: a bill is a patch, and most tools model it as prose

When drafting is done in a word processor, the amendment instruction and the amended text are the same artifact: a human typed the strikeouts. Nothing in the file knows that this bill amends section 12 subsection b paragraph 3, or that it repeals a section entirely, or that it creates a new chapter that has to be numbered without colliding with anything the revisor has already reserved.

What a real drafting system does is hold the code as structured data, down to the smallest citable unit your jurisdiction uses, and hold the bill as a set of amendment actions against that structure. Strike and insert is then a rendering of the difference between the current text and the proposed text, generated rather than typed. The drafter edits the target text directly and the system produces the amendatory display in the conventions your chamber uses, including whether you show the whole section or only the amended subsection, whether repealed language appears at all, and how you handle a table or a formula inside an amended subsection.

This is the piece that cannot be approximated. If the amendatory view is typed by a human, then every downstream promise about accuracy, conflict detection, and automatic codification is false, because the machine never knew what the bill actually did.

Problem 2: amendments compound, and the base keeps moving

A bill is introduced, gets a committee amendment, gets a committee substitute that replaces the whole text, goes to the floor, picks up two floor amendments, one of which is amended, then goes to the other chamber and the process repeats. Somewhere in there another bill amending the same section passes first, which means your bill's strike and insert is now drawn against a base that no longer exists.

Legislatures handle this today with a revisor or a codifier who catches conflicts by reading. That works right up until the last two weeks of session, when volume triples and the reading capacity does not. Conflict detection is the single highest value automated feature in this category and almost nobody has it working properly, because it requires the amendment actions to be structured, which returns you to problem one.

A custom build models this as a chain: the introduced version, each amendment as a set of actions against a specific version, and a resolved current text computed at any point. When two live bills touch the same paragraph, the system flags it with both bill numbers and the specific unit in conflict, and it flags it in week three rather than at enrollment. Floor substitutes get modelled as a full replacement action rather than as a new document, so the lineage stays intact.

Problem 3: engrossing and enrolling is where errors become law

Engrossing means incorporating adopted amendments into the bill text so the version moving forward reflects what was actually voted. Enrolling means producing the final version for signature. In many chambers both are still substantially manual: somebody applies the adopted amendments by hand, another person proofreads, and the clock is a floor deadline.

If amendments are structured actions, engrossing is a computation, not a typing job, and the proofreading changes from checking whether the text was applied correctly to checking whether the right amendments were marked adopted. That is a much smaller and much safer surface. The enrolled version then carries a machine readable record of exactly which units of code it changes, which is the input the codification step has needed all along.

This is also where journal and calendar production stops being a separate chore. Every action that changes the bill is already an event with a timestamp, an actor, and a vote outcome. The journal is a report over that event stream rather than a document somebody assembles at the end of the day.

Problem 4: bill tracking is not a status field, it is your chamber's rules

Commercial tracking products model a bill as a row with a status. Your chamber does not work that way. Readings have to occur on separate days unless a rule is suspended. Referral is to a committee determined by subject and sometimes by a second referral for fiscal impact. Crossover deadlines kill bills that have not moved. A bill can be recommitted, laid on the table, discharged from committee by petition, or die in conference. Fiscal notes have their own clock and their own author.

Encoding those rules is the difference between a system that reports history and a system that prevents mistakes. When the rules are in the system, the calendar can be built from the bills that are actually eligible, the clerk gets a warning before a procedurally invalid action is recorded, and a member's office can be told the real answer to what happens next rather than a status label.

Problem 5: the enrolled act has to reach the published code

After the session, somebody has to take every enacted bill and update the statutes. In most states this is the revisor's office doing careful manual work over months, resolving conflicts between acts, applying effective dates that differ per section, and renumbering. The published code then lags, and the version citizens and courts read is a compiled product that may be a year behind, sold by a commercial publisher.

If the enrolled act carries structured amendment actions, this pipeline becomes assisted rather than manual: the system proposes the code updates, the revisor reviews and approves each one, and effective dates are applied per unit so the code can be rendered as of any date. Point in time code is the feature that surprises people with how much it is worth. A court asking what the statute said on the date of an offense is currently a research project. It should be a query.

What Propylon and Xcential LegisPro actually do

This is a two vendor market for a reason, and both vendors are serious. Xcential built LegisPro as an XML drafting environment and has real experience with legislative markup standards, including the work around Akoma Ntoso and the United States Legislative Markup used federally. Propylon has delivered drafting and codification systems for multiple jurisdictions and understands the codification end deeply. If you are a state legislature, you should talk to both before you talk to anyone else, and this guide is not going to pretend otherwise.

Where a custom build enters the conversation is fit and control. These systems are configured to your chamber, and the configuration surface is large but not infinite. If your amendment conventions, your journal format, or your committee referral rules fall outside what the product models, you are buying a change request queue and a long one, because the vendor is serving other legislatures with different conventions. The other consideration is longevity: a drafting and codification system is a 20 year asset, and the vendor pool is two. Some jurisdictions decide that owning the code and the data model outright is worth the higher build cost, and that is a defensible position rather than a technical preference.

What this costs and how long it takes

A first release with the structured code repository, the drafting editor, generated strike and insert, and rules aware bill status runs $120,000 to $260,000 over 5 to 8 months. The full program adding amendment handling through floor substitutes, engrossing and enrolling, journal and calendar generation, conflict detection, and the codification pipeline runs $400,000 to $1.2M across 12 to 24 months.

What drives the cost in this category specifically: converting your existing code into structured form, which is the largest and most underestimated line and depends entirely on what shape your current publisher hands it to you in; the number of distinct amendatory conventions your chambers use, because two chambers frequently disagree; whether you need the public facing bill site and the internal system to share one data model, which you should; and accessibility, because a legislature's public site is held to a standard that a vendor demo will not show you. What keeps cost down: doing the drafting and code repository first and leaving journal automation to a later session, and resisting the urge to replace the member and lobbyist facing tracking site in phase one.

One scheduling rule overrides everything. Go live between sessions. A drafting system cutover during a session is not a risk to manage, it is a decision not to make.

How to choose a developer for legislative systems

Ask them to model one real amendment on a whiteboard, using a section of your own code that has a table or a nested paragraph in it. A developer who has done this will immediately ask how you cite the smallest amendable unit and what happens when a subsection is renumbered. One who starts by drawing a documents table has built a content management system and is about to learn legislative drafting on your budget and your session calendar.

Ask what they know about legislative XML. They do not have to commit to Akoma Ntoso, and there are good reasons a specific legislature might not, but they should be able to explain the tradeoff between a standard schema and a schema shaped to your conventions, and why the answer affects your ability to leave later.

Ask how they would handle conflict detection between two live bills touching the same paragraph, and listen for whether they treat it as a text diff or as an overlap between structured amendment actions. Only the second one works.

Ask who owns the code, the schema, and the converted code data, and get it in writing before kickoff. At Digital Heroes the client owns the repository and the infrastructure from the first commit and can hire anyone else to continue. The right next step is a scoping session where you bring three bills from your last session, one clean, one with a committee substitute, and one that conflicted with another act, and have the developer walk you through how each would move through their model.