Dev.to WebDev 🛠 Dev 👁 0 📖 3 min read

Building AI Senatus: Wording the Motion Before Anyone Argues It: What Worked, What Broke

Most policy arguments do not fail because people disagree. They fail earlier, because people are arguing about different proposals while using the same words for all of them. One person hears a proposal as a ban, another

Most policy arguments do not fail because people disagree. They fail earlier, because people are arguing about different proposals while using the same words for all of them. One person hears a proposal as a ban, another hears it as a limit, a third hears it as a funding change, and the thread that follows is three debates at once.

Building a public debate product made that problem impossible to ignore. If the question at the start is vague, the cases that follow drift, the evidence stops lining up, and a vote at the end settles nothing, because nobody can say exactly what was approved or rejected. The build therefore put the wording step first, before any argument was allowed to start.

Designing the wording step

Three choices shaped this part of the build.

First, a useful motion has to name four things in plain language: who would act, what would change, where it would apply, and when it would be reviewed. Leave any one of those out and readers fill the gap with the most extreme or the most harmless version they can imagine. Fill all four in and supporters and critics are at least arguing about the same world, with the same costs and the same exceptions in view.

Second, the motion stays fixed once debate opens. Early versions allowed quiet edits while arguments were coming in, which felt flexible and turned out to be corrosive. A case built against version one would suddenly be answering version two, and trust in the final vote fell. Locking the text, and requiring a new motion for a changed proposal, made the record readable later.

Third, the wording is shown again at voting time, word for word. Not a summary, not a headline, the actual motion. That repetition sounds redundant until you watch a close vote where half the room is voting on their memory of the opening post.

What worked

Precision protected the losing side, which was the least expected benefit. When a motion is precise, a defeat is precise too. Critics can point to the exact clause that failed, see which evidence was not accepted, and know what a revised proposal would need to change. Several of the most useful follow up discussions started from that clarity, not from winning.

The four part check also shortened arguments in a good way. Once scope and review date were on the table, a lot of speculation disappeared, because it was speculation about a version nobody had proposed. The debate got narrower and deeper at the same time.

And the discipline travelled outside the product. Council style decisions, workplace choices, even family arguments about money improve when the question on the table can be repeated, word for word, by everyone in the room. That was not a planned outcome, it was just hard to unsee once the pattern was built in.

What broke, or nearly did

Wording took longer than expected, and that nearly killed the flow. If drafting a motion feels like filing a form, people rush it or abandon it, and the debate never starts. The fix was to keep the four prompts short and in ordinary language, with examples inline, so the check takes minutes rather than turning into paperwork.

Over precision broke things in the other direction. A few early motions tried to settle every edge case in the opening text, grew to paragraph length, and became unreadable. Nobody argued about them because nobody finished reading them. The lesson was that a motion needs to be complete enough to judge, and short enough to hold in memory while listening to a case.

The honest limit is that clear wording does not create agreement. It only makes disagreement legible. That is less satisfying than a tool that promises consensus, and it is also the part that makes a final vote worth anything at all.

Lessons for builders

Put the definition step before the discussion step, and protect it in the interface. Any product that collects opinions on a proposal will inherit the quality of the proposal text it allows at the start.

Lock the thing being judged once judging begins. Version drift during a decision is a quiet trust killer, in debates and in code reviews and in approvals alike.

Show the exact question again at the decision moment. Summaries drift toward what each reader wanted the question to be. The original wording does not.

The project behind these lessons is AI Senatus, where a motion is set out plainly, cases are argued for and against in sequence, and votes are cast on the question as written.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.