How Popety.io Orchestrates LLMs on Astro to Turn Swiss Building Rules into Instant Answers

The Customer

Popety.io is a Swiss PropTech company that develops a SaaS platform for real estate prospecting and property analysis. The platform brings together Switzerland's fragmented real estate data into a single, searchable map covering the entire country across its German-, French-, Italian- and Romansh- speaking regions. It enables real estate agents, brokers, developers, banks, and investment funds to answer in minutes questions that once required hours of research.

To power these insights, Popety aggregates official data from every level of the Swiss public administration, from federal to cantonal (state) and communal (municipal) authorities. The platform combines structured and unstructured datasets from land registries to zoning regulations.

Florian Richter, who joined three and a half years ago, is the lead data engineer responsible for that platform, and he describes the scale of the problem Popety solves plainly.

The Challenge

Popety has run its data platform on Astro, Astronomer's managed Apache Airflow service, on Google Cloud since 2021. From the start, Astro orchestrated the conventional engineering behind the map: hundreds of pipelines that scrape and normalize data from government geo-services and public registries, process property transactions and construction permits, and keep listings, parcels, and buildings current in PostgreSQL and Elasticsearch across the whole country. This was standard, large-scale data engineering, and Airflow handled it reliably.

One question, though, never fit that automated picture: what can you legally build on a given parcel? Existing buildings are well documented in public records; development rights are not. The answer is buried in thousands of building regulations, maintained independently by Switzerland's 26 cantons and 2,000-plus communes and published as dense legal documents never meant to be queried, many of them scanned PDFs, some dating to the 1970s, written across Switzerland's four official languages, with terminology that shifts from one canton to the next. Inside them sits the building data Popety's customers care about most: the zoning indices that decide what can go on a plot, including maximum building height, minimum distance to a boundary, permitted floors, and how much of the land can be covered. Turning that fragmented mass of rules into structured, reliable data is one of Popety's core AI challenges, and the focus of this story.

Grounded extraction in action. Here Popety pulls a single index, the maximum building height for the "zone périphérique A" of Blonay, and links it straight back to the exact passage in the source regulation, so a customer can see where the number came from.

Getting those indices out of the documents was, for years, painstaking and manual:

• Hand extraction. A person read each regulation and typed the values in by hand. It was slow, impossible to keep current, and hard to scale across 26 cantons.
• Brittle text parsing. For transactions and permits, the team relied on regular expressions, which are hand-written pattern-matching rules, and they broke constantly on real-world text.
• Unreliable source documents. OCR on decades-old PDFs produced unpredictable results, especially where the key figures sat inside tables.

The result was a coverage ceiling. Expanding the map to a new canton or a new document type meant more manual reading, and the regional variation in language meant no single rule worked everywhere. As Popety data scientist Raed Ben Mustapha puts it, "Extracting that building data used to mean a person sitting with each regulation, reading it page by page, and typing the numbers in by hand. Across 2,000 municipalities, that simply does not scale."

The Solution

The breakthrough started as a master's thesis by Raed Ben Mustapha, now a data scientist at Popety. The question was whether a retrieval-augmented generation (RAG) pipeline could read the regulations automatically. Because the rest of Popety's platform already ran on Astro, the team built the new AI workload exactly where everything else lived, as Airflow DAGs, with no separate system to stand up or maintain. The same scheduling, retries, and logging the team relied on for its data pipelines now backed its LLM workloads too.

"Our whole platform already ran on Astro, so we built the AI pipeline right where our data already lived. We didn't have to bolt on a separate system to run the models. The scheduling, the retries, the logs we already trusted now run our LLM work too." Raed Ben Mustapha Data Scientist, Popety.io

Popety's per-canton RAG pipeline. Astro orchestrates every step, from OCR to structured extraction, and feeds the results straight into the product.

The land-use extraction pipeline runs as a set of per-canton DAGs that mirror the structure of the problem itself. Astro is the orchestrator that holds it together: Airflow runs each DAG, executes every step as a task, sequences the dependencies, retries what fails, and captures the logs, while the specialist libraries and models do the work inside those tasks. The five stages are not one giant DAG; they run as several smaller DAGs that trigger one another, so each stage can be rerun, retried, or kicked off on its own.

1. Ingest and OCR. A task pulls regulation documents from each region's official sources, then another runs OCR with Mistral, a vision-and-language model, to turn scanned PDFs into machine-readable text.
2. Chunk and tag. LangChain splits the text into passages, and each is tagged with metadata: document title, article path, page, and zone. Building the title hierarchy takes an LLM call followed by a post-processing step.
3. Index to Elasticsearch. The passages, along with vector embeddings that capture their meaning, are loaded into Elasticsearch, which becomes the searchable store the pipeline queries.
4. Hybrid retrieval. For a given city and zone, Elasticsearch returns the most relevant passages by combining two methods at once: keyword (lexical) matching and semantic (vector) matching. That blend is what makes it "hybrid," and it catches both exact terms and close paraphrases. After an initial metadata filter, the pipeline surfaces roughly 15 candidate passages, with extra table-aware searches where figures sit inside tables. LangChain wires these queries together.
5. Extract with an LLM. The candidate passages and a canton-specific prompt go to OpenAI, called via LangChain. The model returns the indices as validated structured output, including the value, its source page, and the article path, so every number is traceable to its document. Results are written to PostgreSQL and indexed back into Elasticsearch.

The same approach now powers a parallel production pipeline for construction permits and property transactions, where LLM extraction replaced the old pattern-matching rules and turns a block of text into a clean record: buyer, seller, parcel, and geometry.

The Results

Work that once meant a person reading regulations line by line is now an automated pipeline running across the country. The change shows up both in what customers see and in the scale Popety can operate at:

• Nationwide coverage. Dedicated extraction pipelines built canton by canton across Switzerland, applied across more than 2,000 municipalities.
• Real scale on Astro. More than 650 production DAGs, many built from operators the team wrote themselves, executing over 220,000 tasks a month. Around 130 of those make up the document-extraction system, repeated across cantons and document types (regulations, construction permits, property transactions, and official notices). About 50 are dedicated LLM pipelines, together running over 7,000 LLM tasks a month, each calling OpenAI's Batch API asynchronously.
• Grounded answers in seconds. Customers instantly know what they can build on a parcel, with every result traceable back to the source document. Because the pipeline also extracts the land number or address from the raw text, each result is geo-located on the map, right where the customer is looking.
• Decades of manual work to a live pipeline. The productivity shift is hard to overstate. Extracting a single document by hand took two to three hours, and Popety's regulations span roughly 20,000 documents across 2,000-plus communes: one set of general rules per commune, plus around ten special-rule documents each. Doing that work by hand would run to more than 40,000 hours, the equivalent of over twenty person-years of reading, and in practice only the general documents were ever attempted. Because the rules keep changing, manual coverage could never stay current. The pipeline now processes the full corpus and keeps it up to date.

The payoff in the product. For a single 333 m² low-density residential parcel in Gibloux, Popety shows current versus authorized building coverage, floor-area ratio, height (8.50 m), permitted floors (2), and the 5 m distance limit, each extracted automatically from the communal regulation.

What's Next

Popety is extending the same approach — ingest, OCR, chunk, retrieve — and extract, to new kinds of documents: neighborhood development plans, market evaluations from pension funds, and alerts when a city changes its zoning. Each one means a new pipeline and region-by-region adaptation, and the team is also deepening its construction-permit and transaction coverage. The throughline is consistent: more of Switzerland's hard-to-reach property data, pulled out of PDFs and made searchable for customers.