arXiv CSopen access

Reinforcement learning to improve large language model-based automated code compliance systems

Reinforcement learning to improve large language model-based automated code compliance systems Jack Wei Lun Shi1

Minghao Dang1,2

Wawan Solihin1,3

Leong Hien Poh1

Justin K.W. Yeoh1 1

National University of Singapore

arXiv:2606.22402v1 [cs.SE] 21 Jun 2026

3

2

Harbin Institute of Technology

NovaCITYNETS

Abstract Large language model (LLM)-based approaches for automated code compliance (ACC) of building regulations are prone to generating incorrect and hallucinated computer-processable rules. This paper introduces P4IR, a two-stage framework that uses supervised fine-tuning (SFT) to instill domain knowledge in an LLM, followed by Group Relative Policy Optimization (GRPO) to improve the accuracy of the generated intermediate representations in the form of high-level code skeletons. The framework achieved reductions of up to 23.8% and 38.6% in tree edit distance and token-level Levenshtein distance respectively, relative to the SFT baselines. Comparative analysis demonstrates that this approach in a zero-shot setting outperforms leading LLMs in both code structure and semantics, specifically Claude Opus and Sonnet 4.5, GPT-5.2, Qwen-3-Max, and GLM-4.7, evaluated via fewshot prompting. Additionally, the GRPO stage produced a small yet statistically significant reduction in false positives. By combining SFT with GRPO to optimize directly for domain-specific objectives, this approach offers a path toward more accurate and reliable LLM-based ACC systems. Keywords: Automated Code Compliance; Building Regulations; Large Language Model; Reinforcement Learning; Intermediate Representations

1

Introduction

Compliance with building regulations is crucial for ensuring the safety, functionality, and longevity of structures, while directly influencing project timelines and costs. Singapore’s Building and Construction Authority forecasts construction demand to reach S$53 billion in 2025, representing an 11.7% increase over pre-pandemic levels, and to remain robust through 2029, averaging between S$39 billion and S$46 billion annually [1]. In this dynamic environment, automated code compliance (ACC) systems can drastically reduce design review times, improve accuracy, and enhance overall project efficiency within the Architecture, Engineering, Construction, and Operations (AECO) industry. Despite advancements in ACC systems, the complexity of translating building regulatory clauses into computer-processable formats remains a significant challenge [2]. Conventional approaches often rely on time-consuming and hard-coded rule-based methods, highlighting the need for more flexible and efficient solutions. To manage this complexity, building regulations are often first translated into Intermediate Representations (IRs), which are structured representations that can better support the generation of computer-processable formats. In the ACC domain, such representations have been used to capture hierarchical information and semantic rules [3, 4]. With the recent advances in artificial intelligence (AI), large language models (LLMs) have emerged as a promising approach to generate structured and coherent representations from unstructured regulatory texts. Early work by Zhang [5] explored ChatGPT for converting natural-language building code requirements into executable Python logic, demonstrating that the model generates regulatory-compliant code with high efficiency and showcasing its potential to accelerate ACC implementation. Fuchs et al. [6] showed that GPT-3.5, in a few-shot setting with as few as five

exemplars and carefully crafted system prompts, can translate building regulations into compact IRs using LegalRuleML, achieving F1-scores of approximately 70%. These results were further improved by representative exemplar sampling and self-consistency strategies. Despite these promising results, LLMs can be prone to hallucination [7] (i.e., generating outputs that are statistically plausible but flawed). Supervised fine-tuning (SFT) can inadvertently amplify this phenomenon by forcing the model to fabricate responses when instructions exceed its knowledge boundaries, as it trains the model to always provide an answer rather than express uncertainty [8]. Consequently, the LLM outputs, such as the IRs, are not always reliable for rule interpretation [9]. Even with few-shot prompting, recent state-of-the-art (SOTA) models struggle to generate IRs that match the ground truth in both structure and semantics. To overcome these limitations, an approach is needed that directly optimizes the output structure. Reinforcement learning (RL) offers an alternative, as it optimizes explicit reward functions and can therefore be aligned with domain-specific objectives, which has been shown to reduce hallucinations in practice [10, 11]. Among various RL-based algorithms, Group Relative Policy Optimization (GRPO) reduces computational and memory requirements by eliminating the critic model while also stabilizing training [12]. Accordingly, the research objective is to improve the structure of IRs using RL. This paper proposes P4IR (Policy Optimization for Intermediate Representations), a two-stage GRPO-based ACC framework. The first stage employs SFT to equip a pre-trained LLM with domain knowledge to establish semantic accuracy [13]. The second stage then applies GRPO to improve the structure of generated IRs (hereafter “code skeletons”) and reduce hallucinations. This reinforcement stage is guided by an accuracy reward function based on Jaccard similarity [14], a metric measuring the alignment between the generated and reference code skeletons by comparing their classes, functions, and parameters. Thereafter, a systematic evaluation investigates the influence of initial SFT maturity on subsequent GRPO performance. The paper also benchmarks P4IR against other LLMs, providing empirical evidence that the two-stage framework yields better results than larger general-purpose models evaluated with few-shot prompting.

2

Literature Review

ACC refers to the evaluation of a Building Information Model (BIM) against a computable representation of building regulations. The overall structure of an ACC system generally consists of four stages [15]: (1) rule interpretation, where code compliance experts will discuss with computer programmers regarding building rules to ensure consistency, (2) building model preparation, to create test models in BIM that encompasses various passing and failing scenarios of the rules implemented, (3) rule execution stage, to ensure the prepared BIM are equipped with the correct properties and objects for complete checking task, and lastly, (4) reporting of checking results, where compliance and non-compliance cases for all instances relating to the rules will be shown. Within this ACC system, the primary challenge lies in the initial rule interpretation. Over the past decades, significant efforts have been dedicated to improving ACC systems. These include using semantic decomposition methods to convert textual regulations into rule execution languages without requiring programming expertise [16], establishing ontology-based methods [17] and domain-specific languages [18] to formalize regulatory knowledge within BIM workflows, and adopting visual programming languages to generate transparent process diagrams that allow rule experts to build and interpret compliance logic visually [19]. However, these conventional methods share limitations. They struggle with the inherent ambiguity and implicit knowledge within regulatory texts, demanding manual effort to interpret and translate rules into computer-processable formats. Furthermore, many of these systems are characterized by hard-coded implementations that lack the flexibility to adapt to evolving regulations or to generalize effectively across diverse and complex rule sets. 2.1

Natural Language Processing-Based Approaches in ACC

To overcome these challenges, research has moved toward harnessing natural language processing (NLP) methods to support various ACC processes. These NLP applications can be broadly classified into five interconnected areas: (1) information extraction of structured requirements from textual 2

regulations, (2) formalizing these requirements into computer-processable rules, (3) constructing knowledge representations of building regulations, (4) executing compliance checks against BIM, and (5) creating question-answering (QA) support systems. These classifications are not mutually exclusive, and many research initiatives adopt a hybrid approach, integrating techniques from several of these categories to create more comprehensive ACC solutions. In the area of information extraction, Zhang and El-Gohary [20] presented a semantic rule-based NLP method that automatically extracts regulatory requirements from construction codes using pattern matching and ontological semantics. Their approach achieved a precision and recall of 0.969 and 0.944 respectively when tested in extracting of quantitative requirements from the 2009 International Building Code (IBC). Song et al. [21] introduced a deep learning-based NLP framework for extracting predicate argument structures from building design rule sentences and converting them into machine-readable representations for BIM-enabled compliance verification. Once this information is extracted, the next step is to convert the fragments into programmatic rules, a task known as semantic parsing. For example, Guo et al. [22] transformed the extracted terms and relations into SPARQL using term matching and semantic similarity analysis. Parallel to these efforts in parsing, other work has focused on constructing comprehensive knowledge representations. For example, Zheng et al. [23] proposed a knowledge-informed framework that uses NLP to construct a domain ontology of building concepts, enrich BIM with semantic metadata, and align regulatory text to ontology entities. Their approach enabled the automatic generation of SPARQL queries for rule interpretation and compliance checking, achieving 90.1% accuracy in semantic alignment and a fivefold increase in interpretation speed. Similarly, Peng and Liu [24] presented an NLP-driven approach that preprocesses building regulations using the NLPIR Chinese word separation system and an attention-based conditional random fields (CRF) model to extract and classify domain entities, attributes, and their relationships. They constructed a semantic knowledge graph integrated with BIM elements to support downstream automated compliance checking, and validated the system on four engineering projects with a review accuracy exceeding 96%. Integrating these methods, ontology-based approaches have also been used for ACC by formalizing structural fire safety requirements into a ontology that integrates diverse regulatory texts and expert insights to enable automatic inference of compliance checks [17] and by deploying an ontology-informed information extraction framework to convert building energy conservation codes into machinereadable compliance rules [25]. For the purposes of executing compliance checks, Zhang and El-Gohary [26] developed SNACC, a unified ACC system that leverages semantic NLP to automatically extract and transform regulatory requirements into logic rules, aligns these with BIM-derived logic facts, and applies logic reasoning to perform fully automated compliance verification. Their system achieved 98.7% recall and 87.6% precision in non-compliance detection regarding Chapter 19 of the 2009 IBC. Wu et al. [27] extended SNACC by introducing the I-SNACC framework, which combines invariant signature-based fact extraction with logic reasoning, and adds modules for semi-automated rule expansion, activation condition generation, and interactive model validation to further automate building code compliance checks with minimal user input. Lastly, NLP has also been used to create QA systems for efficient information retrieval of building regulatory information and from BIM. For example, Wang et al. [28] presented a QA system that achieved an accuracy score of 81.9% using NLP for information extraction directly from BIM and IFC models, allowing users to ask questions and receive answers in natural language. 2.2

Transformer- and LLM-Based Approaches in ACC

With the advent of transformer-based LLMs, ACC research has begun to look beyond traditional NLP approaches for state-of-the-art methods. Transformer-based approaches are also implemented across the previously mentioned five areas. Respectively, Okonkwo et al. [29] evaluated the performance of word embeddings and transformer-based models (e.g., Bidirectional Encoder Representations from Transformers (BERT) and Sentence BERT) for automated information extraction of semantic regularities from unstructured British building regulations, achieving up to 80% word-level and perfect sentence-level accuracy. Additionally, Zheng et al. [30] developed a domain-specific BERT model to classify the machine interpretability of building regulatory clauses, filtering out non-computable text to enhance rule interpretation. Fuchs et al. [4] leveraged transformer-based semantic parsers augmented with structured intermediate formats, showing that introducing reversible representations 3

and a hierarchical parsing step can cut training time by nearly 75% and boost F1-scores by up to 6.6%, while also offering an interpretable, human-in-the-loop translation process. For rule interpretation, Zheng et al. [2] presented LLM-FuncMapper, which builds a library of 66 atomic functions for low and high order logic in building codes and uses an LLM to identify predefined functions. When employed with few-shot methods, LLM-FuncMapper retrieved 81.55% of the relevant atomic functions within its top five recommendations, surpassing that of a fine-tuned BERT model. To construct knowledge representations, Iranmanesh et al. [31] transformed IFC building data into graph-based formats by retrieving building object properties and their relations using an LLM-based graph retrieval-augmented generation technique. For LLM-based QA systems on building regulations, Xue et al. [32] paired a BM25-based sparse retriever with a reader built on fine-tuned and distilled LLMs, while Zhong et al. [33] used a fine-tuned BERT model to analyze retrieved regulatory passages. The outputs of the preceding studies, whether formal ontologies, queries, or programmatic functions, implicitly serve as IRs that bridge complex building regulations and the final, computer-processable rules. The quality of these IRs is therefore pivotal to the success of ACC systems. To automate their generation, recent studies have adopted advanced approaches such as SFT and LLM agents. For example, Fuchs et al. [9] employed SFT on T5 and BART models to translate regulations directly into a formal IR in LegalRuleML, while Ying et al. [34] leveraged an agentic workflow to dynamically create intermediate outputs (i.e., explicit reasoning traces and intermediate JSON files) for orchestrating the compliance check. However, Fuchs et al. [9] found that such outputs can be flawed, with underspecified logic statements and hallucinated object references. Consequently, while SFT can capture latent concepts in building regulations and instill domain-specific knowledge in the LLM [13], it does not by itself ensure that the generated IRs are well-structured. This motivates a post-SFT optimization stage that optimizes directly for output structure. 2.3

Reinforcement Fine-Tuning

Reinforcement fine-tuning (RFT) has become a popular strategy for aligning LLMs with desired behaviors. In particular, reinforcement learning from human feedback (RLHF) leverages humanlabeled preferences to refine LLM outputs. This process typically employs policy optimization algorithms such as Proximal Policy Optimization (PPO), which involves training a reward model to score outputs and then optimizing the LLM to maximize these scores, often with a KL divergence penalty for regularization [35]. However, these approaches depend on a learned reward model that is an imperfect proxy for human preferences, where over-optimization of this proxy can lead to degraded performance or reward hacking [36]. Moreover, PPO-based methods introduce a separate value network (i.e., a critic) of comparable size to the policy, incurring significant memory and computational overhead [12]. Training this critic can be unstable and complex, since the feedback signal is often sparse (i.e., usually only a final output reward) in the LLM setting, making it difficult to learn an accurate token-level value function. Shao et al. [12] proposed GRPO as an alternative RFT algorithm that addresses some of the aforementioned challenges. GRPO is a variant of PPO that foregoes the separate critic, instead estimating the baseline (i.e., the expected return) from the average reward of a group of outputs sampled for the same prompt, thereby eliminating the need for expensive value function approximation. GRPO also replaces the KL penalty in the reward function with a KL divergence term added directly to the loss for regularization against a reference policy. These simplifications yield more efficient and stable training without sacrificing performance. For example, applying GRPO-based RFT to a math-focused LLM yielded gains on mathematical reasoning tasks, which often require generating a coherent chain-of-thought to solve a problem. This increased accuracy on the GSM8K math benchmark from 82.9% to 88.2%, while reducing training resource requirements by removing the critic model [12]. Guo et al. [37] applied GRPO directly to a pre-trained DeepSeek-V3-Base model without any SFT, using rule-based rewards on the generated reasoning steps to elicit emergent reasoning behaviors such as self-reflection, and achieved competitive benchmark performance solely through RL. These findings suggest that GRPO and related strategies can match or even improve performance on complex tasks more efficiently than traditional RLHF. However, despite its success in STEM fields, the efficacy of GRPO for the domain-specific challenge of refining code skeletons for ACC has not yet been investigated. Additionally, when applied to the ACC domain, the effectiveness of GRPO for refining code skeletons is contingent on the knowledge 4

of the pre-trained LLMs. Since general-purpose models are not pre-trained on specialized ACC datasets, they lack the domain-specific knowledge required for nuanced rule interpretation, rendering a direct application of GRPO ineffective for this task. Therefore, an initial SFT stage is necessary to prime the LLM with the requisite knowledge. Yet, the interaction between this SFT stage and the subsequent GRPO stage has not been systematically examined in ACC. 2.4

Research Gaps and Objectives

General-purpose LLMs, despite rapid benchmark gains, may not necessarily transfer to highly specialized domains. Compact and domain-optimized models such as BioMistral [38], FinBERT [39], and DeepSeekMath [12] have rivaled or surpassed far larger general-purpose models in medicine, finance, and mathematics. This gap is more acute for ACC, whose rule-conversion datasets are largely proprietary and absent from the public corpora those models draw on, so relying on off-the-shelf SOTA models is insufficient and motivates a framework that explicitly aligns the model with the domain. Within this landscape, even after domain-specific fine-tuning, LLM-generated IRs can still contain underspecified logic and hallucinated outputs. Two research gaps remain in addressing this. First, while GRPO presents a promising solution for aligning LLMs with explicit objectives, its effectiveness has not been systematically investigated for refining IRs in the ACC domain. Second, since the domain-specific nature of ACC requires GRPO to build upon an LLM previously fine-tuned with specialized knowledge, the interplay between initial knowledge instillation via SFT and subsequent GRPO-based refinement remains unexplored. To address these gaps, this paper proposes a two-stage framework for improving the accuracy of generated IRs. In the first stage, a pre-trained LLM is fine-tuned on a domain-specific dataset, instilling the model with the foundational knowledge needed to generate an initial IR. In the second stage, GRPO is applied using a primary accuracy reward function, together with syntactic and length penalties that discourage malformed or trivially short outputs. This paper addresses the following research questions: (1) Can GRPO further improve the accuracy of generated IRs beyond what SFT achieves alone? (2) How does the degree of initial SFT maturity influence the effectiveness of the subsequent GRPO refinement stage? (3) How does P4IR, in a zero-shot setting, compare to existing SOTA LLMs evaluated via few-shot prompting? By answering these questions, this paper seeks to establish guideline on integrating SFT and GRPO to generate high-quality and structure-correct IRs for ACC.

3

Methodology

This paper introduces P4IR (Policy Optimization for Intermediate Representations), a framework for improving the accuracy of generated code skeletons for ACC. A code skeleton is the IR used in this paper, a high-level set of class and function definitions for converting building regulations into computer-processable rules, with low-level implementation details omitted, as shown in Fig. 1. These low-level details, such as the retrieval and referencing of BIM entities and identifiers (e.g., GUID), are extensive and rule-specific, making them challenging for LLMs to learn. Separating them from the structure lets rule experts and programmers add the implementation afterward, so a code skeleton generated by P4IR serves as a starting point that accelerates the development of complete compliance-checking scripts. 3.1

Dataset

The dataset used for training and evaluating P4IR is derived from a real-world rule interpretation project. To tailor it for the refinement task in this paper, a preprocessing pipeline was applied. The dataset contained pairs of regulatory text and their corresponding fully implemented Python scripts, as shown in Fig. 1a. The regulatory texts come from several Singapore codes of practice, such as Sewerage and Sanitary Works (SSW) and Surface Water Drainage (SWD) code of practice from Public Utility Board (PUB), and the Fire Code from Singapore Civil Defence Force (SCDF). Since this is a real-world project, the corresponding Python scripts are tested and fully executable, and are therefore treated as ground truth. From each script, only class and function definitions were extracted (i.e., their names, parameters, and hierarchical nesting as shown in Fig. 1). The low-level 5

implementation details within each function body were replaced with a stub (i.e., pass), as shown in Fig. 1b. Rule Description: SSW 3.2.1 Sewer Design Basis d. Minimum Sewer Size and Depth i - The minimum size of new sewers and the drain-line connection from the last IC shall be 200mm in diameter.

a) Real-world rule interpretation dataset

b) High-level code skeleton dataset

Only high-level code details remain Low-level code details are replaced with ‘pass’

Figure 1: Extracting the code skeleton from the rule interpretation dataset. This process transformed each full script into a code skeleton, which serves as the ground truth for the task. The abstraction focuses the model on learning the structure of the code skeleton rather than the details of its implementation, since generating fully implemented scripts would carry a higher risk of hallucinating plausible but incorrect low-level code. The resulting dataset comprises 732 unique regulation-code skeleton pairs. For training and evaluation, the data was partitioned into a training set of 664 samples (~90.7%) and a test set of 68 samples (~9.3%), ensuring that the test set contains regulations unseen during training. The dataset spans a range of complexity, so that the model is trained and evaluated on both simple and hierarchically complex regulations. Although 732 samples is modest in absolute terms, the dataset is, to the best of the authors’ knowledge, among the largest built from real-world executable rule interpretation code, which is substantially harder to obtain than the synthetic or manually annotated data used in most prior ACC work. 3.2

P4IR Framework

The framework uses Mistral 7B Instruct v0.3 as its base model, selected for its generative capabilities and open-source availability. The development of the framework involves a two-stage process. First, the base model undergoes SFT on a real-world dataset of Singapore building regulations and their corresponding code skeletons, developed in collaboration with industry stakeholders. Second, this fine-tuned model is further optimized using GRPO, where accuracy and formatting reward functions guide the model to reduce hallucinations and generate accurate code skeletons. The overall pipeline of the framework is depicted in Fig. 2. Stage 1: SFT for Knowledge Instillation

Stage 2: Group Relative Policy Optimization for Code Structure Refinement

𝜃'() = 𝜃' + 𝛼∇# 𝐽 𝜋#

Code Compliance Training Data

Building Regulatory Text +

Policy Model

SFT

Programmatic Flowchart

𝛽𝐷!" 𝜋# ∥ 𝜋$%&

Initial Policy Model

Reference Model

o3

𝑘 ∈ {syn, len, acc} r3

A3

πref

oG

rG

AG

Pre-trained LLM

πθinit

πθ

Completions

o1 o2

Rewards

Reward System

r1 ! 𝑟-

Figure 2: Overall pipeline of the proposed framework. 6

r2

Advantages

𝑟 − mean std

A1 A2

The first stage of the framework, shown on the left portion of Fig. 2, uses SFT to equip the base LLM with knowledge of the ACC domain. The objective of this stage is to train the model to map unstructured regulatory text directly to its corresponding code skeleton. The training dataset consists of pairs (q, y), where q is the input regulatory text (i.e., query) and y is the code skeleton. This fine-tuning optimizes the model’s parameters θ by maximizing the conditional likelihood of generating the target code skeleton sequence y given the input query q, achieved by minimizing the standard cross-entropy loss LSF T over the training dataset C:

LSFT = − E(q,y)∼C

|y| X

log πθ (yt | q, y<t )

(1)

t=1

where πθ is the token distribution of the LLM and yt is the t-th token of the target code skeleton. The resulting model from this stage, denoted as πθinit , possesses the specialized knowledge of ACC domain conventions to generate code skeletons and serves as the initial policy for the subsequent GRPO refinement stage. The framework omits explicit chain-of-thought and reasoning steps, unlike standard GRPO-based approaches. This design choice is motivated by both efficiency and efficacy. Including explicit reasoning tokens substantially increases the computational load and latency during training and inference. More importantly, recent research challenges the assumption that longer or more explicit reasoning universally improves performance, especially in specialized domains. For example, Lai et al. [40] found that in medical vision-language tasks, an RL-trained model prevented from generating reasoning tokens achieved better in-domain and cross-domain generalization than its reasoningenabled model. They hypothesize that under a significant domain shift, a model’s pre-trained reasoning patterns can become misaligned, leading to flawed or hallucinated steps that impair final performance. This aligns with the inverse scaling relationship shown by Gema et al. [41], where extending the reasoning of an LLM can degrade accuracy by causing it to fixate on irrelevant information or amplify flawed heuristics. Given that the objective is the accuracy of the code skeleton, forcing the LLM to generate reasoning tokens adds computational cost without necessarily improving the output. Therefore, the framework is predicated on the hypothesis that it is more effective to first instill knowledge via SFT and then use GRPO to directly refine the LLM to generate more accurate code skeletons. Next, the second stage of the framework, shown on the right portion of Fig. 2, uses GRPO to refine the initial SFT policy πθinit to improve the accuracy of its outputs. For a given regulatory text input q, the refinement process begins by sampling a group of G candidate code skeletons {o1 , o2 , o3 , . . . , oG } from the old policy πθold . Each output oi is evaluated against a set of rule-based reward functions (refer to Section 3.3) to obtain the rewards {r1 , r2 , r3 , . . . , rG }. By computing the mean and standard deviation of these rewards for normalization, GRPO determines the relative advantages {A1 , A2 , A3 , . . . , AG } (i.e., the relative quality of these outputs), defined as:

Ai =

ri − mean{r1 , . . . , rG } std{r1 , . . . , rG }

(2)

where Ai represents the relative quality of the i-th output compared to others in the sampled group. The model is then reinforced to favor outputs with a high advantage by updating the policy parameters θ through the optimization of the GRPO objective function [37]: "

G

πθ (oi | q) 1 X min Ai , G i=1 πθold (oi | q)   ! πθ (oi | q) clip , 1 − ϵ, 1 + ϵ Ai πθold (oi | q) #   − βKL DKL πθ (oi | q) πref (oi | q)

JGRPO (θ) = E

7

(3)

E denotes the expectation over the sampled queries q and the corresponding group of generated outputs {oi }. The policy ratio πθπθ (o(oi |q) compares the probability of generating an output oi under i |q) old the current policy πθ versus the old policy πθold , while ϵ and βKL are hyperparameters. The clipping function limits the policy ratio to a small interval [1 − ϵ, 1 + ϵ], preventing excessively large policy updates and ensuring training stability. The final term is a KL divergence penalty, scaled by βKL , that regularizes the policy, ensuring it does not deviate excessively from the knowledge of the reference SFT policy πref . By optimizing this objective, the framework uses its reward functions to iteratively guide the policy toward generating more accurate code skeletons. 3.3

Reward Design for Refining Code Skeletons

The reward system provides the optimization signal that guides the LLM’s policy toward generating more accurate code skeletons. As shown in Fig. 3, it comprises multiple reward functions that evaluate each generated skeleton, denoted yb, against its ground truth y. It combines a primary accuracy reward with two formatting penalties (hereafter also referred to as “rewards”) that together target both the structure and the syntactic validity of the output. c) Jaccard Accuracy Reward

a) Syntactic Format Reward class Functions: def GetConcreteFlowDepth(a, W): pass class Functions: def GetConcreteFlowDepth(a W); pass

Goal: To ensure that the generated code output is a syntactically valid Python flowchart

−1, if 𝑦+ ≠ ∅ and 𝑦+ ∉ ℒ'"$()# 𝑅!"#$%& 𝑦+ = . 0, otherwise

b) Short Output Format Reward class DistributionChamber: def GetManhole(self, retValJson): pass … # additional functions and complex logic … # (code continues)

Goal: To prevent reward hacking by penalizing overly short or trivial outputs.

Ç

class DistributionChamber: def GetManhole(self, retValJson): pass

Goal: To measure the structure similarity between the reference flowchart and the generated flowchart class Utility: def GetJsonObjFromQuery(query): pass

Set y contains 4 signatures: ("Utility", 0) ("Utility.GetJsonObjFromQuery", 1) ("Result", 0) ("Result.display_Message", 3)

class Result: def display_Message(self, resFlg, mainObj, msg): pass

Set ŷ contains 5 signatures: ("Utils", 0) ("Utils.GetJsonObjFromQuery", 2) ("Result", 0) ("Result.display_Message", 3) ("Result.log", 1)

ÇÇÇÇÇ

class Utility: def GetJsonObjFromQuery(query): pass class Result: def display_Message(self, resFlg, mainObj, msg): pass def log(message): pass

𝐽 Sig 𝑦 , Sig 𝑦0

Sig 𝑦 ∩ Sig 𝑦0 Sig 𝑦 ∪ Sig 𝑦0 2 = 7 =

Sig 𝑦 ∩ Sig 𝑦+ , if Sig 𝑦 ∪ Sig 𝑦+ ≠ ∅ 𝑅!$/01$0/+ 𝑦, 𝑦+ = B Sig 𝑦 ∪ Sig 𝑦+ 0, otherwise

−3, if 𝐿 𝑦 − 𝐿 𝑦+ > 𝜏 and 𝐿 𝑦+ < 𝐿-.# 𝑅*+#,$( 𝑦, 𝑦+ = . 0, otherwise

Figure 3: Reward system for the proposed framework. The accuracy reward, denoted Rstructure as shown in Fig. 3c, measures the alignment between the generated and reference code skeletons. It is formulated as the Jaccard similarity between the sets of hierarchical signatures extracted from the two code skeletons. Jaccard similarity was chosen as it is commonly used as an evaluation metric in ACC, for example, to assess alignment between human- and computer-identified sentence-type sets [42], inter-annotator predicate overlap in logic clauses [43], and compare LLM-generated Picat code against a human-verified gold standard [14]. A signature is a formal representation of a code component (i.e., a class or function denoted as Sig(•) in Equation 4) that also encodes its nested position within the hierarchy. The Jaccard similarity is the size of the intersection of the two signature sets divided by the size of their union, yielding a score between 0 and 1. For example, if the ground truth set of signatures is {A, B, C} and the generated set is {A, B, D}, the intersection has size 2 and the union size 4, resulting in a reward of +0.5. This evaluates the entire code skeleton, rewarding the model for identifying both the right components and their correct placement. The accuracy reward is defined as:   y)  Sig(y) ∩ Sig(b , if Sig(y) ∪ Sig(b y ) ̸= ∅ Rstructure (y, yb) = Sig(y) ∪ Sig(b y)  0, otherwise 8

(4)

To ensure that the outputs are well-formed, two penalty-based formatting rewards are included, as shown in Fig. 3a and Fig. 3b respectively. The first is a syntactic reward Rsyntax , which applies a penalty of −1 if yb is not a syntactically valid Python script according to the language specification LP ython . This discourages the model from producing malformed code that cannot be parsed into a complete code skeleton. The syntactic reward function is defined as: ( Rsyntax (b y) =

−1,

if yb ̸= ∅ and yb ∈ / LPython

0,

otherwise

(5)

The second is a length reward Rlength designed to prevent reward hacking, where the model might produce trivially short outputs to avoid syntactic errors. It applies a larger penalty of −3 if yb is both shorter than a minimum length threshold (Lmin ) and deviates in length from y by more than a tolerance τ . The magnitudes of the syntax and length rewards are calibrated to the severity of the error. The −1 penalty for a syntactic error is scaled to exactly negate the maximum possible score of +1, so an invalid script never yields a net positive reward, while the larger −3 reflects that a trivially short output is a more severe failure warranting a stronger deterrent. The length reward function is defined as: ( Rlength (y, yb) = 3.4

−3,

if |L(y) − L(b y )| > τ and L(b y ) < Lmin

0,

otherwise

(6)

Evaluation Metrics for Code Skeleton Comparison

This paper uses two metrics to evaluate the accuracy of the generated code skeletons. Both serve as proxies for the remediation effort a rule expert would need i.e., they quantify the editing operations needed to align a generated skeleton with the ground truth. As shown in Fig. 4, the first metric, tree edit distance, captures differences in the skeleton’s hierarchical structure, while the second, token-level Levenshtein distance, captures finer token-level differences such as naming. a) Tree Edit Distance Generated

Ground Truth

class Functions:

class Functions:

Match

def GetIncorrectDepth(): pass

Subst.

def GetConcreteFlowDepth(): pass def GetEarthFlowDepth(): pass

Insertion

b) Token-level Levenshtein Distance Generated

Ground Truth

class Airwell:

Match

class Airwell:

def GetClearHeightandWidth(): pass

def GetClearHeight(): Deletion

pass

Figure 4: Visualization of (a) tree edit distance and (b) token-level Levenshtein distance measures between generated and ground truth code skeletons. The first metric, as shown in Fig. 4a, quantifies the dissimilarity between the structures of the generated and reference code skeletons, such as incorrect nesting or missing class definitions. It 9

is computed in three steps. First, both code skeletons are parsed into simplified Abstract Syntax Trees (ASTs) that retain only the names and types of all class and function definitions. Next, each tree is linearized into a sequence of nodes by post-order traversal, which preserves the hierarchy by visiting child nodes before their parent. Finally, the standard edit distance is computed between the node sequence of the generated and reference skeletons i.e., the minimum number of node-level operations (insertions, deletions, and substitutions) required to transform one into the other. For example, as illustrated in Fig. 4a, consider a ground truth skeleton where a class ‘Functions’ contains two methods: ‘GetConcreteFlowDepth’ and ‘GetEarthFlowDepth’. The post-order traversal of its tree would yield the node sequence [‘GetConcreteFlowDepth’, ‘GetEarthFlowDepth’, ‘Functions’]. If a generated skeleton correctly defines the ‘Functions’ class but hallucinates the first method as ‘GetIncorrectDepth’ and completely omits the second ‘GetEarthFlowDepth’ method, the post-order traversal of its tree would be [‘GetIncorrectDepth’, ‘Functions’]. The resulting tree edit distance is exactly 2, as transforming the second sequence into the first requires one substitution (changing ‘GetIncorrectDepth’ to ‘GetConcreteFlowDepth’) and one insertion (adding in ‘GetEarthFlowDepth’). A lower score indicates closer alignment between the generated and ground truth code skeletons. To complement this, the token-level Levenshtein distance provides a more granular comparison, as shown in Fig. 4b. While character-level Levenshtein distance is common for natural language, a token-level metric is more appropriate for source code, for three reasons. First, the fundamental units of meaning in code are tokens (e.g., keywords, identifiers, operators), not individual characters, so evaluating at the token level better reflects the structure of the code. Second, it aligns the evaluation with the model’s generative process, since LLMs predict sequences of tokens. Third, it is less sensitive to trivial variations such as extra whitespace while still penalizing substantive errors e.g., a single typo in a long function name like ‘GetConcreteFlowDepth’ counts as one token substitution, a more proportional penalty than multiple character-level edits it would otherwise incur. To compute it, the generated and reference skeletons are encoded into token sequences using the model’s tokenizer, and the standard Levenshtein distance is applied to obtain the minimum number of single-token edits required to transform one into the other. This captures finer differences in naming and local code arrangement that the tree-based metric might miss. The two metrics evaluate the model’s ability to generate accurate code skeletons at both the structural and token levels. 3.5

Experimental Details for the Framework

All GRPO experiments were conducted on a single NVIDIA A100 40GB GPU. The GRPO stage was implemented using low-rank adaptation, configured to target all linear modules of the LLM. Following Shao et al. [12], the learning rate was set to 1e − 6 and optimized using AdamW with β1 = 0.9 and β2 = 0.95. A cosine learning rate scheduler with a warmup ratio of 0.1 was employed. Training was performed with an effective batch size of 4, achieved through 4 steps of gradient accumulation. For each prompt in a batch, the policy generated G = 16 responses with a high sampling temperature of 1.0 and a minimum probability sampling of 0.1 [44], chosen to encourage diverse responses for each prompt. The main experiments were run for a total of 2000 steps, with model checkpoints saved every 200 steps. The KL divergence coefficient βKL was set to the default value of 0.04 [12]. No hyperparameter tuning was performed i.e., standard values were used to keep the focus on the method, leaving an exhaustive search out of scope. 3.6

Experimental Details Comparing the Framework to SOTA Models

To evaluate the efficacy of the framework against the SOTA LLMs, a comparative analysis was conducted against five LLMs through their respective APIs: Claude Opus 4.5, Claude Sonnet 4.5, GPT-5.2, Qwen-3-Max, and GLM-4.7. These baseline models were selected to represent the frontier of general-purpose LLMs. Unlike the framework, which is evaluated in a zero-shot setting (i.e., without any examples during inference time, as shown in Fig. 5a), the baseline models were evaluated using few-shot prompting. This simulates a typical workflow where a general-purpose model is provided with context to guide its generation. Specifically, for each test query, a Retrieval-Augmented Generation (RAG) approach was used to retrieve top-k most similar code examples for that rule from the training set, ranked by cosine similarity of their vector embeddings. In this paper, one-shot and two-shot prompting (i.e., 10

k = 1 and k = 2) were tested. These retrieved examples were then inserted into the original prompt, as shown in Fig. 5b. a) Prompt used for zero-shot setting You are given a building rule described below. Your task is to generate a Python script, potentially using multiple functions and classes, that accurately implements the building rule. This task is critical and requires precise implementation. {rule here}

b) Prompt used for few-shot setting You are given a building rule described below. Your task is to generate a Python script, potentially using multiple functions and classes, that accurately implements the building rule. This task is critical and requires precise implementation. Do not provide low-level code implementation details nor unnecessary comments, provide only the high-level code skeleton. Here are examples for your reference: ``` {first example here} ``` Another example: ``` {if two-shot prompting, second example here} ``` Rule: {rule here}

Figure 5: Prompts relating to (a) zero-shot setting in the proposed framework and (b) few-shot setting in SOTA LLMs. Similar to the proposed framework, all baseline models were queried with a temperature of 0.0 to maximize determinism and reproducibility for ACC tasks. Aside from the insertion of few-shot examples, the baseline prompts, as shown in Fig. 5b, contain slightly more explicit instructions than P4IR’s, as the baselines lack the domain-specific SFT stage. This RAG-based few-shot setup was chosen as it has been shown to benefit LLMs in ACC domain by providing more contextually relevant answers [45]. For this comparison, four metrics were used i.e., tree edit distance and token-level Levenshtein distance described in Section 3.4, plus Jaccard distance [14, 43] and CodeBERTScore [13], covering both the structure and the semantics of the generated code skeletons.

4

Results and Discussion

SFT was conducted for 14 epochs in total, with checkpoints from epochs 4, 6, 8, 10, 12, and 14 selected as initial policies for the subsequent GRPO stage. This range was chosen as policies trained for fewer than 4 epochs were undertrained (i.e., a further 1-2 epochs still produced large gains), while the performance gains from SFT began to plateau after epoch 8, providing a suitable range to study the interaction between SFT and GRPO. The results show that GRPO’s effectiveness depends strongly on the initial policy from SFT, revealing an SFT window in which GRPO is most effective. This window is where the model has sufficient domain-specific knowledge from SFT to generate plausible structures, yet is not so over-trained that it loses the flexibility required for refinement through reinforcement learning. While GRPO generally improves the accuracy of the generated code skeletons, its benefits are realized only when starting from a suitable SFT checkpoint. 4.1

Interplay Between SFT Maturity and GRPO Effectiveness

Fig. 6 presents the primary evaluation metrics across GRPO optimization steps on models from different SFT epochs. In both heatmaps, lower values indicate a closer match to the ground truth (i.e., fewer edits to transform the generated code skeleton into the reference). A clear optimal performance window emerges for policies trained around 8 to 10 SFT epochs. For example, the epoch 10 policy, which begins with a tree edit distance of 28.38, is progressively improved by GRPO to a minimum of 21.63 after 2000 steps, a 23.8% reduction in edit distance. A similar trend is observed for the 11

token-level Levenshtein distance, which improves from 602.44 to a minimum of 369.93, a 38.6% reduction. In contrast, models at the extremes of SFT maturity show limited benefit. Policies from earlier SFT epochs, such as epochs 4 and 6, are underfitted. Although GRPO reduces their initial tree edit distance of 30.22, the final score of 27.47 remains well above that of the optimally trained models. This suggests that the SFT stage failed to instill sufficient foundational knowledge, leaving GRPO with a weak initial policy that is too far from a good solution to be refined effectively. Conversely, policies from later epochs, such as epochs 12 and 14, appear overfitted to the SFT dataset and fail to benefit from GRPO. While these models start with the strongest initial performance (i.e., a tree edit distance of 23.07 for epoch 12, which is the best score achieved through SFT), they show negligible improvement from GRPO. This indicates that the policy has become too deterministic, narrowing its output distribution to the point where it lacks the exploratory capacity for the GRPO reward signal to discover and reinforce better code skeletons.

24.96

28.26

27.41

23.57

26.51

23.68

26.74

8

24.66

28.28

25.21

23.87

24.04

23.51

22.09

23.46

21.43

21.76

21.60

28.38

30.18

23.29

24.18

23.46

21.90

23.38

22.00

22.19

22.44

21.63

23.07

23.25

23.93

22.28

23.54

23.32

23.19

23.96

24.60

23.41

22.43

623.29

497.59

615.90

532.21

469.50

479.29

532.91

599.41

686.13

711.82

678.84

420.38

492.88

474.22

474.12

460.29

396.06

501.97

638.44

685.03

506.84

629.49

524.76

463.06

381.24

468.16

454.40

423.96

372.66

602.44

560.84

573.72

551.63

528.46

370.35

405.00

430.59

385.63

398.29

369.93

440.66

387.63

457.57

389.88

401.06

400.19

402.94

455.62

428.65

468.34

386.60

474.18

485.56

544.88

498.62

495.57

431.51

486.35

486.94

428.84

451.31

422.74

0

26.26

556.07

0

29.31

687.65

80

33.24

585.96

0

6

31.68

700 625.12

60

27.47

0

27.87

40

27.76

20

30.65

4

30.71

6

28.99

8

34.31

10

32.00

12

34.72

14

30.15

34

0

4

30.22

10

(b) Average Token-Level Levenshtein Distance

12

(a) Average Tree Edit Distance

650

32

600

SFT Epoch

30

550

28

26

500

450

14

24 25.18

27.10

26.00

23.60

23.40

24.60

24.75

26.76

24.49

23.69

23.40

400

00

00

00

00

00

16

18

20

00 20

14

00 18

00

00 16

12

00 14

GRPO Step

10

00

0 80

12

0 60

00

0 40

10

0 20

0

22

GRPO Step

Figure 6: (a) Average tree edit distance and (b) average token-level Levenshtein distance. Lower values indicate better performance. 4.1.1

Logit Entropy Across SFT Epochs for Model Interpretability

The underlying mechanism for this performance disparity can be interpreted by analyzing the average logit entropy of the models during generation (i.e., model inference), as shown in Fig. 7. Logit entropy is calculated at each token-generation step. First, the raw output logits of the model are converted into a probability distribution P (x) over its entire token vocabulary using the softmax function. The Shannon entropy H(X) of this distribution is then computed using Equation 7 as follows: H(X) = −

X

p(xi ) log p(xi )

(7)

i

In this context, logit entropy serves as a proxy for the predictive uncertainty of the model, where high entropy indicates a more uniform probability distribution over the next token, encouraging exploration, while low entropy reflects high model confidence and leads to the exploitation of patterns learned during SFT. The analysis reveals three distinct behavioral patterns that correspond to the performance outcomes in Fig. 6. The underfitted epoch 4 policy exhibits consistently high logit entropy, especially at the start, indicating that the model is highly uncertain. This high degree of exploration leads to a wide diversity of generated code skeletons, many of which may be incorrect due to poor knowledge instillation during the SFT stage, making it difficult for the reward signal to guide the policy toward a good solution quickly enough. In contrast, the overfitted policies from epochs 12 and 14 show a rapid collapse in entropy, which approaches zero after approximately 1400 generation steps. This policy collapse indicates that the model has become overly confident and deterministic, repeatedly generating the same or nearly identical code skeletons. This lack of exploratory capacity deprives the GRPO algorithm of diverse sampled outputs, preventing it from discovering and reinforcing new higher-advantage outputs. The optimally performing policies from epochs 8 and 10 maintain a moderate and stable level of entropy throughout generation. These models strike a balance i.e., confident enough to generate coherent code skeletons, yet retaining enough stochasticity to explore 12

Epoch 4 Epoch 6 Epoch 8 Epoch 10 Epoch 12 Epoch 14

0.35

Smoothed Average Logit Entropy (nats)

0.30 0.25 0.20 0.15 0.10 0.05 0.00 0

500

1000

1500 Generation Step

2000

2500

3000

Figure 7: Smoothed average logit entropy during generation.

meaningful variations. This calibrated uncertainty is well suited to GRPO, balancing exploitation of known good structures against exploration for better ones. This also suggests that monitoring logit entropy is a useful interpretable heuristic [46] for identifying when an SFT model has reached the range best suited to the subsequent GRPO stage. 4.1.2

Effect of GRPO on Semantics Learned During SFT

While GRPO is effective at improving the accuracy of code skeletons, it is essential to preserve the domain knowledge instilled during SFT. The results indicate that it does not substantially alter the semantic content learned during the SFT stage. Fig. 8 shows the CodeBERTScore precision and recall for different SFT epochs across the GRPO steps, which measure the semantic similarity between the generated and reference code skeletons. Epoch 8

Epoch 10

Epoch 12

Epoch 14

0.845

0.843

0.843

0.840

0.840

13

00

00

20

00

Figure 8: (a) CodeBERTScore Precision and (b) CodeBERTScore Recall.

18

00

16

00

GRPO Steps

14

12

0

00 10

0

20

80

0

00

00

20

00

18

00

16

00

GRPO Steps

14

00

12

10

80

60

40

0

0.830

0

0.830

0

0.833

0

0.835

0.833

0

0.835

0

0.838

0

0.838

40

Score

0.845

20

Score

(b) CodeBERTScore Recall

60

Epoch 6

(a) CodeBERTScore Precision

Across all epochs, both CodeBERTScore precision and recall remain stable throughout the GRPO process, indicating that GRPO refines structure while preserving the semantic knowledge acquired during SFT. For example, the precision for the epoch 10 model fluctuates within a narrow band from approximately 0.834 to 0.840, and its recall similarly stays between 0.838 and 0.843. Although there is a general trend of slightly increasing precision and decreasing recall as GRPO proceeds, the semantic understanding is already established during SFT and is largely unchanged by GRPO. This corroborates that SFT instills the domain-specific semantic knowledge [13], whereas GRPO refines the structure of that knowledge to improve accuracy without substantially changing its semantics. 4.2

Reducing Model Hallucinations

The GRPO stage also reduces model hallucinations through the reward functions. This analysis focuses on one measurable form of hallucination i.e., the fabrication of extraneous classes or functions (false positives, FP) not present in the ground truth. To quantify this, the number of FP is measured in each generated output. An aggregated analysis across all epochs shows a reduction in these hallucinations. The mean FP count decreased from 21.60 for SFT models to 18.60 after the GRPO stage, accompanied by a decrease in the standard deviation from 23.87 to 18.00 and in the median FP count from 15.0 to 14.0, indicating that the GRPO models are more consistent as well as more accurate on average. To verify the statistical significance of this reduction, both non-parametric and parametric one-sided paired tests were conducted. The Wilcoxon signed-rank test yielded p < 0.001, corroborated by the paired t-test with p = 0.005, confirming a statistically significant reduction in FP. Nonetheless, the effect size (Cohen’s d = 0.127) is small i.e., the reduction is consistent enough to be distinguished from chance, but modest in practical magnitude. 4.3

Qualitative Analysis of Reference and Generated Code Skeletons

In this section, four code skeletons are presented in Fig. 9 to Fig. 12 as a qualitative comparison to further illustrate how GRPO improves accuracy while reducing hallucinations. These examples compare the initial SFT output with the refined code skeleton produced after the GRPO stage. Definitions shown in bold correspond to those present in the reference. ​CDF​ ​ S 9.2.1​ ​ a​ ​ (5)​ ​ (a)​ ​ -​ ​ Travel​ ​ distance​ ​ within​ ​ a​ ​ residential​ ​ unit:​ ​ (a)​ ​ In​ ​ each​ ​ residential​ ​ apartment​ ​ or​ ​ maisonette​ ​ unit,​ ​ the​ ​ exit​ access​​ ​ door​​ or​​ doors​​ shall​​ be​​ provided​​ such​​ that​​ the​​ travel​​ distance​​ measured​​ from​​ any​​ point​​ within​​ the​​ unit​​ to​​ the​​ entrance​​ door(s)​ of the unit shall not exceed 20m.​ ​ ​a)Reference.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── UTParser​ ​ │ ​ ├── __init__()​ │ ​ ├── GetStoreyParent()​ │ ​ ├── CheckBuildingPDT()​ │ ​ ├── GetConditionTableValues()​ │ ​ └── GetClassificationCode()​ ├── FilterAreaAndRoom()​ ​ ├── GetBoundDoor()​ ​ ├── GetEntranceDoorFromResidentalArea()​ ​ ├── GetConnectedSpaces()​ ​ ├── GetStartPointResidential()​ ​ ├── GetEndPoint()​ ​ ├── CreateOpeningGeometry()​ ​ ├── GetStoreyObstructions()​ ​ ├── GetStoreySlab()​ ​ └── IsConnected()​ ​

​b)SFT.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ └── UTParser​ ​ ├── __init__()​ ​ ├── GetStoreyParent()​ ​ ├── GetClassificationCode()​ ​ ├── GetBuildingStorey()​ ​ ├── GetStoreyObstructions()​ ​ ├── GetStoreySlab()​ ​ ├── GetStartPoint()​ ​ ├── GetEndPoint()​ ​ ├── GetTravelDistance()​ ​ ├── RemoveDuplicatedOpening()​ ​ ├── GetExitDoor()​ ​ ├── GetDoor()​ ​ ├── GetDoorFaces()​ ​ ├── GetDoorClearWidth()​ ​ ├── GetDoorFacesPoly()​ ​ ├── GetPolyBotFace()​ ​ ├── GetIntersectedObstruction()​ ​ ├── GetIntersectedLine()​ ​ ├── GetLineOutside()​ ​ ├── GetSetbackDistance()​ ​ ├── GetSetbackLine()​ ​ ├── GetParents()​ ​ ├── GetResidentialUnit()​ ​ ├── GetUnitDoor()​ ​ ├── GetDoorSpace()​ ​ ├── GetDoorSpaceAccess()​ ​ ├── ...​ ​ └── └── (and 15 more erroneous​ ​ ‘Get...()’ methods)​ ​

​c)GRPO.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── UTParser​ ​ │ ​ ├── __init__()​ │ ​ ├── GetStoreyParent()​ │ ​ ├── InsertValuesFromKey()​ │ ​ └── GetClassificationCode()​ ├── GetBuildingStorey()​ ​ ├── GetStoreyObstructions()​ ​ ├── GetStoreySlab()​ ​ ├── GetStartPointResidential()​ ​ ├── GetEndPoint()​ ​ ├── GetTravelDistance()​ ​ ├── RemoveDuplicatedOpening()​ ​ ├── RemoveStairCaseUnderRefuge()​ ​ ├── IsConnected()​ ​ ├── RemoveDoorsBoundedByHabitableSpace()​ ​ ├── GetNearerToCorridor()​ ​ ├── ReverseKeyAndValue()​ ​ ├── CreateOpeningGeometry()​ ​ ├── CheckResidentialCompliance()​ ​ ├── RelatedObjectName()​ ​ ├── CheckSpaceCompliance()​ ​ ├── IsOneWayTravelResidential()​ ​ ├── GetSpaceWithoutPhysicallyBoundedDoor()​ ​ ├── GetIntersectedDoor()​ ​ ├── GetDoorSpace()​ ​ └── GetNearestRoomSpace()​ ​

Figure 9: Example pertaining to travel distance, showing (a) the reference, (b) the SFT-generated, and (c) the GRPO-refined code skeleton. 14

Fig. 9 shows how GRPO reduces hallucinations and corrects the hierarchy. The SFT model in Fig. 9b produces an inaccurate code skeleton. While the SFT model identifies the ‘UTParser’ class, it proceeds to incorrectly define all subsequent logic as methods under it, including hallucinating over 15 erroneous ‘Get. . . ()’ methods. The model after the GRPO stage corrects these issues. It removes the majority of irrelevant hallucinated methods, then nests only the relevant methods under ‘UTParser’ while terminating the list appropriately, so that subsequent functions such as ‘GetStoreyObstructions()’ and ‘GetStoreySlab()’ are correctly placed outside the ‘UTParser’ class definition. This demonstrates an improved understanding of object-oriented code structure. ​CDF 2.3.12 (b) (1) - One-way travel distance: If the distance between the 2 exits or exit access doors is less than half the length​ S of​ ​ ​ the​ ​ maximum​ ​ overall​ ​ diagonal​ ​ dimension​ ​ of​ ​ the​ ​ building​ ​ or​ ​ area​ ​ to​ ​ be​ ​ served,​ ​ it​ ​ shall​ ​ be​ ​ considered​ ​ as​ ​ a​ ​ one-way​ ​ escape​ arrangement.​ ​ ​a)Reference.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── ExitFacilitiesCls​ ​ │ ​ ├── MainChecking()​ │ ​ ├── MeasureExitFacilities()​ │ ​ ├── GetSpacesOccLoad()​ │ ​ ├── GetSpaceListDiagLine()​ │ ​ ├── GetOccupancyLoad()​ │ ​ ├── GetBottomFaceArea()​ │ ​ ├── GetSpaces()​ │ ​ ├── GetExitFacilitiesCls()​ │ ​ ├── CheckStairsInCorridor()​ │ ​ ├── GetStaircaseSpStairs()​ │ ​ ├── GetSpaceAccess()​ │ ​ ├── SetRelatedObj()​ │ ​ ├── MeasureExitDistance()​ │ ​ ├── GetExitFacelist()​ │ ​ └── GetFarthestDistance()​ ├── UniversalTemplate​ ​ │ ​ ├── __init__()​ │ ​ ├── GetStoreyBBoxPoly()​ │ ​ ├── GetBldgStoreyBBox()​ │ ​ ├── ConstructBBox()​ │ ​ ├── CheckBuildingPDT()​ │ ​ └── GetConditionTableValues()​ ├── GetElementParent()​ ​ ├── InsertValuesFromKey()​ ​ ├── ElementName()​ ​ ├── GetClassificationCode()​ ​ ├── GetBuildingStoreyMtd()​ ​ ├── GetStoreyObstructions()​ ​ ├── FilterAreaAndRoom()​ ​ └── SpaceOccupancyFactors​ ​ ├── __init__()​ ​ └── GetFactor()​ ​

​b)SFT.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── UniversalTemplate​ ​ │ ​ └── __init__()​ ├── GetExit()​ ​ ├── GetDoor()​ ​ ├── GetStairFlight()​ ​ ├── GetStoreyParent()​ ​ ├── InsertValuesFromKey()​ ​ ├── GetClassificationCode()​ ​ ├── GetSpaces()​ ​ ├── EvaluateOneWayDistance()​ ​ ├── GetNearerToCorridor()​ ​ ├── ReverseKeyAndValue()​ ​ ├── CreateExitGraph()​ ​ ├── GetParentBuilding()​ ​ ├── CheckForTemporaryExit()​ ​ ├── GetExitDoor()​ ​ ├── CheckRuleApplicability()​ ​ ├── GetSpaceListDiagLine()​ ​ ├── GetFarthestSpace()​ ​ ├── GetStoreyCenter()​ ​ ├── CreateDiagonalLine()​ ​ ├── GetIntersect()​ ​ ├── GetAllIntersect()​ ​ ├── GetDepth()​ ​ ├── GetCandidatesElements()​ ​ ├── GetStairFlightParent()​ ​ ├── CheckForVerticalStairflight()​ ​ ├── GetSpaceListForVertical()​ ​ └── ...​ ​ └── (and 16 more ‘...ForVertical()’​ ​ functions)​ ​ ├── CheckForDiagLine()​ ​ ├── Get2DDistance()​ ​ └── GetExactStorey()​ ​

​c)GRPO.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── UniversalTemplate​ ​ │ ​ └── __init__()​ ├── GetExit()​ ​ ├── GetDoor()​ ​ ├── FilterNonPhysicalDoor()​ ​ ├── GetStairFlight()​ ​ ├── GetStoreyParent()​ ​ ├── InsertValuesFromKey()​ ​ ├── GetClassificationCode()​ ​ ├── GetSpaces()​ ​ ├── EvaluateOneWayDistance()​ ​ ├── GetNearerToCorridor()​ ​ ├── ReverseKeyAndValue()​ ​ ├── CapitalizedFirstLetter()​ ​ ├── RelatedObjectName()​ ​ ├── DisplayOccupantLoad()​ ​ ├── GetSpaceListDiagLine()​ ​ ├── GetOccupancyLoad()​ ​ ├── GetBottomFaceArea()​ ​ ├── FilterAreaAndRoom()​ ​ └── SpaceOccupancyFactors​ ​ ├── __init__()​ ​ └── GetFactor()​ ​

Figure 10: Example pertaining to one-way escape arrangements, showing (a) the reference, (b) the SFT-generated, and (c) the GRPO-refined code skeleton. Fig. 10 further highlights the strength of the framework. Apart from reducing hallucinations as in the previous example, this case shows GRPO recovering entire class definitions and correct methods absent from the SFT output. The SFT model shown in Fig. 10b produces a largely unusable code skeleton, overwhelmed by a long list of hallucinated methods. In contrast, the GRPO model shown in Fig. 10c reduces this noise and improves completeness. It regenerated the complete ‘SpaceOccupancyFactors’ class, including its ‘__init__()’ and ‘GetFactor()’ methods, a key abstraction for this regulation that the SFT model had failed to produce, and recovers other methods like ‘GetOccupancyLoad()’ and ‘GetBottomFaceArea()’. Even so, a key limitation remains in capturing the full structural complexity. The reference shown in Fig. 10a uses a nested, multi-class hierarchy with components such as ‘ExitFacilitiesCls’ and ‘UniversalTemplate’. The GRPO output, while more than the SFT model (i.e., fewer hallucinated functions), still presents a comparatively flattened structure. This indicates that while the framework recovers essential classes and methods and reduces redundancy, replicating intricate hierarchical patterns remains challenging. Fig. 11 shows how GRPO improves coherence by correcting structural flaws and removing certain hallucinations. The SFT model shown in Fig. 11b produces an inefficient structure, creating a ‘GFAUtility’ class populated with a long series of incrementally named and hallucinated methods (e.g., ‘GetIntersectedEle2’ through ‘GetIntersectedEle10’). The GRPO stage removes these redundant methods and reorganizes the logic into a more sensible ‘RuleUtility’ class. This refinement also illustrates semantic equivalence. While the GRPO-generated methods, such as ‘CheckRuleWidth’, are not syntactically identical to the ‘GetLinkwayWidth’ method in the reference output, they capture 15

​.14.3.1​ ​ 7 -​ ​ Underground​ ​ linkages​ ​ –​ ​ To​ ​ Rapid​ ​ Transit​ ​ System​ ​ (RTS)​​ stations:​​ As​​ the​​ underground​​ pedestrian​​ links​​ function​​ as​​ a​​ public​ thoroughfare,​ ​ ​ the​ ​ floor​ ​ area​ ​ of​ ​ the​ ​ underground​ ​ pedestrian​ ​ walkway​ ​ can​ ​ be​ ​ exempted​ ​ from​ ​ the​ ​ gross​ ​ floor​ ​ area​ ​ computation​ ​ if​ ​ the​ following​​ ​ criteria​​ are​​ satisfied.​​ The​​ underground​​ pedestrian​​ link​​ will​​ have​​ a​​ clear​​ pedestrian​​ walkway​​ width​​ of:​​ (i)​​ Between​​ 6m​​ -​​ 7m​ for​​ ​ walkway​​ with​​ single-loaded​​ uses;​​ or​​ (ii)​​ A​​ minimum​​ width​​ of​​ 7m​​ for​​ walkway​​ with​​ double-loaded​​ uses.​​ For​​ walkways​​ that​​ are​​ greater​ than 7m wide, the exemption is given up to 7m only.​ ​ ​a)Reference.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── UniversalTemplate​ ​ │ ​ ├── __init__()​ │ ​ └── GetCondition()​ ├── GeneralRuleLogs​ ​ │ ​ └── Add()​ └── SpaceRule​ ​ ├── __init__()​ ​ ├── GetActivitySpaceChecking()​ ​ ├── GetLinkWayWidth()​ ​ ├── GetLinkWayRelatedObjs()​ ​ └── GetLinkWayChecking()​ ​

​b)SFT.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── UniversalTemplate​ ​ │ ​ ├── __init__()​ │ ​ ├── GetSpaceType1InStorey()​ │ ​ ├── GetSpaceType2InStorey()​ │ ​ ├── GetSpaceType3InStorey()​ │ ​ ├── GetElement2Query()​ │ ​ ├── ... (methods 3 through 8)​ │ ​ ├── GetElement9Query()​ │ ​ └── GetElement10Query()​ ├── GFAUtility​ ​ │ ​ ├── GetIntersectedEle()​ │ ​ ├── GetIntersectedEle2()​ │ ​ ├── ... (methods 3 through 8)​ │ ​ ├── GetIntersectedEle9()​ │ ​ ├── GetIntersectedEle10()​ │ ​ ├── GetPolyBotFace()​ │ ​ └── GetSpaceGFAFaces()​ └── Space​ ​ ├── __init__()​ ​ ├── IsSingleLoaded()​ ​ ├── IsDoubleLoaded()​ ​ ├── GetWidth()​ ​ ├── IsInPDT()​ ​ ├── IsConnectedToOtherSpace()​ ​ └── HasObstructions()​ ​

​c)GRPO.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── UniversalTemplate​ ​ │ ​ ├── __init__()​ │ ​ └── GetSpaceType1InStorey()​ ├── Space​ ​ │ ​ ├── __init__()​ │ ​ └── GetGFAFaces()​ └── RuleUtility​ ​ ├── CheckRuleWidth()​ ​ ├── GetClearWidth()​ ​ ├── GetObstruction()​ ​ ├── GetSpaceWithin()​ ​ └── GetDoor()​ ​

Figure 11: Example pertaining to underground pedestrian linkages, showing (a) the reference, (b) the SFT-generated, and (c) the GRPO-refined code skeleton. the same functional intent. This is a limitation for precise replication, but also shows the model generating accurate and equivalent abstractions. ​.30.4​ ​ 7 Shadow​ ​ areas​ ​ -​ ​ Sloping​ ​ ground:​ ​ Shadow​ ​ areas​ ​ on​ ​ existing​ ​ undulating​ ​ sloping​ ​ terrain​ ​ or​ ​ sloping​ ​ ground​ ​ below​ ​ building​ structures,​​ ​ platform​​ or​​ deck​​ can​​ be​​ excluded​​ from​​ gross​​ floor​​ area​​ computation.​​ To​​ qualify​​ for​​ exemption,​​ the​​ exempted​​ shadow​​ areas​ cannot be enclosed on the sides.​ ​ ​a)Reference.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── ParseUT​ ​ │ ​ └── __init__()​ ├── ParseQuery​ ​ │ ​ ├── __init__()​ │ ​ └── GetTopoQuery()​ ├── UtilityLocal​ ​ │ ​ ├── ShrinkageLine()​ │ ​ ├── GetExtrudeLineBothSides()​ │ ​ ├── GetIntersectedEle()​ │ ​ ├── HasWalls()​ │ ​ └── GetStoreyList()​ └── Geometry​ ​ ├── GetTopFaces()​ ​ └── IsFaceSlope()​ ​

​b)SFT.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── ParseUT​ ​ │ ​ ├── __init__()​ │ ​ └── GetCondition()​ └── UtilityLocal​ ​ ├── GetSideFaces()​ ​ ├── GetIntersectedEle()​ ​ ├── GetLongestLine()​ ​ ├── GetHighestElev()​ ​ ├── GetCollidedWater()​ ​ ├── GetElevation()​ ​ ├── ...​ ​ └── └── (and 80+ more methods,​ ​ including many redundant definitions)​ ​

​c)GRPO.py​ ( ├── main()​ ​ ├── CheckRule()​ ​ ├── ParseUT​ ​ │ ​ ├── __init__()​ │ ​ └── GetCondition()​ └── UtilityLocal​ ​ ├── GetSideFaces()​ ​ ├── GetIntersectedEle()​ ​ ├── GetInteract()​ ​ ├── GetHeight()​ ​ ├── GetSlope()​ ​ ├── GetHighestSlope()​ ​ ├── GetExtrudeLineBothSides()​ ​ ├── GetIntersect()​ ​ ├── GetSidePoints()​ ​ ├── GetDistance()​ ​ ├── GetLine()​ ​ └── GetIntersected()​ ​

Figure 12: Example pertaining to shadow area calculation, showing (a) the reference, (b) the SFTgenerated, and (c) the GRPO-refined code skeleton. Lastly, Fig. 12 presents a clear case of mitigating severe generation failure. The SFT model shown in Fig. 12b falls into a generative loop, hallucinating over 80 redundant methods i.e., a case of model collapse that renders the output unusable. The GRPO stage shown in Fig. 12c resolves this failure mode, using its formatting reward to penalize such repetitive and non-productive generation. These truncated outputs (i.e., incomplete generations that exceed the maximum token limit through runaway hallucination and so fail to produce a coherent result) drop from 2.45% across all SFT models to less than 0.5% under GRPO. The resulting code skeleton is pruned to a concise and relevant set of functions. While this is a significant improvement, the GRPO output still simplifies the reference structure, combining logic from the reference’s ‘UtilityLocal’ and ‘Geometry’ classes into a single ‘UtilityLocal’ class. This shows that while GRPO can correct severe generation errors, it may favor simpler structures over the more nuanced designs in the ground truth, suggesting that additional reward functions could address this issue. 16

Table 1: Comparative performance of P4IR (zero-shot) against retrieval-augmented SOTA models via few-shot prompting. Downward arrow indicates lower is better, and vice versa. Best results are in bold. Jaccard Tree Edit Token-level CodeBERT CodeBERT Distance (↓) Levenshtein (↓) Distance (↓) Precision (↑) Recall (↑)

Model

Setting

Claude Opus 4.5

1-shot 2-shot

33.18 36.47

808.94 802.62

0.9242 0.9178

0.7579 0.7689

0.8004 0.8100

Claude Sonnet 4.5

1-shot 2-shot

27.81 30.07

607.75 594.34

0.9087 0.8974

0.7666 0.7805

0.7962 0.8045

GPT-5.2

1-shot 2-shot

28.29 29.60

1234.22 1283.87

0.9556 0.9515

0.7054 0.7142

0.7800 0.7929

Qwen-3-Max

1-shot 2-shot

22.82 22.78

411.21 395.13

0.8808 0.8868

0.7784 0.7833

0.7922 0.7878

GLM-4.7

1-shot 2-shot

24.66 22.56

546.53 475.78

0.8806 0.8721

0.7815 0.7884

0.7971 0.7915

P4IR

FT + GRPO (0-shot)

20.49

372.66

0.7081

0.8399

0.8400

4.4

Comparative Results of P4IR Against SOTA Models

To position the proposed framework within the landscape of current LLMs, the optimal policy (i.e., fine-tuned for 8 epochs and reinforced for 2000 steps) was evaluated against five SOTA models via few-shot prompting: Claude Opus 4.5, Claude Sonnet 4.5, GPT-5.2, Qwen-3-Max, and GLM-4.7, as described in Section 3.6. As summarized in Table 1, P4IR outperforms all five baselines on every metrics, despite operating in a zero-shot setting without access to retrieved samples at inference, and being orders of magnitude smaller. In general, Claude Opus 4.5, Claude Sonnet 4.5, and GPT-5.2 perform poorly across all metrics. The 1-shot versus 2-shot comparison also reveals a counter-intuitive trend for these three models. In fact, increasing the number of exemplars from one to two degraded the tree edit distance (e.g., Claude Opus worsened from 33.18 to 36.47). This context pollution suggests that for highly specialized tasks like ACC, simply injecting more examples into the context window of a general-purpose model may be insufficient and potentially detrimental. The additional context may introduce conflicting patterns that confuse the model. In contrast, P4IR internalizes domain knowledge through SFT and refines it via GRPO, yielding a more stable policy that does not rely on inference-time retrieval or external vector databases. Qwen-3-Max and GLM-4.7 exhibit a distinct performance pattern compared to the weaker baselines. They make better use of few-shot prompting, achieving competitive tree edit and token-level Levenshtein distance. For example, with two-shot prompting, Qwen-3-Max and GLM-4.7 achieved tree edit distances of 22.78 and 22.56, and token-level Levenshtein distances of 395.13 and 475.78, respectively. However, this improvement does not translate to accurate content. Despite lower edit distances, these two models, like all other baselines, recorded high Jaccard distances (i.e., >0.87), which is worse than that of P4IR. These scores should be read in light of how strict the Jaccard metric is for ACC, since it penalizes even minor lexical variation in predicate naming. As a reference point, Xue and Zhang [43] reported that even between human domain experts, the inter-annotator Jaccard distance is approximately 0.63, indicating that the reference is only one of several valid structures, and that a distance near zero is neither achievable nor expected. While this figure measures a related rather than identical quantity, it provides a useful floor. P4IR’s 0.7081 sits close to this expert-disagreement level, whereas the SOTA models (i.e., around 0.90) remain well above it, indicating a more fundamental failure to recover the correct domain-specific class and function identifiers. The CodeBERTScores show a similar pattern, where the baseline scores lower on semantic similarity, indicating that even Qwen-3-Max and GLM-4.7, which mimic the code skeleton better than other baselines, fail to generate the correct domain-specific identifiers. P4IR achieves the highest CodeBERTScore precision and recall of 0.84. While the baselines achieved reasonable recall (i.e., peaking at 0.81 for Claude Opus 4.5), their lower precision scores indicate a tendency to include irrelevant 17

logic alongside correct predictions (i.e., hallucinations). In ACC systems, this lower precision reduces reliability, as it forces rule experts to manually filter out these FPs from the generated code skeleton. P4IR’s balanced high performance indicates that the GRPO stage preserved the semantic knowledge from SFT while improving structure and reducing hallucinations, producing code skeletons that are both syntactically valid and semantically close to the reference.

5

Limitations and Future Work

While P4IR improves the accuracy of code skeletons and reduces hallucinations, several limitations qualify these findings and highlight directions for future work. First, P4IR rewards structural accuracy rather than functional correctness. Although the accuracy of the IRs bridging building regulations and the computer-processable rules is improved, whether the model can be reinforced directly for functional correctness remains an open question. Future work could explore rewarding the model based on the outcomes of BIM unit tests (i.e., pass/fail results from a BIM sandbox environment) corresponding to the generated computer-processable rules. While this would more directly optimize for executable accuracy, it presents challenges, including the need for extensive test-case datasets and the added complexity of creating rule interpretation datasets. Second, the framework relies on a labeled dataset of ground-truth code skeletons. This supervised approach may limit its applicability where such curated data is scarce, a common challenge in ACC. Despite just 732 samples, the dataset is substantial in the ACC context, as each sample typically requires days of effort to convert a rule into a computer-processable format. In addition, while P4IR has been shown to reduce hallucinations via GRPO, comparison to other RL algorithms (e.g., PPO/RLHF) remains to be tested. Future work could investigate semi-supervised or self-supervised methods for instilling domain knowledge, potentially by leveraging an LLM already pre-trained on a large corpus of domain-specific data, thereby reducing the need for domain-specific SFT. Lastly, this paper focuses on a single form of IR (i.e., code skeleton), leaving its generalizability to other structured formats unexplored. Building regulations also differ widely across countries in structure and terminology, leading to semantic inconsistencies in vocabulary. P4IR has not been tested on this variation due to the scarcity of labeled rule interpretation datasets, so its ability to generalize without country-specific training remains unknown. Future work could investigate additional specialized reward functions and this GRPO-based approach on other IRs, such as atomic functions or ontologies, to assess its broader utility in ACC. P4IR could also be evaluated on schemaconstrained IRs (e.g., LegalRuleML), where fixed syntax reduces stylistic variation and may yield a more stable target for reward design and evaluation.

6

Conclusion

This paper introduces the P4IR framework, an approach to improve the accuracy of code skeletons while reducing hallucinations. The framework first uses SFT to instill foundational domain knowledge before applying GRPO to refine the generated code skeletons. The results show that P4IR reduces the distance between the generated and ground-truth code skeletons. Hallucinations (in the form of redundant or fabricated classes and functions) are also reduced i.e., a small but statistically significant effect (p = 0.005, paired t-test; p < 0.001, Wilcoxon), contributing to more consistent outputs. The comparison with SOTA LLMs shows that, despite their recent advances, these models lack the capabilities for off-the-shelf application to specialized, real-world ACC tasks. In contrast, P4IR produces a specialized model that outperforms far larger baselines while offering a privacy-preserving workflow, processing sensitive regulatory and design data locally without compromising performance. Despite these limitations, P4IR augments SFT with explicit optimization for domain-specific objectives. By adding GRPO with task-specific rewards, it optimizes directly for the structural accuracy of the code skeleton, beyond what SFT alone achieves. This produces more accurate code skeletons with fewer hallucinations, reducing the manual effort rule experts need to verify and edit the generated outputs. As the AEC industry adopts automated workflows, combining SFT with GRPO offers a promising direction for more accurate LLM-based ACC systems that convert building regulations into computer-processable rules. 18

References and Construction Authority (BCA), Construction demand to [1] Building remain strong for 2025, BCA (2025). https://www1.bca.gov.sg/ about-us/news-and-publications/media-releases/2025/01/23/ construction-demand-to-remain-strong-for-2025 (accessed August 4, 2025). [2] Z. Zheng, J. Han, K.-Y. Chen, X.-Y. Cao, X.-Z. Lu, J.-R. Lin, Translating regulatory clauses into executable codes for building design checking via large language model driven function matching and composing, Eng. Appl. Artif. Intell. 163 (2026) 112823. https://doi.org/10. 1016/j.engappai.2025.112823 [3] R. Zhang, N. El-Gohary, Hierarchical representation and deep learning–based method for automatically transforming textual building codes into semantic computable requirements, J. Comput. Civ. Eng. 36 (2022) 04022022. https://doi.org/10.1061/(ASCE)CP.1943-5487. 0001014 [4] S. Fuchs, J. Dimyadi, M. Witbrock, R. Amor, Intermediate representations to improve the semantic parsing of building regulations, Adv. Eng. Inform. 62 (2024) 102735. https://doi. org/10.1016/j.aei.2024.102735 [5] J. Zhang, How can ChatGPT help in automated building code compliance checking?, Int. Symp. Autom. Robot. Constr. ISARC Proc. 2023 Proceedings of the 40th ISARC, Chennai, India (2023) 63–70. https://doi.org/10.22260/ISARC2023/0011 [6] S. Fuchs, M. Witbrock, J. Dimyadi, R. Amor, Using large language models for the interpretation of building regulations, (2024). https://doi.org/10.48550/arXiv.2407.21060 [7] S. Lin, J. Hilton, O. Evans, TruthfulQA: measuring how models mimic human falsehoods, in: S. Muresan, P. Nakov, A. Villavicencio (Eds.), Proc. 60th Annu. Meet. Assoc. Comput. Linguist. Vol. 1 Long Pap., Association for Computational Linguistics, Dublin, Ireland, 2022: pp. 3214–3252. https://doi.org/10.18653/v1/2022.acl-long.229 [8] L. Huang, W. Yu, W. Ma, W. Zhong, Z. Feng, H. Wang, Q. Chen, W. Peng, X. Feng, B. Qin, T. Liu, A survey on hallucination in large language models: principles, taxonomy, challenges, and open questions, ACM Trans. Inf. Syst. 43 (2025) 1–55. https://doi.org/10.1145/ 3703155 [9] S. Fuchs, M. Witbrock, J. Dimyadi, R. Amor, Neural semantic parsing of building regulations for compliance checking, IOP Conf. Ser. Earth Environ. Sci. 1101 (2022) 092022. https: //doi.org/10.1088/1755-1315/1101/9/092022 [10] K. Tian, E. Mitchell, H. Yao, C. Manning, C. Finn, Fine-tuning language models for factuality, in: NeurIPS 2023 Workshop on Instruction Tuning and Instruction Following, 2023. https: //openreview.net/forum?id=kEK08VdSO5 (accessed November 10, 2025). [11] P. Roit, J. Ferret, L. Shani, R. Aharoni, G. Cideron, R. Dadashi, M. Geist, S. Girgin, L. Hussenot, O. Keller, N. Momchev, S. Ramos Garea, P. Stanczyk, N. Vieillard, O. Bachem, G. Elidan, A. Hassidim, O. Pietquin, I. Szpektor, Factually consistent summarization via reinforcement learning with textual entailment feedback, in: A. Rogers, J. Boyd-Graber, N. Okazaki (Eds.), Proc. 61st Annu. Meet. Assoc. Comput. Linguist. Vol. 1 Long Pap., Association for Computational Linguistics, Toronto, Canada, 2023: pp. 6252–6272. https://doi.org/ 10.18653/v1/2023.acl-long.344 [12] Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y.K. Li, Y. Wu, D. Guo, DeepSeekMath: pushing the limits of mathematical reasoning in open language models, (2024). https://doi.org/10.48550/arXiv.2402.03300 [13] J.W.L. Shi, W. Solihin, J.K.W. Yeoh, Fine-tuning a large language model for automated code compliance of building regulations, Adv. Eng. Inform. 68 (2025) 103676. https://doi.org/ 10.1016/j.aei.2025.103676 19

[14] F. Yang, J. Zhang, Prompt-based automation of building code information transformation for compliance checking, Autom. Constr. 168 (2024) 105817. https://doi.org/10.1016/j. autcon.2024.105817 [15] C. Eastman, J. Lee, Y. Jeong, J. Lee, Automatic rule-based checking of building designs, Autom. Constr. 18 (2009) 1011–1033. https://doi.org/10.1016/j.autcon.2009.07.002 [16] E. Hjelseth, N. Nisbet, Capturing normative constraints by use of semantic mark-up RASE methodology, Proc. CIB W78-W102 Conf. Pp 1-10 (2011). https://itc.scix.net/pdfs/ w78-2011-Paper-45.pdf [17] I. Fitkau, T. Hartmann, An ontology-based approach of automatic compliance checking for structural fire safety requirements, Adv. Eng. Inform. 59 (2024) 102314. https://doi.org/ 10.1016/j.aei.2023.102314 [18] J.-K. Lee, C.M. Eastman, Y.C. Lee, Implementation of a BIM domain-specific language for the building environment rule and analysis, J. Intell. Robot. Syst. 79 (2015) 507–522. https://doi.org/10.1007/s10846-014-0117-7 [19] H. Kim, J.-K. Lee, J. Shin, J. Choi, Visual language approach to representing KBimCode-based korea building code sentences for automated rule checking, J. Comput. Des. Eng. 6 (2019) 143–148. https://doi.org/10.1016/j.jcde.2018.08.002 [20] J. Zhang, N.M. El-Gohary, Semantic NLP-based information extraction from construction regulatory documents for automated compliance checking, J. Comput. Civ. Eng. 30 (2016) 04015014. https://doi.org/10.1061/(ASCE)CP.1943-5487.0000346 [21] J. Song, J.-K. Lee, J. Choi, I. Kim, Deep learning-based extraction of predicate-argument structure (PAS) in building design rule sentences, J. Comput. Des. Eng. 7 (2020) 563–576. https://doi.org/10.1093/jcde/qwaa046 [22] D. Guo, E. Onstein, A.D.L. Rosa, A semantic approach for automated rule compliance checking in construction industry, IEEE Access 9 (2021) 129648–129660. https://doi.org/10. 1109/ACCESS.2021.3108226 [23] Z. Zheng, Y.-C. Zhou, X.-Z. Lu, J.-R. Lin, Knowledge-informed semantic alignment and rule interpretation for automated compliance checking, Autom. Constr. 142 (2022) 104524. https://doi.org/10.1016/j.autcon.2022.104524 [24] J. Peng, X. Liu, Automated code compliance checking research based on BIM and knowledge graph, Sci. Rep. 13 (2023) 7065. https://doi.org/10.1038/s41598-023-34342-1 [25] P. Zhou, N. El-Gohary, Ontology-based automated information extraction from building energy conservation codes, Autom. Constr. 74 (2017) 103–117. https://doi.org/10.1016/j. autcon.2016.09.004 [26] J. Zhang, N.M. El-Gohary, Integrating semantic NLP and logic reasoning into a unified system for fully-automated code checking, Autom. Constr. 73 (2017) 45–57. https://doi.org/10. 1016/j.autcon.2016.08.027 [27] J. Wu, X. Xue, J. Zhang, Invariant signature, logic reasoning, and semantic natural language processing (NLP)-based automated building code compliance checking (I-SNACC) framework, J. Inf. Technol. Constr. 28 (2023) 1–18. https://doi.org/10.36680/j.itcon.2023.001 [28] N. Wang, R.R.A. Issa, C.J. Anumba, NLP-based query-answering system for information extraction from building information models, J. Comput. Civ. Eng. 36 (2022) 04022004. https: //doi.org/10.1061/(ASCE)CP.1943-5487.0001019 [29] O. Okonkwo, Leveraging word embeddings and transformers to extract semantics from building regulations text, 11th Linked Data Archit. Constr. Workshop June 11–15 2023 Matera Italy (2023). https://ceur-ws.org/Vol-3633/paper14.pdf [30] Z. Zheng, Y.-C. Zhou, K.-Y. Chen, X.-Z. Lu, Z.-T. She, J.-R. Lin, A text classification-based approach for evaluating and enhancing the machine interpretability of building codes, Eng. Appl. Artif. Intell. 127 (2024) 107207. https://doi.org/10.1016/j.engappai.2023.107207 20

[31] S. Iranmanesh, H. Saadany, E. Vakaj, LLM-assisted graph-RAG information extraction from IFC data, in: Proceedings of the 2025 European Conference on Computing in Construction, Porto, Portugal, 2025: pp. 263–270. https://doi.org/10.35490/EC3.2025.366 [32] X. Xue, J. Zhang, Y. Chen, Question-answering framework for building codes using finetuned and distilled pre-trained transformer models, Autom. Constr. 168 (2024) 105730. https: //doi.org/10.1016/j.autcon.2024.105730 [33] B. Zhong, W. He, Z. Huang, P.E.D. Love, J. Tang, H. Luo, A building regulation question answering system: a deep learning methodology, Adv. Eng. Inform. 46 (2020) 101195. https: //doi.org/10.1016/j.aei.2020.101195 [34] H. Ying, R. Sacks, From automatic to autonomous: a large language model- driven approach for generic building compliance checking, Proc. 41st Int. Conf. CIB W78 Marrakech Moroc. 2-3 Oct. ISSN 2706-6568 ISSN 2706-6568 (2024). http://itc.scix.net/paper/w78-2024-59 [35] L. Ouyang, J. Wu, X. Jiang, D. Almeida, C.L. Wainwright, P. Mishkin, C. Zhang, S. Agarwal, K. Slama, A. Ray, J. Schulman, J. Hilton, F. Kelton, L. Miller, M. Simens, A. Askell, P. Welinder, P. Christiano, J. Leike, R. Lowe, Training language models to follow instructions with human feedback, (2022). https://doi.org/10.48550/arXiv.2203.02155 [36] Y. Zhai, H. Zhang, Y. Lei, Y. Yu, K. Xu, D. Feng, B. Ding, H. Wang, Uncertainty-penalized reinforcement learning from human feedback with diverse reward LoRA ensembles, (2023). https://doi.org/10.48550/arXiv.2401.00243 [37] D. Guo, D. Yang, H. Zhang, J. Song, P. Wang, Q. Zhu, R. Xu, R. Zhang, S. Ma, X. Bi, X. Zhang, X. Yu, Y. Wu, Z.F. Wu, Z. Gou, Z. Shao, Z. Li, Z. Gao, A. Liu, B. Xue, B. Wang, B. Wu, B. Feng, C. Lu, C. Zhao, C. Deng, C. Ruan, D. Dai, D. Chen, D. Ji, E. Li, F. Lin, F. Dai, F. Luo, G. Hao, G. Chen, G. Li, H. Zhang, H. Xu, H. Ding, H. Gao, H. Qu, H. Li, J. Guo, J. Li, J. Chen, J. Yuan, J. Tu, J. Qiu, J. Li, J.L. Cai, J. Ni, J. Liang, J. Chen, K. Dong, K. Hu, K. You, K. Gao, K. Guan, K. Huang, K. Yu, L. Wang, L. Zhang, L. Zhao, L. Wang, L. Zhang, L. Xu, L. Xia, M. Zhang, M. Zhang, M. Tang, M. Zhou, M. Li, M. Wang, M. Li, N. Tian, P. Huang, P. Zhang, Q. Wang, Q. Chen, Q. Du, R. Ge, R. Zhang, R. Pan, R. Wang, R.J. Chen, R.L. Jin, R. Chen, S. Lu, S. Zhou, S. Chen, S. Ye, S. Wang, S. Yu, S. Zhou, S. Pan, S.S. Li, S. Zhou, S. Wu, T. Yun, T. Pei, T. Sun, T. Wang, W. Zeng, W. Liu, W. Liang, W. Gao, W. Yu, W. Zhang, W.L. Xiao, W. An, X. Liu, X. Wang, X. Chen, X. Nie, X. Cheng, X. Liu, X. Xie, X. Liu, X. Yang, X. Li, X. Su, X. Lin, X.Q. Li, X. Jin, X. Shen, X. Chen, X. Sun, X. Wang, X. Song, X. Zhou, X. Wang, X. Shan, Y.K. Li, Y.Q. Wang, Y.X. Wei, Y. Zhang, Y. Xu, Y. Li, Y. Zhao, Y. Sun, Y. Wang, Y. Yu, Y. Zhang, Y. Shi, Y. Xiong, Y. He, Y. Piao, Y. Wang, Y. Tan, Y. Ma, Y. Liu, Y. Guo, Y. Ou, Y. Wang, Y. Gong, Y. Zou, Y. He, Y. Xiong, Y. Luo, Y. You, Y. Liu, Y. Zhou, Y.X. Zhu, Y. Huang, Y. Li, Y. Zheng, Y. Zhu, Y. Ma, Y. Tang, Y. Zha, Y. Yan, Z.Z. Ren, Z. Ren, Z. Sha, Z. Fu, Z. Xu, Z. Xie, Z. Zhang, Z. Hao, Z. Ma, Z. Yan, Z. Wu, Z. Gu, Z. Zhu, Z. Liu, Z. Li, Z. Xie, Z. Song, Z. Pan, Z. Huang, Z. Xu, Z. Zhang, Z. Zhang, DeepSeek-R1 incentivizes reasoning in LLMs through reinforcement learning, Nature 645 (2025) 633–638. https://doi.org/10.1038/s41586-025-09422-z [38] Y. Labrak, A. Bazoge, E. Morin, P.-A. Gourraud, M. Rouvier, R. Dufour, BioMistral: a collection of open-source pretrained large language models for medical domains, (2024). https://doi.org/10.48550/arXiv.2402.10373 [39] B. Lefort, E. Benhamou, J.-J. Ohana, D. Saltiel, B. Guez, Optimizing performance: how compact models match or exceed GPT’s classification capabilities through fine-tuning, (2024). https://doi.org/10.48550/arXiv.2409.11408 [40] Y. Lai, J. Zhong, M. Li, S. Zhao, X. Yang, Med-R1: reinforcement learning for generalizable medical reasoning in vision-language models, (2025). https://doi.org/10.48550/arXiv. 2503.13939 [41] A.P. Gema, A. Hägele, R. Chen, A. Arditi, J. Goldman-Wetzler, K. Fraser-Taliente, H. Sleight, L. Petrini, J. Michael, B. Alex, P. Minervini, Y. Chen, J. Benton, E. Perez, Inverse scaling in test-time compute, (2025). https://doi.org/10.48550/arXiv.2507.14417 21

[42] R. Zhang, N. El-Gohary, Clustering-based approach for building code computability analysis, J. Comput. Civ. Eng. 35 (2021) 04021021. https://doi.org/10.1061/(ASCE)CP. 1943-5487.0000967 [43] X. Xue, J. Zhang, Regulatory information transformation ruleset expansion to support automated building code compliance checking, Autom. Constr. 138 (2022) 104230. https://doi.org/ 10.1016/j.autcon.2022.104230 [44] N.N. Minh, A. Baker, C. Neo, A.G. Roush, A. Kirsch, R. Shwartz-Ziv, Turning up the heat: min-p sampling for creative and coherent LLM outputs, in: 2024. https://openreview.net/ forum?id=FBkpCyujtS (accessed January 26, 2026). [45] M. Uhm, J. Kim, S. Ahn, H. Jeong, H. Kim, Effectiveness of retrieval augmented generationbased large language models for generating construction safety information, Autom. Constr. 170 (2025) 105926. https://doi.org/10.1016/j.autcon.2024.105926 [46] J.W.L. Shi, M. Dang, W. Solihin, J.K.W. Yeoh, LLM attribution analysis across different finetuning strategies and model scales for automated code compliance, in: The 21st International Conference on Computing in Civil and Building Engineering (ICCCBE 2026), Taipei, Taiwan, 2026. https://doi.org/10.48550/arXiv.2604.15589

22

Related documents

• Experimental Settings in LLM-Based Program Repair: A Study of Inputs, Tool Access, Feedback, and Validation#965480
• A11yLTLNav: Automatic Detection of Accessibility Navigation Failures#965481
• Detecting Argument-Swap Bugs Using Context-Enhanced Code Representations#965482
• A Large-Scale Empirical Study of Quality Assurance Practices and Gaps in AI Agents#965483
• CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts#965484