Legislative Drafting and Bill Tracking Software Problems: The 5 That Produce Defective Law, and How to Avoid Them

Why does the data model get scoped as documents so often?

Because that is what everyone sees. Drafters work in a word processor, the output is a document, the chamber prints documents, and the request in the room is usually described as making the drafting tool better. A developer without legislative experience hears documents with versions and builds a content management system, which is a competent piece of software solving the wrong problem.

The tell appears in the first design review. If the schema has a table called documents and a version number, and the amendatory display is produced by a person marking text, then the machine never learns what the bill does. Strike and insert becomes a picture of an amendment rather than a description of one.

The correct shape is that your codified law is held as structured data down to the smallest citable unit your jurisdiction uses, and a bill is a set of actions against that structure: amend this paragraph, repeal this section, create a new chapter. The amendatory view is then generated as a difference between current and proposed text, rendered in your chamber conventions, and the drafter edits the target text directly.

Test this before funding anything. Put a real section of your own code on a whiteboard, ideally one containing a table or a deeply nested paragraph, and ask the developer to model a single amendment to it. A team that has done this will immediately ask how you cite the smallest amendable unit and what happens when a subsection is renumbered.

What goes wrong when you convert your existing code into structured form?

It is the largest line in the project and the one most often quoted as a data migration. What you are actually doing is converting a body of law, produced over many decades by many hands, into a structure precise enough that a machine can address any paragraph of it unambiguously.

The problems are specific. Numbering conventions changed over time, so a chapter enacted in one era nests differently from one enacted in another. Some sections contain tables, formulas or maps that do not decompose cleanly. Historical notes, source credits and annotations are interleaved with operative text and only sometimes distinguishable by formatting. Repealed and reserved sections have to be represented rather than dropped, because bills still cite them. And whatever your commercial publisher hands you is shaped for printing rather than for addressing.

The other trap is treating conversion as a one time event. Errors will be found for years, so you need a correction workflow with an approver, a reason and a history, and you need to know which bills were drafted against a section before it was corrected.

Scope conversion as its own funded workstream with its own acceptance criteria, running before the drafting editor is built rather than beside it. Accept the sections that convert cleanly, quarantine the awkward ones for expert handling, and require the developer to demonstrate round tripping on your ugliest chapter before you accept the approach.

Why does bill tracking break once real procedure meets it?

Because commercial tracking products model a bill as a row with a status, and your chamber does not work that way. Readings must occur on separate days unless a rule is suspended. Referral depends on subject and sometimes on 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 run on their own clock with their own author.

A status field records history. It cannot prevent a mistake, cannot build a calendar from the bills that are genuinely eligible, and cannot tell a member's office what happens next in any useful way. So clerks keep parallel spreadsheets, and the spreadsheets become the real system while the software becomes the place things are typed afterwards.

The second failure is chamber divergence. The two chambers rarely agree on conventions, and a build that models one and configures the other usually ends up modelling the first properly and bolting exceptions onto the second. Both sets of rules need to be data from the start.

Encode the rules, and make the system refuse or warn before a procedurally invalid action is recorded. Then the calendar, the journal and the daily status report all fall out of the same event stream rather than being assembled by hand at the end of a long day.

What happens when engrossing, enrolling and codification are left for phase two?

You get a system that drafts well and hands off to the same manual work you were trying to eliminate, at exactly the point where errors become law.

Engrossing means incorporating adopted amendments so the version moving forward reflects what was voted. Enrolling produces the final version for signature. If amendments are structured actions, both are computations and the human task shrinks from checking whether text was applied correctly to checking whether the right amendments were marked adopted, which is a far smaller and safer surface. If amendments are documents, both remain typing jobs against a floor deadline.

The deeper cost is codification. When the enrolled act carries structured amendment actions, updating the statutes becomes an assisted process where the system proposes changes and the revisor approves each one, with effective dates applied per section so the code can be rendered as of any date. When it does not, the revisor's office does the same manual work it always did, and the point in time capability that turns a research project into a query never arrives.

You do not have to build all of it in the first release, and you should not. What you must do is make the first release produce the structured record the later phases need, because retrofitting that means redrafting every bill written in the interim.

Should you build custom or buy from the two vendors who serve this market?

Talk to Xcential and Propylon before you talk to anyone else. This is a small market and both have delivered real legislative systems. Xcential built LegisPro as a markup based drafting environment with genuine experience of legislative schemas, including the work around Akoma Ntoso and the markup used federally. Propylon has delivered drafting and codification for multiple jurisdictions and understands the codification end deeply. If your amendment conventions, journal format and referral rules sit comfortably inside what either product already models, buy, and do not let anyone talk you into a bespoke programme.

The build case is fit and control rather than capability. Configuration surfaces are large but finite, and if your conventions fall outside them you are funding a change request queue at a vendor who is simultaneously serving legislatures with different conventions. The other argument is longevity. A drafting and codification system is a twenty year asset and the alternative supplier pool is very small, so some jurisdictions decide that owning the schema, the converted code and the repository outright is worth a higher initial cost. That is a defensible institutional position rather than a technical preference.

If you only watch bills, do not build any of this. A lobbying firm, trade association or agency needs a tracking subscription, and the drafting engine and codification pipeline are the expensive parts you would never touch.

How do hidden costs get into a legislative software quote?

Five places. Code conversion is first and largest, and it depends entirely on what shape your current publisher hands you the text in. Ask for a sample of your ugliest chapter and have it converted before anyone commits to a number.

Second is chamber divergence. Two chambers with different amendatory conventions, different journal formats and different committee rules is closer to two projects than one, and quotes written against one chamber routinely miss it.

Third is the public facing side. Your bill site is held to accessibility standards that no vendor demonstration will show you, and it should share a data model with the internal system rather than being fed by an export. Retrofitting accessibility into a published site late is expensive and visible.

Fourth is integration with the chamber's existing infrastructure: the voting system, the calendar, the fiscal note process and whatever the clerk's office already runs. Each is a separate negotiation as much as a separate build.

Fifth is the calendar itself. There is one non negotiable scheduling rule in this category: go live between sessions. A drafting cutover during session is not a risk to be managed with a rollback plan, because your drafting attorneys have no capacity to learn a new tool while bills are moving and the deadlines are fixed. A slipped delivery therefore does not cost weeks. It costs a year.

What separates a drafting system that works from one that gets abandoned?

Three things. The first is that drafters were in the room from the beginning and their conventions were treated as requirements rather than preferences. Drafting offices have precise habits about how amendatory text appears, how repeals are shown, how a new section is numbered against reservations the revisor holds. Software that gets those wrong is rejected quietly, by people continuing to use their word processor, and you will not hear about it until the session ends.

The second is conflict detection that works on structure rather than on text. When two live bills touch the same paragraph, the system should flag both bill numbers and the specific unit in week three, not at enrollment when volume has tripled and reading capacity has not. This is the highest value automated feature in the category and it is only possible if the model is right.

The third is ownership. The repository, the schema and the converted statute data should be yours from the first commit, with the right to hire anyone else at any point. The converted code alone is a multi year institutional asset, and in a market with very few suppliers, the ability to move is the only real negotiating position you have.