Building Permit Assessment (Byggesak)

lokaliQ is a document retrieval system with an LLM on top. You upload documents, it indexes them, and when someone asks a question it finds the relevant passages and generates an answer with citations. That's the baseline — every RAG system does this.

What you can do with lokaliQ that matters for this case study:

1. Organize your documents into domains so different sources don't drown each other out
2. Write prompts that shape the output into something you can actually use

This guide walks through setting up a building permit assessment workflow. The same pattern applies to other areas — land use planning, environmental assessments, procurement — swap the documents and the prompt, the process is the same.

The documents

For building permit assessment, the relevant sources can be:

Create a project, create these domains, upload the documents to each one, and ingest.

Why domains instead of one big heap of documents? When everything is in one collection, the system retrieves the 20 most similar chunks regardless of source. A well-written DiBK guidance document might score higher than the actual law it's interpreting — and push the legal text out of the context window entirely. With the use of domains, lokaliQ retrieves and reranks per domain, then combines. Every source gets representation.

That's the structural advantage. It's not magic — it's just smarter retrieval.

Where You Put In the Work - Prompting

The documents provides the system with knowledge. The prompt tells it what to do with that knowledge. This is where your effort has the most impact.

Making the output useful

A generic RAG prompt produces generic answers. A case worker might not need a summary — they need text that can be extracted and ready to be pasted into a formal decision. The difference is entirely in how you structure the prompt.

Generic prompt, generic output:

"The construction of a 14 m² shed may be exempt from permit requirements under PBL §20-5, provided certain conditions are met regarding distance to boundary and local plan provisions..."

That's correct, but rather useless.

More specific prompt equals more usable output

If you tell the LLM what format to produce, it will for the most part comply. For example, adding this to your prompt:

Structure your response as follows:

1. Conclusion — state whether the project requires an application, and under which provision (§20-3, §20-4, or exempt under §20-5)
2. Legal basis — list the specific provisions that apply, with section numbers
3. Conditions — if exempt, list the conditions that must be met
4. Missing information — if the assessment depends on facts not provided, list them

Write in a formal tone suitable for inclusion in a municipal decision document (vedtak). Use Norwegian bokmål.

Now the output looks like something a case worker can actually work with.

The take-away is that when you provide the LLM with examples of correct behaviour it's more likely to follow your instructions

Telling the system what it doesn't know

Just as important: tell the LLM to flag uncertainty. Case workers need to know when the system doesn't have enough information to give a definitive answer.

If the answer depends on information not provided in the question — such as distance to property boundary, building height, zoning category, or whether the property is subject to a regulation plan — state explicitly what information is needed before a conclusion can be reached.

This prevents the system from guessing, which is the worst thing it can do in a regulatory context.

Iterating

Your first prompt will not be your last one. Use it for some time, and you will start to notice where the LLM falls through. These are the areas where you need to adjust and enforce rules to get the LLM on track.

Common adjustments:

• The system cites the law but ignores local plan restrictions → add a rule: "Always check whether local plan provisions (kommuneplanbestemmelser) impose additional restrictions beyond what PBL §20-5 allows"
• The output is too long → add: "Be concise. The conclusion should be one sentence. The legal basis should be a bulleted list."
• The system mixes Norwegian and English → add: "Always respond in Norwegian bokmål"

The prompt is a living document. Treat it like one.

What This Doesn't Do

lokaliQ retrieves documents and generates text. It does not:

• Make legal decisions
• Guarantee correctness
• Replace professional judgment
• Know about your specific case unless you tell it in the question

The output is a draft. The case worker reads it, verifies the references, and takes responsibility for the decision. That workflow doesn't change.