Event Scout

An event page is a poor data format. The same detail appears once as a table, once in the running text of a newsletter, once in a calendar that only loads after scrolling. A regular expression fails on that; a language model does not. That is exactly where, and only where, the model sits: it reads the fetched pages, decides what counts as a future in-person event within reach, and fills in the fields of a fixed schema for each one.

Everything before and after is ordinary code. Which sources are due today, how they are fetched, when two entries are the same event, what drops out of the record after a year and what the dashboard looks like are written in code, not in an instruction to the model. Nor does the model write to the record itself. It delivers a file, and a script merges that file into events.json by fixed rules.

That file is the contract. It has a defined schema, it is the single source of truth, and every view is generated from it. There is no database, no server and no subscription. The most important practical benefit follows from that: when something looks wrong, you can open the file and see whether the fault lies in the reading or in the rules.

Rules being code does not make them correct. The first version of the deduplication treated two entries as the same event as soon as they carried the same link. Many organisers, however, list every date of a series under a single overview page, and so in one run 23 new dates vanished into their older predecessors. It was noticed because the fault left a trace that could be checked: past events marked as found again today. Since then a matching link only counts as a hit when the start dates are no more than three days apart.

A language model is good at reading a messy page. Keeping a record is not that kind of task.

A source queried equally thoroughly every week costs time even when it has produced nothing useful for months. So every source keeps a short yield history: how many events the model kept from it over the last five runs. The average places it in one of three bands. The model's judgement therefore steers the schedule only through a counted number.

Band A is queried on every run. It holds sources averaging at least three kept events and sources rated as especially important, even after an empty run. Band B holds sources with some yield or no history yet; they are due again after seven days, at most eight per run, oldest first. Band C collects sources that repeatedly deliver nothing. They pause for seven, then fourteen, then twenty-eight days, thirty at most, and are then tried again, at most three per run.

A page that loads but shows no events only moves down the order. A source counts as broken only after it could not be fetched three times in a row. New sources come, among other places, from a register of public networks, accelerators, research institutes and clusters in the region: if an organisation there has an events page that is not yet in the source database, it can be added. The register itself is never read as an event source, so that nothing is counted twice.