Measuring Rework with Traceable Design-Change Records: A Protocol for Audit-Friendly Quantification in Construction and Related Process Workflows

1. Introduction and research question

Rework is usually reported as an effect: extra cost, extra time, missed productivity, or a defect that must be corrected. That framing is useful for project accounting, but it is weak for causal diagnosis because it does not preserve the sequence of design changes and workflow reversals that generated the effect. When the object of analysis is a bridge project, or any other engineered process with formal approvals and digital records, the more informative unit is not the final overrun alone but the traceable episode in which a design instruction, construction action, verification result, and corrective return can be linked to the same deviation. The present manuscript asks a narrower question: how can rework be measured from auditable design-change records in a way that is explicit enough for operational use, comparable across projects, and compatible with BIM-linked project controls? [1]

The evidence scope is a targeted narrative synthesis rather than a systematic review. It uses one application source on bridge-project rework with BIM and earned value management, together with transferable methodological foundations from workflow logging, digital-twin integration, and hierarchical record structures. The purpose is not to claim empirical superiority, but to define a measurement protocol that can be tested against established indicators. The literature used here supports three premises: first, bridge rework can be evaluated through cost and schedule indicators derived from BIM and EVM; second, digital systems can preserve state histories, timestamps, permissions, and costs; and third, structured hierarchical records can bind observations, semantics, and rules into a computable audit trail. These premises are sufficient to define a new measurement protocol without extending beyond the supplied evidence. [1] [2] [3] [4]

2. Prior methods and their limitations for rework measurement

The bridge-project study using BIM and EVM is the closest prior method in scope. It operationalized rework through ratios and performance indicators tied to cost and time, including a rework cost ratio, a rework time ratio, and rework-impact indices derived from CPI and SPI. That approach is useful because it connects rework to project controls and allows comparison between BIM-enabled and non-BIM projects. Its limitation for traceability is that the metric set remains aggregate: the indicators report how much rework occurred, but not the recorded chain of design-change decisions that produced each episode. The study also treated interviews and case comparisons as its method, which is appropriate for project-level assessment but insufficient if the aim is to audit rework at the level of individual state transitions. [1]

A second foundation comes from workflow platforms that record status changes, timestamps, associated costs, and user roles. In the DIVA platform, each design and project has a history log, workflow state changes can be timestamped and costed, and failed or abandoned states are explicit parts of the process grammar. This is methodologically important because it shows that the measurement of a complex process depends on preserving transitions, not only endpoints. A related contribution from digital-twin research shows how high-resolution sensor and model data can be integrated into a continuously updated virtual environment for scenario testing. A third foundation comes from hierarchical evidence structures in the indoor-inspection framework, which bind geometric measurements, semantic labels, image observations, and rules into a SceneState-like object. For rework measurement, the transferable lesson is that a record should not be a flat log line alone; it should carry enough structure to link the change request, the affected design entity, the verification result, and the resulting corrective action. [2] [3] [4]

The conflict across these methods is not about whether digital systems help, but about what they measure. EVM summarizes performance loss, BIM can expose coordination problems before execution, and workflow platforms preserve traceable histories. None of these alone defines a rework episode in a way that is both operational and auditable. The proposed protocol therefore combines the strengths of these approaches: an episode-level definition from the workflow record, a project-level comparator from EVM/BIM, and a hierarchical record structure for evidence attachment. [1] [2] [4]

3. Conceptual definition of rework and analytic scope

For this protocol, rework is defined as a recorded corrective process that occurs after an initial release of a design, construction task, or verification step, and that requires return to a prior state or replacement of a completed component because the original output no longer satisfies the approved specification. The definition excludes ordinary planned iteration before release and excludes design development that is still within the normal approval cycle. It includes only those episodes in which the workflow log shows that a task was accepted, moved forward, and then reopened, re-issued, or corrected because of a discrepancy, omission, clash, infeasibility, nonconformance, or failed verification. This operational distinction matters because many construction records mix ordinary iteration with genuine rework. [1] [2]

The analytic scope includes design-change records, workflow events, approval metadata, versioned artifacts, and time/cost annotations. In bridge projects, these records may arise from model revisions, drawing updates, clash corrections, fabrication revisions, site instructions, or verification failures. In other process domains, analogous records may be version updates, rejected outputs, failed verification steps, or re-issued tasks. The protocol is therefore domain-sensitive in its examples but domain-general in its record logic. It is intended for organizations that already maintain digital logs or can impose a minimal logging standard on top of existing BIM, project management, or document control systems. [1] [2] [3]

4. Proposed record architecture and variables

The core unit is the change episode. Each episode should be represented by a hierarchical record with five linked elements: record identity, affected object, transition history, justification, and resource burden. Record identity contains a unique episode ID, project ID, and version lineage. Affected object identifies the design package, drawing, model element, or work package that changed. Transition history stores the ordered states and timestamps, including canonical release, corrective-return and closure states; submission, review, execution and verification states are optional when the local system records them. Justification stores the coded reason for the change. Resource burden stores labor hours, machine time, procurement delay, and material waste attributable to the episode. If a system cannot attribute all burden categories, it should at least preserve the categories that are observable and flag missing ones explicitly. [2] [4]

The protocol uses the following variables. Let C be the set of candidate aggregated change episodes in a project after lineage normalization and rule-based aggregation. For each episode e in C, define: r(e) as a binary indicator of whether the episode qualifies as rework under the operational rule; c_obs(e) as the observed incremental direct cost attributable to the episode when a cost value is recorded under the project attribution rule; t_obs(e) as the observed incremental delay time attributable to the episode when a delay value is recorded; v(e) as the number of affected versioned objects; q_cls(e) as a binary classification-completeness indicator, where q_cls(e)=1 only if the episode contains the minimum fields required to apply the rework rule; q_cost(e) as a binary cost-observability indicator, where q_cost(e)=1 only if episode-level direct cost is documented; and q_time(e) as a binary time-observability indicator, where q_time(e)=1 only if episode-level delay time is documented. The minimum classification fields are: a lineage key, an ordered transition history with timestamps, a release-status field sufficient to determine whether the object had reached an approved or executed state, and the fields needed to establish a post-release corrective return; cause coding is additionally required for a cause-specific classification. Episodes with q_cls(e)=0 are excluded from rework classification and reported separately as unclassifiable candidates. Episodes with q_cls(e)=1 may be classified for incidence even when q_cost(e)=0 or q_time(e)=0; in that case their burden is treated as partially observed rather than zero. [2] [1]

5. Operational rule and algorithm for episode identification

The protocol uses one default operational rule. A logged change counts as rework if and only if all three conditions hold: first, the affected object had previously reached an approved, issued-for-execution, or executed state under the local workflow grammar; second, a later transition returned that same lineage to a prior stage or triggered corrective replacement of completed work; and third, the recorded cause belongs to a prespecified deviation code set. The default deviation code set has five top-level classes: nonconformance, design error or omission, coordination or interface conflict, failed verification or inspection, and execution error requiring corrective replacement. Free-text causes are admissible only after deterministic mapping to one of these classes by a written coding dictionary; if no unique mapping is possible, the cause is coded ambiguous and the episode is not classified as rework unless the governance plan specifies adjudication. In notation, r(e)=1 when approved-before(e)=1, backward-or-corrective-transition(e)=1, and deviation-code(e)=1; a corrective episode with an unresolved cause is labeled cause-unclassified rather than a proven non-rework revision; only fully observed negative conditions support r(e)=0. Sensitivity analysis may test narrower or broader code dictionaries, but the default dictionary must be frozen before evaluation. [1] [2]

The algorithm proceeds in seven steps. Step 1 ingests all state-change logs, version histories, approval records, and cost or time annotations from the participating systems. Step 2 normalizes identifiers so that all records referring to one design object or work package share a common lineage key. Step 3 forms candidate episodes by scanning each lineage in timestamp order and opening a new candidate when a post-release corrective signal first appears. A corrective signal is any backward workflow move, failed verification result, corrective site instruction, or replacement record linked to that lineage. Subsequent events are merged into the same candidate until the earliest of two closure conditions: an approved-as-final or closed state for that lineage, or a formal closure recorded for that episode; a different lineage is scanned independently and cannot close the first. Step 4 applies a prespecified root-cause equivalence rule within each candidate episode. Two events are treated as the same root-cause chain only if they share the same lineage key and either the same top-level deviation class or a parent-child pair within the coding dictionary; otherwise they begin separate overlapping candidates even if they are temporally adjacent. When planned revision and corrective revision both occur within one lineage, the episode is split at the first event coded as planned development after the last corrective event, so that one candidate cannot mix rework and non-rework segments. Step 5 orders the transitions within each candidate by timestamp and detects the backward or corrective condition in the workflow grammar. Step 6 applies the release-status and cause-code tests, then assigns one of three labels: rework, non-rework revision, or unclassifiable because the minimum classification fields are missing or ambiguous. Step 7 computes outputs on the final candidate set C with a fixed unit of analysis: episode counts and episode burdens use candidate aggregated episodes as the denominator unit, while package prevalence is reported separately as the proportion of work packages with at least one rework episode. The default aggregation rule is conservative: merge within a lineage until a formal closure condition occurs; a sensitivity analysis may compare this rule with a narrower window that also splits candidates after a prespecified idle interval. [2] [4]

A mathematical summary is as follows. Let C_cls={e in C : q_cls(e)=1} be the set of classifiable candidate episodes, and let R={e in C_cls : r(e)=1} be the set classified as rework. Episode-based rework incidence is |R|/|C_cls|. Work-package rework prevalence is the number of work packages with at least one episode in R divided by the total number of observed work packages; it is a different estimand and should not be substituted for incidence. Documented rework cost burden is the sum of c_obs(e) over e in R with q_cost(e)=1, and documented rework time burden is the sum of t_obs(e) over e in R with q_time(e)=1. Cost documentation coverage is the proportion of episodes in R with q_cost(e)=1, and time documentation coverage is the proportion with q_time(e)=1. Reports should present documented burden together with these coverage measures and the count of unclassifiable candidates |C|-|C_cls|. If organizations wish to derive a single monitored rate for management use, the default rule should be the episode-based incidence |R|/|C_cls|, while package prevalence remains a supplementary exposure measure. These are proposed operational measures, not validated results. Any alert threshold should be prespecified in the governance plan and checked in sensitivity analysis rather than treated as a general benchmark. [1] [2]

6. Comparator, outcome measures, and prospective validation design

The primary comparator is the conventional project-control approach used in the bridge study: rework ratios and EVM-based indicators computed at the project level. The proposed protocol should be evaluated against those measures rather than replacing them. The reason is methodological: aggregate indicators are useful for management, while traceable records are useful for diagnosis. A valid comparison would test whether the episode-based protocol reproduces the project-level direction of rework burden while offering finer resolution on where, when, and why the burden emerged. In addition, BIM-linked clash or coordination events can be used as a secondary comparator because they represent a pre-construction signal of later corrective work. [1]

The prospective evaluation should use bridge projects or bridge work packages that already maintain digital records capable of supporting the minimum classification fields. The sampling frame should be prespecified as all candidate episodes generated by the Step 3 aggregation rule within a fixed observation window, together with the associated work-package roster needed to compute package prevalence. The adjudication unit is the candidate aggregated episode, not the individual log line. The primary endpoint should be positive predictive value of the rework label against an adjudicated reference standard, because the protocol is intended first to distinguish rework from ordinary revision without inflating counts. Secondary endpoints should be sensitivity for rework detection, the proportion of candidates that are classifiable, cost and time documentation coverage among rework episodes, agreement in project or package ranking between episode-based burden measures and aggregate cost or schedule indicators, and the proportion of rework episodes linked to a specific design-change source. Ranking agreement should be assessed with Spearman rank correlation on a prespecified project-level or package-level burden measure. The adjudication procedure should be frozen before evaluation begins. Two reviewers should independently classify each candidate episode as rework, non-rework revision, or unclassifiable under the written rules and coding dictionary. If both reviewers agree, that label is final. If they disagree, they should record the specific rule item in dispute and submit the case to a third adjudicator, whose decision becomes the final reference label. Overlapping candidates created by distinct root-cause classes within one lineage should be adjudicated separately. If a candidate contains both planned revision and corrective revision because the log does not permit clean splitting, the reference standard should label it unclassifiable rather than force a binary decision. Rule revisions prompted by recurrent ambiguity may be drafted only after the evaluation set is closed and must be tested in a subsequent round rather than retroactively applied to the same set. [1] [2] [4]

The evaluation should also test whether the protocol is robust when records are incomplete. Missing timestamps, incomplete cost fields, and ambiguous cause codes are expected failure cases. If a project lacks verified closure events, the protocol should report rework as partially observable and separate measurable burden from estimated burden. That distinction prevents false certainty. A further validation step should examine whether the same episode is reconstructed consistently across BIM logs, document-control logs, and site instruction logs. If the episode cannot be linked across systems, the protocol should classify it as low-traceability rather than force a false match. [2] [4]

7. Failure cases and limits of generalization

The main failure case is semantic ambiguity. Some workflow systems treat any revision as a new version, even if the change was made before release and therefore does not constitute rework. Other systems merge correction and resubmission into one opaque state, which hides the backward transition needed for episode detection. A second failure case is under-logging of causes. If the reason for correction is left as free text or omitted, the rule may undercount genuine rework or overcount benign iteration. A third failure case is fragmented provenance, where different teams use separate identifiers for the same object, making lineage reconstruction uncertain. The protocol addresses these risks by requiring explicit lineage keys and mandatory cause coding, but it cannot repair missing institutional discipline after the fact. [2] [4]

Generalization is limited by process formality. The protocol is best suited to settings where approval states, version histories, and corrective actions are digitally recorded. It transfers well to construction, design-for-construction workflows, and other regulated production systems. It is less suitable for informal craft work or for projects in which changes are not logged at the level of individual objects. It also depends on local process definitions: one organization may classify a resubmitted model as an ordinary iteration, while another may classify the same event as rework if it occurs after contractual approval. For that reason, the protocol should be calibrated to the project’s governance rules before cross-project comparison is attempted. [2] [1]

8. Implications for bridge projects and transferable digital systems

In bridge projects, the proposed protocol adds a diagnostic layer to BIM-EVM analysis. The bridge study shows that BIM can be used to evaluate rework’s impact on time and cost, and that project performance can be summarized through rework ratios and schedule/cost indicators. The present protocol does not compete with that logic; it explains how those burdens may be assembled from auditable episodes. If implemented in a bridge project, the protocol would allow managers to answer a more specific question: which design-change records produced the rework, through which workflow states, and with what documented burden? That answer is valuable because corrective actions can then target the state transitions, approval delays, or coordination failures that recur across episodes. [1]

The transferable foundations are equally relevant outside construction. Workflow systems such as DIVA show that state histories, costs, permissions, and activity logs can be preserved at the design-object and project level. Digital-twin systems show that continuously updated data environments can support scenario analysis and operational feedback. Hierarchical record structures show that a traceable object can bind measurements, labels, rules, and observations without collapsing them into a single flat table. The protocol borrows from all three ideas but applies them to one specific measurement task: quantifying rework from recorded design-change history. That bounded contribution is narrower than a full digital twin and more granular than a simple project ratio. [2] [3] [4]

Episode identity, missing burdens and reference interpretation

Before scanning events, freeze a many-to-many object-to-work-package table. Assign every corrective chain a unique root episode ID; child events inherit that ID unless a documented independent cause opens a new root. Process equal timestamps by immutable event ID. A child correction is attached to its open root before any new episode is considered. Cross-package episodes count once in incidence and once for each affected package in package prevalence, while each documented cost item is assigned once by its immutable accounting ID. Pre-release events provide context but never contribute post-release rework burden. Unresolved lineage or conflicting parentage makes an episode unclassifiable. When the classifiable denominator, package roster or rework denominator is empty, the corresponding ratio is non-estimable. Documented burden is a partial total with coverage, not an imputed project total. Rank correlations use the same burden unit, observation window and minimum documentation coverage across projects; otherwise no pooled correlation is reported. Expert adjudication is an operational reference under these definitions, not external proof of a unique true rework count.

9. Conclusion

This manuscript established a conceptual measurement protocol for rework based on traceable design-change records. The protocol defines rework as a corrective episode that returns a released or executed object to a prior state because of deviation from the approved specification, and it provides an operational rule for classifying logged changes, a hierarchical record structure, project-level output measures, and a prospective evaluation design. Compared with conventional BIM-EVM indicators, the protocol is more explicit about episode formation and provenance, while still remaining compatible with aggregate project control. Compared with workflow logging platforms and digital-twin systems, it is narrower in scope but more focused on the measurement of corrective deviation. [1] [2] [3] [4]

What remains untested is empirical performance: the sensitivity and positive predictive value of the rule in real bridge projects, the reliability of manual adjudication under the proposed coding dictionary, the portability of the cause-code hierarchy across organizations, and the extent to which episode-level traceability improves managerial diagnosis beyond standard project controls. Those questions require prospective implementation in live projects. Until then, the contribution of this manuscript is a proposed precise and falsifiable measurement framework, not a claim of demonstrated superiority. [1] [2]

References

1. 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.
2. Plahar, Hector; Lane, Stephen D.; Stawski, Nina; Simirenko, Lisa; Tapaswi, Manjiri; Kuo, Rita; Goyal, Garima; Hillson, Nathan J.; et al. (2026). Vision and Development of a Design, Implementation, and Verification Automation (DIVA) Software Platform for DNA Construction. ACS Synthetic Biology. 15(8), 3498-3503. doi:10.1021/acssynbio.6c00197.
3. Mandal, Debayan; Zou, Lei; Wadhwa, Abhinav; Wilkho, Rohan Singh; Cai, Zhenhang; Zhou, Bing; Ye, Xinyue; Newman, Galen; et al. (2026). FlowsDT: A geospatial digital twin for navigating urban flood dynamics. Computers, Environment and Urban Systems. 126, 102414. doi:10.1016/j.compenvurbsys.2026.102414.
4. Jing, Zijian; Zhu, Liyi; Chen, Tianyi; Hovestadt, Ludger; Li, Li (2026). Vision-Based Digital Twin and AI Agent Framework for Low-Cost, Explainable Indoor Building Inspection and Safety Assessment. Sensors. 26(15), 4992. doi:10.3390/s26154992.