PR-02: can people find council stuff in their own words?

Hey Kazim! Here's where my half is at · Michael · Oct 11, 2026

Quick recap: PR-02 asks whether a regular person can find a San Bernardino council item without knowing the meeting date or the official jargon (FR-02, plus US-01, FR-07, MU-04, NFR-02, NFR-03, V-02). I built a little search test app, loaded it with every agenda item from six summer 2026 meetings, and put it online. The family test just kicked off.

What I did

1. Kept the experiment simple

Since we agreed the prototypes can be throwaway, I didn't build a formal user study. The setup:

• You get a plain-English scenario, like "You heard the city is buying a new truck that fixes potholes. Find the council item about it." Then you just search however you'd normally search.
• It counts as found once you open a correct record. You can also give up.
• The timer starts at your first keystroke. I left out a visible countdown on purpose, since rushing people would mess with what we're trying to measure.
• Everyone gets 5 of 20 topics. The app hands out the least-used ones first, so people in the same house mostly get different ones.
• Nicknames are optional and there are no real names. Your results and mine are tagged "team", separate from family.

2. Got the real records

• The city's records are spread across three places: PrimeGov (its robots.txt blocks all crawlers, so I stayed off it), the Laserfiche WebLink archive (agenda packets and minutes), and Cablecast (meeting videos).
• I grabbed all 143 numbered open-session items from the six meetings: title, staff-report text, outcome, section, attachment links, and the official source link. I saved proof that every source link actually loaded.
• I went 5 records → 30 → all 143, and kept the original 30 exactly as they were.

3. Built the app and put it online

• Front end: plain HTML/JS with Pico.css, no build step. Works fine on a phone.
• Search: MiniSearch, running in the browser. It's deliberately dumb keyword search: titles count 3× more, it matches word beginnings, it forgives small typos, and it has no synonyms. That way we get a baseline, and later we can replay everyone's searches against smarter versions offline.
• Back end: Cloudflare Pages Functions + a D1 (SQLite) database. It logs every search, the results people saw, what they clicked and whether it was right, timing, and when they switch away from the tab (so a phone call doesn't wreck their time).
• Doesn't break easily: results get saved even if the connection drops, a reload picks up where you left off, and the API rejects junk input. I also ran a keyboard-only end-to-end test with a fake XSS record thrown in.

4. Wrote 20 topics

Each one describes a real item the way you'd hear about it from a neighbor. I checked every topic against all 143 records for other correct answers and for lookalikes that aren't the answer. A few have more than one right answer; the McDonald's drive-through fight, for example, came up at three different meetings.

What I've learned so far

The jargon gap is real, and plain keyword search falls into some of it

Before anyone tested, I typed what I figured a normal person would search for each topic:

Honestly, more of these worked than I expected. Even when the title is pure jargon, the staff report usually says it in normal words somewhere, so searching the full report text (not just titles) matters a lot. The misses happen when the everyday word never shows up in the record at all, like brand names (Airbnb) or alternative terminology (marijuana). That's where synonyms or semantic search would help. The family test should show how often real people run into this.

Missing text is another obstacle

• 41 of the 143 records have no report text, so you can only find them by title. 32 of those are from June 17, because I couldn't find that meeting's packet. So when a search fails, it isn't always the jargon's fault.
• The city hasn't posted the August minutes yet, so 48 August items have no outcome. I didn't guess outcomes from the staff recommendations.
• The search looks at title, report text, and section, not outcomes.

Stuff that's probably useful for your importer (PR-01)

• Don't trust the PDF text: some pages had text, just not all of it. Six pages needed OCR, which I checked against the page images. Same thing you found: having some text doesn't mean you got all of it.
• Finding where a report ends is annoying. Packets mash the staff report and its attachments together, so you have to stop at the attachment list. One report just mentioned "Attachment 3" in a sentence, the extractor stopped there, and half a trash-rates report went missing.
• Minutes aren't in agenda order, and one item can have several results (the Airbnb-style rental item: ban denied, and staff told to come back with rules). Match outcomes by title.
• Laserfiche quirks: folder listings come 40 at a time, and you need getNewListing=false after the first page. PDF exports sometimes lose their session and need a retry. The temporary export URLs aren't good permanent links.
• I left the city's typos and mismatches as published (e.g. "pproval", dollar amounts that disagree) and didn't fix them.

Little things

• The intro screen's made-up example was "new fire truck," and then a real asphalt-truck purchase came up #1 for it. The example is supposed to find nothing, so I swapped it for a swimming pool one.
• I cut a "park restroom" topic because two different records both buy restroom buildings, so you couldn't tell which one was the answer.

Next

1. Get the family test done (it started tonight), plus our team runs. You've already got the link, so go for it whenever.
2. Pull the results out of D1 and dig in with Python: how often people found it, how long it took, what they actually typed, and what they missed.
3. Replay everyone's searches against smarter options (synonyms, title-only vs. full text, semantic search) to see what would've helped.
4. Talk through the importer stuff above when we sit down on PR-01 and the final architecture.