If you are familiar with stack machines, it turns out that you also understand the broad strokes of how most US legislative bodies operate.
Seeing the commonality will instill in you the sense of awe that only reading execution traces from an operational quarter millennia old computer can.
Brief context for this post
I recently spent some cycles working on a parser for legislative journals from the Missouri House of Representatives. The journals are hand-written in Microsoft Word, and so are prone to human error. Because of this the first parser, a naive line-by-line regex thing, was a failure. Expecting the journal to be well formatted enough to just read front to back was not going to cut it.
My second attempt included code that tried to comprehend what the legislative body was doing as it read the journal. By tracking the current state, recognizing actions taken and the rules that apply to them, it could catch errors. If it thought something had happened that violated parliamentary rules, it likely meant a parsing error.
As I wrote it, something felt familiar. I had written exactly this kind of code before.. when implementing a JVM.
I’d written a stack based virtual machine, the journals were programs that it could execute, and legislation was the side effects it produced.
Parliamentary procedure
US Legislative bodies generally follow one of three manuals for how to operate. Either they use Jefferson’s Manual, Mason’s Manual, or Robert’s Rules of Order. Mason’s Manual and Robert’s Rules are both modeled on Jefferson’s Manual. Jefferson’s Manual is modeled after the Westminster procedures, the virtual machine spec used to legislate in England and much of the old commonwealth.
The rest of this will be drawn from Jefferson’s Manual, though I think it applies quite broadly to the other approaches as well.
I want to make it abundantly clear up front: My understanding of parliamentary procedure is very thin. Expect there to be - and point out if you see - errors. Focus on the broad strokes.
Bodies and motions
The basic idea is that the group making decisions - a Senate, House of Representatives, Parliament, Organizational Board or any other group that’s decided to follow these rules - is a body and the body makes motions (get it?).
In computer parlance, the body is a machine and each motion an operation.
A body that makes motions! Isn’t it a wonderful abstraction?
Motions, briefly
In a computer, whether you can perform an operation depends on context. You can’t ask the JVM to add two numbers together if your top stack items are all strings. That would be a violation of the rules.
The same thing is true for motions. Whether a motion is executed - adopted - depends on both static rules like in a VM spec, but also on voting.
So, motions are proposed by members of the body, and rules then govern whether they are adopted, or executed.
There is set of motion types. Each type - just like operators in a programming language - have different rules. The rules include things like:
- precedence (because there can be race conditions1!)
- context required to propose it
- whether it needs a second - ie. another member of the body joining you in proposing the motion
- votes - if any - needed to adopt it
- whether debate is allowed
- et cetera
The exact rules around motions differ between legislative bodies, because metaprogramming is allowed. There’s a section about this further down. For now, the short version is that each body may have changed the rules to fit their needs.
As an example, there is a motion type called lay on the table, which sets the initial stack frame. That motion generally requires a simple majority to adopt, requires a second, and is not debatable.
The stack
Motions exist in a stack.
When you propose a motion, you are adding it to the top of the stack. Hence, at any given time there is at most one motion that is active, the one at the top of the stack.
Note that there is a diffrence here from most virtual machines we know. In computer science, stacks generally contain state, while the operations manipulating the state exist separately from the stack.
Here, everything is a motion, and motions exist on the stack.
Even motions that mutate the stack go on the stack. If they are adopted, they would have their effect applied, otherwise their stack frame is simply discarded and we’re back to whatever frame was below.
The initial stack frame must be from a class of motions called main motions. This will generally be some piece of legislation or declaration for the body to consider.
An example
When the machine starts executing, the stack is empty:
<nothing here>
Some member would propose a Main Motion for the body to consider. The Main Motion differs from other motions - called Subsidiary Motions - in that it is not an action. The Main Motion, rather, is more like “Lets work on this thing”.
[MAIN Name: HB1337, Contents: <bill text>]
Now that there is a Main Motion, we are allowed to propose Subsidiary Motions.
Someone now proposes to Amend the legislation in the main motion. Amending is a motion to apply a diff to the parent stack frame.
[MAIN Name: HB1337, Contents: <bill text>]
[AMEND Name: Amendment No. 1 to HB1337, Diff: <Diff to apply>]
Someone else likes this idea, but wants some minor change to the diff, so they propose to amend the amendment:
[MAIN Name: HB1337, Contents: <bill text>]
[AMEND Name: Amendment No. 1 to HB1337, Diff: <Diff to apply>]
[AMEND Name: Amendment No. 1 to Amendment No. 1 to HB1337, Diff: ..]
At this point, someone else is getting tired of all this, doesn’t think any of these amendments will pass and wants to force a vote to pass the main motion. They can do this with the Previous Question, or PQ, motion. If the PQ motion passes, it clears all stack frames other than the first one, and then forces a vote on the first motion.
I find this rather beautiful. The operator to modify the stack itself goes on the stack, and is voted on:
[MAIN Name: HB1337, Contents: <bill text>]
[AMEND Name: Amendment No. 1 to HB1337, Diff: <Text diff to apply>]
[PQ]
If the Motion to the Previous Question is adopted, the stack is cleared, and the first stack frame is mutated so that a vote is now required - no more motions until that’s done:
[AMEND Name: HB1337, Contents: <bill text>, VoteRequired: true]
The body would now move to do something useful with the main motion it’s been manipulating. Perhaps move to Pass it and make it law, or Commit it to a committee to be worked on.
Once the main motion is done with, the stack is again empty and another main motion can be Taken Up.
Using this model to understand the Filibuster
In the example above, we used two types of subsidiary motions. Here are some of the rules that normally apply to these motion types:
| Motion | Debatable? | Amendable? | Votes required |
|---|---|---|---|
| Amend | Yes | Yes | (N/2) + 1 |
| Previous Question | No | No | N * (2/3) |
Using only these two motions, you can understand the oft-discussed Filibuster! As you can see, you only need a simple majority to Amend, but you need a two-thirds majority to PQ.
In other words, making legislation is generally simple majority rule, but stopping debate using the PQ motion has a higher bar.
The idea here is simple: The majority should not be able to completely silence the minority.
However, the spec here has a vulnerability. What if the minority is in such opposition to the motion being proposed that they are willing to burn all their bridges to the majority, and.. debate forever?
The body then becomes gridlocked, because there is no motion available in the spec to halt, unless you have a two-thirds majority.
This vulnerability is what we call the Filibuster. The Filibuster is a part of the Jefferson spec that allows programs that never halt. In the federal government, it only exists in the Senate, because the House used metaprogramming to reduce the two-thirds rule on the PQ operator to simple majority2.
Speaking of metaprogramming..
Metaprogramming
The spec allows for the spec itself to be taken up as a main motion. Get get goose bumps writing this, how cool is that!?
The machine can open up it’s own specification and rewrite it using the same mechanisms it uses to write legislation.
The proposal going around the Democratic party these days - in 2019 if you are in the future - of “removing the Filibuster” is essentially a proposed set of opcodes to invoke.
[MAIN Name: The Spec Itself, Contents: <Stuff Jefferson wrote>]
[AMEND Name: Amendment 1 to .., Contents:
Replace "N * (2/3) in rules for the PQ motion
with (N/2)+1]
And if that passes, the machine itself changes how it operates.
It brings warmth into the depths of my soul to think about the smart people that designed this stuff, hundreds of years ago, and the privilege it is to still see it in operation today.
Addendum
If you are keen, you can see these machines executing live by adding a calendar entry of the next legislative session at your state capitol and heading down to sit in the audience.
Or, you can read execution traces from recent sessions. Here is one from my local legislators in Missouri working to pass HB 1649, which would make assaults on dogs subject to harsher punishment than assults on women. It starts when a legislator proposes the “Take Up” motion, which sets the Main Motion HB 1649.
While my representative, of course, voted for this, you will be happy to know the legislation did not pass.
Just like the JVM, these old machines are being forced to run some really, really horrible code.
Notes
1 I’m struggling from writing all of this in all caps. Not only is it a stack based VM, it’s also implemented as a distributed system, with each representative a concurrently executing actor. There are a whole slew of really fascinating algorithms implemented to govern this concurrency.
2 I think this means that if you could find a valid program that runs on the version of the spec used by the House Of Representatives that does not halt, you will have found a new type of Filibuster and the ghost of Paul Ryan will be very excited for you.