RegioWizard

The AW-Wiki at aw-wiki.de has spent years collecting what is known about the Ahrweiler district: clubs, buildings, vineyards, hiking trails, councils, companies, events, people. Roughly 39,000 articles in the main namespace, written and maintained by people from the region.

To find something there, though, you have to know what you are looking for. A search box does not answer “which clubs in Dernau were affected by the flood?”. It finds pages containing the word Dernau. A human does the rest.

That is exactly the gap: the corpus exists, the questions exist, and what is missing between them is a system that connects the two without inventing anything. RegioWizard is our answer - a running prototype, not a concept paper.

Everything in the prototype reads the same local index. There is no second data source that could drift out of step.

1. Ask - sourced answers in full sentences, with filters and a retrieval trace.
2. Atlas - every geolocated entry on one map, flood layer optional, neighbourhood within 3 km.
3. Insights - structure and time depth of the corpus, plus the editorial desk.
4. Newsroom - a diff of fresh press copy against the wiki.
5. 14/15 July 2021 - documentation of the flood night, built deliberately restrained.
6. Pipeline - the state of ingestion, index and models, in the open.
7. Article view - every article as a reading copy, linking back to the wiki original.

Plus a command palette on Ctrl + K that holds all 4,295 titles: type, jump. If it matches nothing, your input is passed on as a question.

This is the rule everything else hangs off. The language model writes only from the passages retrieval found beforehand, and marks every assertion with a footnote. The footnote is clickable and opens the passage it came from - title, section, wording.

The more important part is the case without a model. If none is configured, the system invents nothing and reports no error either: it shows the best-matching sentences from the wiki, verbatim and cited, with the retrieved passages in full underneath. This extractive mode is a first-class path, not a failure state.

There is a practical reason for that. A newsroom that repeats a figure stands behind it. A tool that merely asserts a source instead of showing it is worthless in that position.

“Who from the region has a birthday today?” sounds like a question for an AI. It is a database query, and vector search answers it reliably badly: it finds texts that talk about birthdays, not people whose birthday is today.

So the prototype detects these questions and routes them to fixed queries over the structured fields - birth and death dates, founding years, coordinates, categories. Answered this way: anniversaries on a date, recorded deaths in a year, foundings, proximity, and - the case newsrooms care about most - coverage gaps: articles that are referenced often but are themselves thin or missing entirely.

The result is a table of name, date and source. Not prose guessing at numbers.

Under every answer stands how it came about: how many candidates the keyword stage produced, how many the vector stage, how many survived the merge, how many actually reached the answer, and how long it took. In the run shown: 72 lexical, 72 fused, 12 kept, 120 milliseconds.

Retrieval itself is built for German. Umlauts are folded, stems reduced, compounds expanded - Weinbau also matches Weinbaubetrieb. Every passage carries a fixed header of title, section, type, place and categories, so it stays interpretable once lifted out of its article.

We do not show this out of engineering pride. Anyone reusing a statement should be able to see how thin or how broad the basis was.

A regional wiki goes stale exactly where the present happens - in the local section, the free weekly, the club's press release. The newsroom sees those items every day anyway. Transferring them into the wiki costs time nobody has.

The editorial desk takes a text and compares it against the corpus. People, clubs, companies and places are detected; each find is checked against existing articles and gets one of three states: already covered, article exists, statement missing, no article. In the example shown: 8 entities, 5 without an article, 3 with a possible extension.

Every proposal comes with a draft in wiki format to copy. What matters is what the system does not do: it writes nothing into the wiki. The selection stays with the editors - not a technical limitation, but the division of labour we consider correct.

The corpus holds a substantial number of articles relating to the flood of 14/15 July 2021. A page for it was unavoidable - the question was what it may look like.

We put it under fixed constraints, and those constraints are part of the product, not a matter of style: a notice before the content, no victims' names, no imagery, no animation, no counting-up numbers, no engagement mechanics, a muted palette distinct from the rest of the application.

Figures on that page stand with their source. Where sources differ, the difference is named rather than smoothed over.

Honestly about scope: 4,295 of roughly 39,000 articles are ingested, selected by relevance to the typical questions. They yield 20,543 passages, 68,992 index terms and 1,040 geolocated entries. Ingestion respects the wiki's rate limits; for a full copy a database export would be the right route, not 39,000 individual fetches.

The application runs entirely locally: corpus, index and vectors live as files in the project folder. No database, no external service, no tracking, no cookies - the only third-party request in the browser is the map tiles.

Every illustration in the prototype is a drawing, produced with an image model and labelled as such. None of them depicts a real place, a real building or a real person. That is deliberate: an application whose entire claim is that facts carry sources must not ship a picture anyone could mistake for a photograph.

The images below this section come from the first version of 2025 - the original chatbot draft the idea began with. They stay because they show where the project came from.