The House Is Back, and So Is Trillium

The last few weeks have been exciting for me. Not just because I spoke at my first conference in two years in Spain at “J on the Beach”, but also because the House at the Ontario Legislative Assembly met for the first time since the spring, and I now had an opportunity to test all the changes I’ve been making to Trillium over the past couple of weeks.

This post is going to go into what worked well and what didn’t in this first couple of weeks back.

🟢 Summary gives a better sense of the bill’s contents and impacts

I’m pretty certain this is a result of the changes I made to the “judge” model that determines if summaries need further revisions, and increasing the maximum amount of tokens that the LLM was allowed to return in API calls (see this previous blog post for more details).

🟢 New bill prioritization using Hansard has been working spiffily

Shout to Matt Elliott from the Toronto Star and City Hall Watcher for this suggestion.

For those who aren't aware, the Ontario Legislative Assembly publishes the transcripts of meetings in the Hansard search system.

Matt had suggested that I use these transcripts to prioritize the bills in the newsletter, so that the ones that have more debate in the House bubble up to the top, and the ones that are debated on less (or not at all) about are pushed further down in the newsletter.

Now that this has been added, bills that likely should get more attention and scrutiny will be among the first to appear in the generated newsletter.

🟡 Vague titles used

In a couple of the generated summaries for specific bills, the AI would say that a “director” or a “Minister” had powers to take a particular action, but didn't clarify which director or minister this was.

For example, in a bill that gives a minister the ability to appoint or remove a head of council in some municipalities, the AI merely wrote “Minister”, not “Minister of Municipal Affairs”.

At a minimum, not specifying this can lead to the summary being somewhat useless, but what I particularly don’t like about this outcome is that it doesn’t empower people to reach out to that Minister if they have thoughts or concerns they want to share and advocate for.

🟡 Newsletter body in Buttondown is unformatted when submitted via an API request

Although it doesn't render in a way that makes it obvious that this is happening to the end user, the way the text is rendering in in the Buttondown editor when I've submitted it via an API request prevents me from making any changes without breaking all the formatting.

This is something that I plan on taking a closer look at because right now my solution has been to save a copy of the generated markdown locally as a file, so that if I do need to make changes I can modify and copy/paste the contents of that file rather than edit it within the Buttondown editor directly.