Abstract
Construction cost models are often developed within a narrow project set and then applied to projects that differ in delivery method, work scope, material choices, or organizational practice. This creates a validation problem: a model may appear accurate within its development sample while failing when transferred to another project class. This protocol proposes a cross-project validation framework for construction cost estimates that treats transferability as an empirical question with explicit operational rules. The framework uses a targeted narrative synthesis of direct construction cost evidence and methodological foundations from adjacent studies. Cost drivers are represented as project-level, stage-specific, and process-level variables; the validation target is not only point prediction error but also calibration, ranking stability, and uncertainty coverage under leave-project-out evaluation. The protocol defines a transferability score based on feature overlap, context distance, and residual drift, and it specifies a decision sequence for accepting, recalibrating, or rejecting a source model for a new project class. Search-guided ensembles with prediction intervals provide the estimation core, while Bayesian-network logic and structural equation modeling inform assumptions about uncertain causal transport and latent construct comparability. The protocol is intended for prospective testing across project portfolios rather than retrospective performance claims. Its main contribution is a reproducible methodology for determining when a cost estimate remains valid outside the project context in which it was trained, and what form of recalibration is justified when it does not.
1. Introduction and research question
Construction cost estimation is often treated as a prediction task, yet in practice it is also a transport problem: a model built from one project set must be judged against another set with different design density, material inputs, procurement patterns, and execution constraints. This protocol addresses the question: under what conditions can a construction cost model estimated in one project context be used in another without losing calibration, interpretability, or decision value? The question is narrower than broad cost-forecasting research because it focuses on validation across project boundaries rather than on model discovery alone. It is also narrower than a systematic review, because the aim is to define a testable validation procedure, not to enumerate the literature exhaustively.
The rationale for this protocol can be stated without treating the cited studies as direct evidence of cross-project transfer. Construction cost estimation remains difficult because nonlinear dependencies, heterogeneous data distributions, and parameter uncertainty can limit the reliability of traditional approaches within a given modeling setting, and search-guided ensembles have been proposed to combine prediction accuracy, interpretability, and prediction intervals in one framework. Separate studies also show that cost outcomes are associated with process variables such as material waste across processing stages, rework in bridge delivery, and construction-maintenance design assumptions in pavements. Taken together, these studies motivate a prospective validation protocol in which cross-project transport is tested directly rather than presumed from within-context performance. [1] [2] [3] [4]
2. Evidence scope and synthesis logic
The evidence scope is a targeted narrative synthesis of six supplied studies, selected for direct relevance to construction cost estimation or for methodological transfer to validation design. The construction-specific evidence concerns cost estimation itself, comparative construction-and-maintenance costs, bridge-project cost performance related to BIM and rework, and cost overruns associated with waste drivers. The transferable methodological evidence concerns Bayesian networks for uncertainty scenarios and SEM for testing relations among latent implementation constructs [Chen et al., Pradeep et al., Elseufy et al., Kamal et al., Albtoush et al., Alsehaimi et al.]. This is not a claim that these studies are methodologically identical; rather, they contribute distinct pieces needed to define a cross-project validation protocol. [1] [4] [3] [2] [5] [6]
The synthesis supports two bounded claims for this manuscript. First, validation should not rely only on aggregate fit within the development class, because strong within-class performance does not by itself establish transport to a different class; here that concern is treated as a hypothesis to be tested prospectively, not as a settled result from any one cited study. Second, cross-project validation should distinguish predictors that were useful in a particular dataset from predictors that remain stable after transfer. For example, the cited cost-estimation study reports Formwork, Tributary Area, and Concrete as influential features in its own modeling setting, while the waste study reports the strongest association between cost overrun and the handling, storage, and transportation phase in the examined setting. These findings justify explicit transfer tests, but they do not demonstrate transportability across project classes on their own. [1] [2]
3. Conceptual model and variable definitions
The proposed validation unit is a project p nested in a source project class s and a target project class t. A project class is defined by a combination of project type, procurement regime, delivery method, scale band, and dominant material system. The source model is any estimation model trained on class s and applied to class t. The protocol distinguishes four variable groups. First, cost outcome variables: total direct cost, unit cost, cost overrun ratio, and maintenance-adjusted life-cycle cost. Second, structural predictors: gross floor area, span length, lane length, volume, or other design quantities relevant to the project class. Third, process predictors: rework intensity, waste intensity, procurement delay, change-order density, and maintenance interval. Fourth, context variables: climate exposure, regulatory setting, labor market tightness, and BIM/digital maturity. [1] [3] [4] [2] [6]
The protocol uses one default acceptance rule and two auxiliary diagnostics. Default rule: fix one common outcome definition before analysis; convert all monetary values to the same price basis and currency basis; aggregate any repeated records within a project to one project-level observed outcome and one project-level prediction by the preregistered aggregation operator, with the default selecting the final registered forecast at the common project stage and the unique final project cost; exact duplicate records are deduplicated by ID; then compute one absolute percentage error per project. Let the source reference error be the median of project-level absolute percentage errors from leave-project-out validation within the source class, and let the target error be the median of project-level absolute percentage errors in the target class under the frozen source model. Reject direct transport if the target median exceeds the source median by more than Δ. The default preregistered value is Δ = 0.05 in absolute proportion terms; sensitivity analyses should repeat the rule for Δ in {0.03, 0.07, 0.10}. Confidence intervals for the error difference should be obtained by bootstrapping projects, not records; if projects contain clustered repeated measures, resample whole projects with all attached records preserved. The point difference governs the registered deployment rule; the bootstrap interval communicates uncertainty and does not replace it with a different post hoc gate. An underpowered target class is indeterminate under its registered minimum sample criterion. Auxiliary diagnostic 1: direction instability is assessed by the effect summary available for the chosen model class. For parametric models, use signed standardized coefficients; for nonparametric models, use a preregistered signed monotone partial-effect summary computed over the common support of the predictor. A predictor is flagged as direction-unstable only when the same effect summary is estimable in both classes under the same specification, both summaries lie outside a near-zero exclusion zone of ±0.05 on the standardized scale, and their signs differ. Auxiliary diagnostic 2: uncertainty calibration is accepted only when empirical prediction-interval coverage for a preregistered nominal level differs from nominal by no more than 0.05; the default nominal level is 0.90, with sensitivity checks at 0.80 and 0.95.
The protocol also defines a bounded transportability score T as a decision aid. Let O denote feature-overlap proportion, C denote context similarity, and G denote residual stability. Define O = |S∩S'|/|S∪S'|, where S and S' are the usable predictor sets in the source and target classes after preprocessing and missing-data rules are fixed. Define C = 1 - D_C, where D_C is the average normalized absolute difference across preregistered context variables after each variable is scaled to the unit interval by fixed engineering bounds or portfolio-wide minima and maxima; if a context variable is binary, its contribution is 0 for a match and 1 for a mismatch. Define G = max{0, 1 - min(1, |MedAE_t - MedAE_s|/(MedAE_s + ε))}, where MedAE_s and MedAE_t are source and target project-level median absolute errors on the same outcome scale and ε is a small positive constant fixed before analysis. If the target class is too small to estimate MedAE_t with a preregistered minimum number of projects, the default rule is to withhold T-based acceptance and classify the transport decision as indeterminate pending more target projects; sensitivity analysis may report T using a shrinkage estimate of MedAE_t toward the pooled portfolio median, but that estimate should not govern the primary accept-reject decision. Then T = 0.4O + 0.3C + 0.3G, so T is constrained to [0,1]. The default decision rule is: accept direct transport when T ≥ 0.75 and the default error and calibration criteria are also met; attempt recalibration when 0.50 ≤ T < 0.75; reject transport and rebuild or pool models when T < 0.50. Sensitivity analysis may vary the weights within ±0.10 while preserving a sum of 1.
4. Proposed methodology for cross-project validation
The proposed methodology proceeds in five steps. Step 1, define project classes before any model fitting by explicit rules on project type, procurement regime, delivery method, scale band, and dominant material system. Step 2, estimate a source-class cost model. The default estimation core is a search-guided regression ensemble that selects and combines candidate learners within the source class and outputs both point predictions and calibrated prediction intervals; alternative source learners may be examined in sensitivity analysis, but the validation protocol remains unchanged. Step 3, estimate source performance by leave-project-out validation, with all records from a held-out project excluded together, and then apply the frozen source model to each target class with no parameter updating. Step 4, if direct transport fails but the transportability score indicates moderate overlap, perform staged recalibration in a fixed order: intercept correction first, intercept-plus-slope correction second, and interval-width rescaling third. Recalibration must be estimated on a target-class adaptation subset that is distinct from the final target-class evaluation subset; the same target projects cannot be used both to choose the recalibration stage and to claim its success. Step 5, accept the transported model only if the preregistered error, calibration, and ranking criteria are satisfied on the held-out target evaluation subset after the earliest successful stage; otherwise reject transport for that target class. [1]
The comparator is a structured set of alternatives: a naive mean predictor, a class-specific linear baseline, the source model without recalibration, and the source model with staged recalibration. This design helps localize the source of failure. The pavement study shows that cost assessments vary with traffic level, design configuration, materials, and maintenance assumptions within a unified analytical framework, so a specification developed for one band should not be presumed valid for another without testing. The bridge rework study reports context-dependent gains in a BIM-associated setting, which this manuscript interprets as a reason to examine whether process differences alter transferred cost relations rather than to assume they do so in every target class. [4] [3]
The primary outcome measures are mean absolute error, median absolute percentage error, interval coverage probability, interval width, rank correlation between predicted and observed project ordering, and calibration slope. Secondary outcomes are decision classification accuracy for under-budget versus over-budget projects and the stability of feature importance across source and target classes. These outcomes are chosen because a model used in cross-project settings must support budgeting, risk screening, and priority setting; point accuracy alone is insufficient for that purpose. [1] [3]
5. Assumptions, causal transport, and construct comparability
Cross-project validation requires assumptions about which mechanisms can move across settings. The protocol adopts three. Assumption A1: some cost drivers are structurally stable, meaning their effect is preserved after scaling for project size and scope. Assumption A2: some drivers are context-conditioned, meaning their effect depends on institutional or delivery conditions. Assumption A3: some latent constructs are only comparable after measurement alignment. These assumptions are consistent with the methodological division between predictive modeling, causal scenario analysis, and latent-construct testing in the supplied studies [Albtoush et al., Alsehaimi et al.]. [5] [6]
Bayesian-network reasoning is useful here because it formalizes uncertain cross-project transport as scenario-dependent belief updating rather than as a fixed universal law. In the cited BN framework, expert beliefs are pooled to represent how technologies may affect time-cost risk under different conditions, and the result is explicitly treated as scenario-based rather than empirically measured [Albtoush et al.]. The present protocol borrows this logic by treating transferability as conditional on measurable context nodes such as labor reliability, digital maturity, and procurement structure. SEM is useful for a different reason: it allows the analyst to test whether latent cost-related constructs, such as waste pressure or rework pressure, remain comparable across project classes [Alsehaimi et al.]. [5] [6]
This distinction matters because cost-estimation evidence often combines direct quantities with process effects that may be represented as latent constructs. The waste-driver SEM study links multiple material-processing phases to project cost overrun and reports the strongest association for handling, storage, and transportation in the examined setting. That result does not establish a universal ranking of waste phases across construction domains. In this protocol it serves a narrower purpose: if variables such as waste pressure or rework pressure are modeled as latent constructs, cross-project validation should test their measurement comparability before coefficient comparisons are interpreted as evidence of transport or non-transport. [2]
6. Validation design, failure cases, and limits of generalization
The prospective validation design is a portfolio study in which at least two project classes are defined in advance, one serving as the source class and one or more as targets. Within each class, projects are split by project identity rather than by random records, because leakage across records from the same project would inflate validity. The source model is trained only on source-class projects. It is then applied to each target class without re-estimation, followed by a staged recalibration test. Statistical comparison should use paired project-level errors where matching is possible, and distributional tests where only class-level summaries are available.
Failure case 1 occurs when target projects differ so strongly that feature overlap is too small for meaningful transport. Failure case 2 occurs when residual drift is large despite acceptable in-sample fit, implying that the source model has learned project-class idiosyncrasies rather than transferable cost structure. Failure case 3 occurs when the model predicts average cost well but fails on extremes, which is a serious problem for budgets because overruns often matter most in tail cases. Failure case 4 occurs when the direction of a process effect changes, as may happen if rework reduction through BIM offsets one set of costs while introducing coordination overhead in another setting. The bridge BIM evidence shows why such tradeoffs must be considered rather than assumed away [Elseufy et al.]. [3]
Generalization is limited by the fact that construction cost is jointly shaped by design, process, market, and governance factors. Pavement evidence shows that even within a single infrastructure domain, cost depends on traffic class, material substitution, and maintenance horizon [Pradeep et al.]. Waste-driver evidence shows that cost overrun is tied to stage-specific material processing rather than to waste as a monolithic variable [Kamal et al.]. Therefore, the protocol does not claim that one cross-project model can serve all construction domains; it claims only that transfer can be tested under explicit and comparable conditions. [4] [2]
7. Relation to prior methods and methodological contribution
The proposal differs from the search-guided regression ensemble in that it treats uncertainty and interpretability as necessary but insufficient for transport. The ensemble framework provides an estimation core with dynamic learner selection and prediction intervals, which is suitable for source-class modeling [Chen et al.]. The present protocol adds a cross-class validation layer that asks whether the ensemble remains calibrated when the project context changes. This is a different question from whether the ensemble is accurate in one dataset. [1]
The proposal differs from the BIM barrier SEM framework in that it does not model adoption success as a latent outcome of implementation barriers; instead, it uses SEM only as a diagnostic tool for checking whether latent cost-process constructs are comparable across classes [Alsehaimi et al.]. It also differs from the Bayesian-network framework in that it does not infer hypothetical technology impacts from expert beliefs; instead, it uses the BN logic to represent conditional uncertainty about transport conditions [Albtoush et al.]. In short, the protocol combines predictive validation, construct invariance testing, and scenario logic in one sequence, but it does not collapse them into a single model class. [6] [5]
Its substantive contribution is bounded: it specifies how to decide whether a cost estimator built in one project context can be accepted, recalibrated, or rejected in another. That contribution is useful for infrastructure agencies, contractors, and researchers who need to compare models across portfolios without assuming that historical accuracy automatically implies future portability. The protocol is therefore a decision framework for cross-project validation rather than a claim that any particular estimator is universally transferable.
Common estimand and transport rejection rule
The primary target is final project cost in one registered price-year currency and one fixed cost-accounting scope, measured at the same project stage. Collapse repeated forecasts to the preregistered stage-specific forecast per project before computing absolute percentage error; projects with zero or noncomparable realized cost have non-estimable APE and are reported separately. Harmonize predictor units, coding, categorical reference levels and missingness rules before any transport comparison. Reject unchanged deployment when target-domain median APE minus source-validation median APE exceeds a positive preregistered degradation margin Delta. An improvement does not trigger that rejection. Recalibration is a separately trained candidate evaluated on a fresh target test partition under its own frozen acceptance margin; the same observations cannot select and certify it. Common-support diagnostics require a preregistered minimum number of independent projects; insufficient support yields an unavailable transport judgment and explicit coverage counts. Partial-effect differences are exploratory diagnostics, not causal effects or rejection gates without adequate support. Missing accounting scope cannot be repaired by forcing records onto a common numerical scale.
8. Conclusion
Conceptually, this manuscript treats cross-project validation of construction cost estimates as a distinct methodological problem from ordinary model fitting. The synthesis supports three bounded propositions for prospective testing: cost estimation is sensitive to modeling context; process variables such as rework and material-waste stages are associated with cost outcomes in particular studied settings; and uncertainty-aware estimators remain in need of explicit transfer tests before they are used outside the data context in which they were developed. [1] [3] [2]
What remains untested is the protocol itself. No empirical dataset has yet been used here to estimate the transferability score, calibrate the acceptance thresholds, or compare the proposed sequence against alternative validation rules. The next step is a prospective portfolio study with predeclared project classes, held-out target validation, and explicit recalibration rules. Until that testing is completed, the protocol should be read as a precise and falsifiable plan for evaluating when construction cost estimates remain valid across project contexts, and when they do not.
Contribution and availability
This protocol defines cross-project validation as a distinct problem in construction cost estimation and proposes a reproducible sequence for testing transportability, calibration, and construct comparability across project classes. It integrates search-guided estimation, Bayesian scenario logic, and SEM-based invariance diagnostics into a single decision framework, while keeping empirical claims unmade until prospective validation is performed.
Funding: Roman Vlasov’s own funds. Editorial responsibility and competing interests: Roman Vlasov is the founder and Editor-in-Chief of Smart World Journal and the creator of the BILDRY construction-planning platform. Other competing interests have not been declared.
This conceptual study reports no newly collected empirical data. Its proposed procedures require the prospective validation described above.
References
- Chen, Lifei; Lim, Zhi Min; Lim, Wei Hong; Tiang, Sew Sun; Sharma, Abhishek; Syamsunur, Deprizon; Alharbi, Amal H.; Eid, Marwa E.; et al. (2026). Search-guided regression ensembles for accurate, interpretable, and uncertainty-aware construction cost estimation. Scientific Reports. 16(1), 21456. doi:10.1038/s41598-026-51706-5.
- Kamal, Lobna; Yamany, Mohamed S.; Hosny, Hossam E. (2026). Assessing the impact of construction material waste drivers on project cost overrun across material processing stages: a structural equation modeling approach. Scientific Reports. 16(1), 28364. doi:10.1038/s41598-026-63008-x.
- Elseufy, Sara M.; Hussein, Ayman; Badawy, Mohamed (2026). A comprehensive framework for evaluating bridge project rework through earned value management (EVM) and building information modeling (BIM). Scientific Reports. 16(1), 7197. doi:10.1038/s41598-025-27546-0.
- Pradeep, B.; Lavanya, N.; Archana, M. R.; Basutkar, S. M.; Anjaneyappa, V. (2026). Energy and carbon estimation in construction and maintenance of pavements using conventional and alternative materials: a comparative analysis. Scientific Reports. 16(1), 25753. doi:10.1038/s41598-026-55867-1.
- Albtoush, Faten; Al-Btoosh, Ja’far A. Aldiabat; Rawashdeh, Taiseer Mustafa; Al-Btoush, Mohammed A. K. A. (2026). Assessing the impact of AI-enabled BIM digital twins on construction risks: a Bayesian Network of Jordanian expert beliefs. Frontiers in Artificial Intelligence. 9, 1846388. doi:10.3389/frai.2026.1846388.
- Alsehaimi, Abdullah; Ghani, Muhammad Usman; Baarimah, Abdullah O.; Alawag, Aawag Moshen; Ramu, Madhusudhan Bangalore (2026). Mitigating obstructions to attain successful application and implementation of building information modeling (BIM) in residential construction projects’ lifecycle. Scientific Reports. 16(1), 12389. doi:10.1038/s41598-026-43261-w.