Automated compliance checking of documents against rules (e.g. building permits)

Authorities and compliance teams spend much of their time checking whether a submission is complete and conforms to a rulebook: is every required document there, does the stated floor-area ratio respect the development plan, does the filing contain the mandatory disclosures? AI reads the submission, maps each rule to evidence, and returns a traceable list of findings. The decision stays with a human; the AI shortens the check and makes it consistent.

Problem & value

• Today: case workers read hundreds of pages of forms, plans and statements against building codes, local development plans or internal policies. Incomplete applications cycle back and forth; rules are applied with varying rigour; knowledge sits in a few experienced heads.
• AI value: automatic completeness checks, first-pass conformity findings with evidence, consistent application of the same rule version, drafts of deficiency letters.
• Evidence (vendor-reported, treat as indicative): Archistar's AI PreCheck (formerly eCheck) reports "up to a 55% reduction in permit review cycles"; Los Angeles County cites a 54% reduction in plan-processing time and Austin roughly 50% time savings on zoning review [3]. These come from the vendor's own page; no independent evaluation was found.
• Policy push: the Horizon Europe project ACCORD (2022–2025) built a semantic framework, a rule formalisation tool and compliance-checking micro-services for digital building permitting, demonstrated in five regulatory contexts (UK, Finland, Estonia, Germany, Spain) [1]. A July 2026 Bundestag inquiry treats automated code compliance checking as the next step after the digital "Einer-für-Alle" building application [2].

Variants

• Building permits (flagship): completeness check of the application package, then conformity checks of plans or BIM models against building code, development plan, fire-safety and accessibility rules.
• Building-control site inspection support: extracting information from digital building files to prepare inspections and draft reports (TUM / Landratsamt Ostallgäu pilot, April 2025–March 2026) [4].
• Other permits and public filings: environmental permits, event permits, subsidy applications (completeness and eligibility pre-check; the decision itself is AGENT-026).
• Corporate and regulatory filings: checking prospectuses, annual reports, ESG/CSRD disclosures, tender responses (DOC-015) or supplier documents against a checklist of mandatory content.
• Policy compliance inside companies: expense reports, HR documents, quality dossiers, technical documentation against internal policies or standards (see DOC-019, DOC-027 for label/certificate niches).
• Private use: applicants run a pre-check before submitting (e.g. a homeowner's building application).

How it works

1. submission (PDF set / forms / IFC model)
2. document classification & completeness (what is required for this procedure?)
3. parsing: OCR + layout, table and drawing-annotation extraction; IFC read via geometry/property API
4. rule base: rules as (a) deterministic code/queries (b) retrieved text clauses with version + jurisdiction
5. per-rule evaluation: numeric/geometric rule
6. deterministic check on extracted values or the BIM model interpretive rule
7. LLM with retrieved clause + evidence passages, cited verdict
8. finding = {rule id & version, verdict, evidence page/box, confidence, reason}
9. human review (case worker confirms, overrides or asks applicant)
10. report / deficiency letter, audit log, archive

• Two kinds of rules. Quantitative rules (distances, areas, heights) should be formalised and executed deterministically, either on the BIM model with IDS/model-checker rules or in a rules engine (e.g. Rego/OPA [8]). Interpretive rules ("adequate", "fits the local character") are handled by an LLM that must quote the clause and the evidence, and that outputs "unclear" rather than guessing.
• Rule formalisation is the real bottleneck: ACCORD's rule formalisation tool and ruleset database address exactly this [1]. The buildingSMART Information Delivery Specification (IDS) is an XML standard to state IFC-based information requirements machine-readably [6].
• Human-in-the-loop: every negative finding and every "unclear" goes to a person; positive findings are sampled. Decisions (approval, refusal) are never issued by the system.

Data preparation

Two data sets must be prepared: the submissions and the rulebook. Submissions arrive as PDF plans, forms, calculations and sometimes IFC models, via portals, e-mail or paper; they live in the DMS, case system or file shares. The rulebook is scattered across laws, development plans, standards, internal policies and the heads of experienced reviewers. Typical gaps: rules in prose with exceptions, several valid versions by date, scanned plans, inconsistent naming of attachments, and no record of past decisions in machine-readable form.

Steps: (1) convert the rulebook into atomic, numbered rules with source citation and validity date, see PREP-014 and PREP-012; (2) define the completeness checklist per case type, see PREP-019; (3) parse submissions with a layout parser, see DOC-014; (4) harvest past cases with outcomes as labels, see PREP-020; (5) let senior reviewers build a test set, see PREP-018; (6) pseudonymise applicant data in test material, see PREP-022. Tools: Docling or an OCR API, a rule table, a vector store. Expect 40-50 % of effort in rule structuring and test sets.

Implementation paths

Which path for whom

• SMB: Path B — own rulebooks and checklists must be integrated, and no mature SMB product fits; start with a narrow ruleset on EU-hosted APIs.
• Enterprise: Path B — rule engines, workflow and audit log integrate with existing compliance systems; Path C once volume or sensitivity grows.
• Public: Path C — authorities handle citizen data and decisions with legal effect, so sovereign hosting, procurement rules and full audit control weigh heavily; sovereign cloud (Path B) is the interim option.
• Developer: Path B — build rule-to-evidence pipelines on API models and move sensitive parts to Path C later.

Path A — Buy (off-the-shelf)

• BIM rule checking: Solibri (Helsinki, Nemetschek; rule-based BIM quality assurance with tiers incl. an air-gapped "Security+" edition and an AI Assistant) [5]. EU-based, widely used by designers; used on the applicant/designer side more than as authority workflow.
• Permit plan review: Archistar AI PreCheck (Australia/Canada/US; PDF, CAD or BIM upload, pass/fail reports) [3]; German BIM.permit and Baumind (BIM-model checks against building rules; vendor claims not verified here).
• Permit workflow suites in German administrations (digital Bauantrag via EfA service, municipal specialist software) are adding completeness checks; ask your software supplier.
• Corporate use: GRC and regulatory-intelligence suites with document checklists; contract/clause tools such as DOC-009 vendors for policy checks.
• Choose A when: the domain is covered by a product with your jurisdiction's rules already encoded. Rules in German state building codes (16 Landesbauordnungen) differ, so check coverage per state.

Path B — Build on cloud APIs (recommended default for pilots)

• Parsing: Azure AI Document Intelligence (layout, EU regions), Mistral OCR / document AI (EU provider), Google Document AI; or a VLM that reads plan sheets directly.
• Reasoning: a frontier reasoning/long-context model (Claude, Gemini, GPT, Mistral Large) via EU-region endpoints; schema-constrained findings output; retrieval over rulebooks (embeddings + reranker + vector DB).
• Orchestration: an agent that plans which rules apply, calls deterministic check tools (geometry, arithmetic, lookup) and the LLM only for interpretive rules; workflow engine (n8n, Camunda, Power Automate).
• Choose B when: you need custom rulebooks and quick iteration, and data may legally leave to an EU cloud. Public authorities often need a data processing agreement and approved hosting first.

Path C — Self-host (open source)

• Parsing: Docling (MIT, LF AI & Data; PDF layout, tables, local/air-gapped use) [7], PaddleOCR-VL, MinerU.
• BIM: IfcOpenShell (LGPL; includes ifctester for IDS-based model auditing) [6]; Bonsai (Blender) for viewing.
• Reasoning: open-weight 30–120B models (e.g. Qwen3, gpt-oss, Mistral Medium/Large-class open weights, Llama family) via vLLM; embeddings + reranker (BGE, Qwen3-Embedding) with pgvector/Qdrant; rules as code or Rego [8].
• Hardware: HW3 (one 48–141 GB GPU) for a ~70–120B model with long context plus a VLM; HW2 suffices for completeness checking and smaller models. Why C: municipalities and ministries with sovereignty requirements. Ops effort is substantial because the rule base needs permanent maintenance.

Path D — Custom training

Worth it mainly for (1) a fine-tuned small VLM/classifier for document-type and plan-sheet classification using thousands of labelled historical applications, (2) training an extractor for symbols and dimension annotations in plans, or (3) a retrieval re-ranker on your own rulebook. Past case files with known outcomes are the data source — but see GDPR below. Do not train a model to predict approval decisions from past files; that raises bias and legal issues (see risks).

State of the art (2026)

• Hybrid neuro-symbolic is the consensus: formalise rules where possible (IDS, rule engines, ontologies as in ACCORD [1]) and use LLMs for parsing, retrieval, interpretation of vague clauses and drafting. Pure "ask the LLM whether the plan complies" is not reliable enough for legal checks.
• Regulators' own caution: a 2025 expert-interview study with regulators reports ambiguous terminology, inconsistent rules and the question of how much human oversight to keep as main hurdles for automated compliance checking (summary via EC3 [9]). Digital rulebooks are the prerequisite, not the model.
• BIM-based checking is the mature, deterministic path where applicants deliver IFC models; 2D PDF plans still require vision parsing of drawings, which is error-prone for dimensions, scales and symbols (see DOC-013).
• Limits and failure modes: hallucinated rule citations; outdated or wrong jurisdiction/version of a rule; misread dimensions; missing evidence interpreted as compliance; overconfidence on vague clauses; automation bias in reviewers. Mitigate with versioned rule retrieval, mandatory evidence pointers, "unclear" as a valid outcome, regression test sets of real past cases, and reviewer sampling.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-reasoning + retrieval): DOC-009 contract clause extraction, DOC-010 review and redlining, DOC-014 PDF-to-structured parsing for RAG, DOC-015 tender requirements extraction, DOC-013 technical drawing understanding, DOC-027 label proofing. One HW3 server with a VLM, an LLM and a vector store can serve all of them.
• Upstream: DOC-003 (form and application processing) for intake; DOC-008 classification of submitted files.
• Downstream: AGENT-026 (caseworker agent drafting decisions and requesting missing documents) consumes the findings; CONV-style citizen assistants can explain deficiency letters; LANG-024 does the analogous check for marketing claims.
• Shared building blocks: versioned rule repository (legal text + formalised rules), evidence-linking viewer, audit log, workflow engine.

Effort, cost & KPIs

• Path A: weeks to months (rule coverage and integration into the permit system dominate).
• Path B: 3–6 months for one procedure type; main cost is rule formalisation and test-set building, not tokens.
• Path C: 6–12 months including infrastructure; one HW3 server plus maintenance staff.
• Path D: only after the pipeline runs; adds annotation effort.
• KPIs: completeness-check precision/recall against expert verdicts; share of findings accepted by reviewers; review time per case; number of correction cycles per application; first-submission completeness rate; rule-coverage percentage; disagreement rate across reviewers before/after.

People & change

Involve early: management or authority leadership, the department lead (process owner), case workers and senior reviewers as rule authors and testers, legal for liability and administrative-law questions, IT and the DPO. Applicants or customers should get a transparent notice that automated pre-checks are used.

Works council / staff council: depends. Rule checking alone does not monitor staff, but case-system logs and review statistics do, so §87(1) no. 6 BetrVG (in authorities the Personalrat under BPersVG/state law) likely applies; §90(1) no. 3 applies in any case and an expert under §80(3) may be engaged. Data protection: applicant data is personal; AVV, legal basis and DPO are needed; a DPIA is likely for systematic evaluation, see GUIDE-005. AI Act: classification depends on the use, see GUIDE-014.

AI literacy: support reviewers with training on reading findings and spotting unreliable ones. Pilot: one case type in parallel mode, with measured agreement. Concerns: loss of discretion and liability - the AI only proposes; the human decides, and overrides are logged as feedback. See GUIDE-004 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act (depends): Annex III does not list building permits as such. Point 5(a) covers systems evaluating eligibility for essential public assistance benefits and services [10], so a benefit/subsidy eligibility check is high-risk, while a pure completeness or technical conformity pre-check supporting a human reviewer is typically not high-risk (Art. 6(3) derogation for narrow procedural or preparatory tasks, which the provider must document). Classification needs case-by-case legal review; this is not legal advice. In all cases Art. 4 AI literacy applies; if high-risk, Arts. 9–15 (risk management, data governance, logging, human oversight) apply. Not a prohibited practice in its typical form.
• Administrative law (Germany): §35a VwVfG allows fully automated administrative acts only where no discretion or margin of assessment exists; keep decisions with the caseworker, with reasons given (§39 VwVfG). Other EU states have equivalent rules.
• GDPR: applications contain personal data of applicants, neighbours and planners; need a legal basis (public task), data processing agreement, and no reuse of case files for training without a basis. Art. 22 GDPR restricts solely automated decisions with legal effect.
• Liability and trust: if applicants rely on a private pre-check tool, state clearly that only the authority's decision counts. Version and publish the rules applied; keep an audit log of tool output vs. final decision.
• Other sector rules: DORA/MiFID/CSRD etc. for financial or sustainability filings; the rulebook defines duties, the AI tool does not.
• Mitigations: human decision, rule versioning, evidence pointers, test sets, bias review across applicant types.

Getting started

1. Pick one narrow procedure (e.g. completeness check for a single permit type) and write down the rule checklist.
2. Collect 100–200 historical anonymised submissions with the reviewers' findings as a ground-truth test set.
3. Prototype with Path B or the Docling stack: parse, retrieve the rule, output finding + evidence + "unclear".
4. Formalise the numeric rules as code (or IDS if BIM models are delivered) and keep the LLM for interpretation.
5. Run in shadow mode next to case workers, measure agreement, do the AI Act classification and a DPIA, then go live with human sign-off.

Sources

1. ACCORD (Horizon Europe) — Automated Compliance Checking and building permitting — https://accordproject.eu/
2. Deutscher Bundestag, Drucksache 21/6854 (Kleine Anfrage, July 2026) — https://dserver.bundestag.de/btd/21/068/2106854.pdf
3. Archistar — AI PreCheck (formerly eCheck), vendor page with reported results — https://www.archistar.ai/
4. TUM CCBE — AI-based support for on-site inspections in building permit processes — https://www.cee.ed.tum.de/ccbe/research/research-groups/information-management/ai-based-support-for-on-site-inspections-in-building-permit-process
5. Solibri — BIM quality assurance — https://www.solibri.com/
6. buildingSMART Information Delivery Specification (IDS) repository — https://github.com/buildingSMART/IDS ; IfcOpenShell / ifctester — https://github.com/IfcOpenShell/IfcOpenShell
7. Docling project — https://github.com/docling-project/docling
8. Open Policy Agent — Rego policy language — https://www.openpolicyagent.org/docs/latest/policy-language/
9. EC3 — The Challenge of Automated Compliance Checking: a Regulatory View — https://ec-3.org/?p=10393
10. EU AI Act Annex III (artificialintelligenceact.eu) — https://artificialintelligenceact.eu/annex/3/ ; Regulation (EU) 2024/1689 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj