Watch what an authority announces

A Czech municipality has to publish every decision it makes on its official noticeboard — the úřední deska. Building permits, land sales, zoning changes, demolitions: if an authority decided it, the notice is public. And every municipality publishes that same board as open data, in a national format, so it can be read as a feed rather than scraped off a web page.

That makes noticeboards useful for any work that turns on knowing early: a supplier who has to be specified at design stage, a builder looking for sites, anyone whose deal is decided years before the thing is built.

You need two things enabled on your workspace: Official Noticeboards, and — if you want to know who is behind a project — Business Register. Both are under Settings → Connections → Public Registers, and neither has anything to connect: open data needs no account or key.

Choose which boards to read

Open Settings → Connections → Czech Official Noticeboards. The watchlist starts with a spread of boards where building actually happens: Prague districts, the towns around it, and the regional cities. Edit it freely — one board per line, written as Name | address:

Praha 12 | https://www.praha12.cz/opendata-uredni-deska
Kladno | https://www.mestokladno.cz/opendata-uredni-deska

The address is the board’s open-data address, not the page a person would read. Municipalities list theirs in the national open-data catalogue at data.gov.cz. Clear the box entirely to go back to the starting list.

A few offices leave part of their certificate out

Three boards on the starting list — Praha 2, Praha 4 and Brno — run a web server that sends only half of what it needs to prove who it is. A browser papers over this by fetching the missing half itself, so the boards look fine to a person and are unreadable to everything else. Routario reads them the way a browser does, and their lines carry a third field saying so:

Brno | https://edeska.brno.cz/eDeska/opendata | complete-chain

Add that third field to any board that comes back complaining about a certificate. It is per board on purpose: Routario still checks the certificate in full, and still refuses a board whose certificate is genuinely wrong — the setting only allows for the one piece the office left out, and only on the board you put it on.

It is worth telling such an office, too. The same fault breaks every program that reads their board, not just this one, and it is a one-line fix on their side. When they make it, the check below stops saying Certificate completed for that board and tells you the field can come off the line.

Which offices we can read, and which we cannot

Under the watchlist is Every office, and whether we can read it — the standing record of every Czech building authority we have assessed: 32 of 38 are readable, and the other six are on it too, with the reason.

That last part is the point. A watchlist can only hold boards we can read, so before this record an office we could not reach was simply absent — and “are we watching Praha 5?” got silence from every screen, which reads exactly like yes. Four things an office can be:

Status	What it means, and what to do
Reading	The board answers and its notices come through.
Reading — certificate repaired	Answers, but only because Routario completes a certificate the office leaves half-sent. Worth telling them.
No open data	The office publishes no noticeboard dataset and answers none of the known addresses. Nothing to read until it starts.
Address is dead	It registered a board at an address that no longer answers. The board may exist elsewhere — worth looking again.

The Why column carries the specific reason for that office: which are large residential districts, which serve years of history, which publish notices with no attachment, which one reads fine from Routario and fails on a laptop.

Check that the boards are actually answering

Press Save and read every board now. The Last check column fills in with how many notices each board is serving and the range of posting dates it covers — and, for a board with the certificate problem above, whether it was actually read that way.

This is worth doing whenever you change the list, and worth doing occasionally when you have not. A board that quietly moves its address, or starts serving nothing, looks exactly like a quiet week from inside an automation — the run succeeds, it just finds nothing.

The record and the check are shown side by side rather than merged, because the row where they disagree is the one worth seeing: a board on record as readable that did not answer just now has almost certainly moved, and the table says so in the Why column instead of leaving you to spot it. A board you added yourself gets a row too, marked Added here — we have not assessed it, and the table says that rather than quietly leaving it out.

Two things people are usually surprised by:

• Boards keep years. Several serve their whole history — one Prague district goes back to 2008. That is useful once (you can catch up on everything that already happened) and a nuisance every week after, which is what the date window below is for.
• Not every notice has a document. Some boards publish only the title. Those notices still come back; there is just nothing to read.

Read the boards in a flow

Add a Read official noticeboards step. The two term boxes are an and: the title must contain one word from each.

Field	What to put in it
Title mentions	What the notice is about — bytov, obytn, rezidenc, polyfunk, bydlen
…and also mentions	What happened — rozhodnut, povolen, uzemni, zahajeni riz
Only notices posted in the last N days	10 for a weekly flow. 0 reads everything the boards still serve.

Matching ignores accents and capitals, so bytovy finds Bytový. Use word stems, not whole words: Czech declines everything, and bytov catches bytový, bytových and bytovými at once.

Leave the date window at 0 for the first run so you pick up whatever history is there, then set it to a bit more than your schedule — ten days for a weekly flow gives you three days of overlap.

Requiring both groups is what separates “a residential building” from “a residential building permit decision”. Either group on its own returns most of the board.

The step gives you back:

• notices — one entry per match, each with its title, the board it came from, when it was posted, when it stops being served, and document_ref: the notice’s document, already filed in your Memory. A board serves a notice for a couple of weeks and then stops, so the document is stored rather than linked — a URL saved on a row is a dead link by the time anyone follows it.
• counts — read notices_seen against matched to tell a quiet week from a filter that has stopped matching.
• failures — the boards that could not be read, each with its error. Branch on this and tell someone; it is the one output you should never ignore.

Each notice also carries a source_key, a stable id for that notice. Use it as the upsert key on a Create record step and a re-run updates the row instead of adding a second one.

Don’t filter on numbers in the title

It is tempting to keep only the notices that mention how many flats a building has. Don’t. Most notice types — a change, an invitation to inspect the file, a notice that a document is ready for collection — never restate it, and they are about the same projects as the notices that do. Keep every plausible signal and decide later.

Read what a notice actually says

A title match is a weak signal: roughly one in ten is what you were looking for. What the notice says is in its document, and an Extract step reads it.

For Czech building notices there is a recipe written for exactly these documents: set Recipe to cz_building_permit and Document ref to {{ notice.document_ref }}. It returns the project’s name, whether it is residential, how many dwellings and parking spaces, who applied, where the site is (cadastral area and parcel numbers), and the dates that matter — when it was decided, when it was applied for, and how long the permit gives to start building.

Every value comes back with a confidence and the words it came from, so you can see why a fact is on a record.

Two things worth knowing about how it reads:

• A permit names several organisations, and they are not interchangeable. The office that issued it prints its own registration number in the letterhead, and the applicant is often followed immediately by the firm representing them. The recipe asks for all three separately, which is what keeps the authority out of the “who is the developer” field.
• A collection notice legitimately reads as almost empty. That is the right answer for that document, not a failure.

Nothing else in the recipe is required, so a sparse notice is written as-is with blank cells. Only a document whose kind cannot be read asks for a person — branch on needs_review to route those.

A document is only read once

Reading a document with a recipe costs a real model call — a 31-page permit is around 35,000 tokens of input. The answer is kept, keyed on the document’s contents and the recipe’s version, so re-running a flow over documents it has already read costs nothing and returns the same values with reused set.

Change the recipe and the next read under it reads everything again: a changed recipe is a new version by itself, with no number to bump, and each read says which version made it. Changing only what the recipe calls the document keeps the reads you already have. Turn on Read it again even if it was read before for a single fresh read of an unchanged recipe.

The documents themselves are kept too. A board serves a notice for a couple of weeks and then stops, so anything not stored the first time is gone for good — reprocessing later never has to go back to the board.

Find out who is behind it

A development is usually built by a company created for that one building. The company you actually want to talk to is the group above it.

Add a Look up a business step with Registration number set to what the extraction read. It returns the registered name, legal form, seat and VAT id, and — with Follow who owns it on — walks up the ownership chain and gives you owner_name, ultimate_owner_name, and chain_ended_because.

Branch on is_business before treating anything as a company you could sell to. It is derived from the registered legal form, so a municipality, a residents’ association, or a form nobody recognises all fail it. A list of authority names to exclude does not work: there is always another authority.

The address is the registered seat

address is where the company is registered — frequently an accountant’s office in a different district. It is never where the project is. The project’s location is the cadastral area and parcel numbers in its own documents, which name an exact polygon.

chain_ended_because is worth surfacing rather than hiding. “The register discloses no owner above this one” is a real answer — a joint stock company only has to name a shareholder when it has exactly one — and it is different from having failed to look.

Put it together

A weekly flow that keeps a watch list current:

1. Schedule — once a week is plenty; most boards serve a notice for two to four weeks.
2. Read official noticeboards — your terms, a ten-day window.
3. For each notice:
   • Extract the document with cz_building_permit.
   • Look up a business on the applicant’s registration number.
   • Create record into your table, upserting on source_key.
4. After the loop — a notification with the counts, and the contents of failures if there are any.

Scoring and classification belong on the table, not in the flow: a computed column can turn a dwelling count and a stage into a priority, and stays editable by whoever owns the work rather than by whoever edits flows.