An engineering cost scope equivalent request sharing and node security cancellation method

Abstract

The application relates to electronic data processing of engineering cost, and discloses a method for sharing and canceling nodes in the scope of engineering cost equivalence request. A processor parses a candidate variable into a normalized scope semantic tuple containing a project version, a hierarchical node range, a source field path, filtering, aggregation, transformation, a unit of measurement and precision, to request a summary to locate a sharing bucket, and compare complete tuples in the bucket, and only merge requests that are completely equivalent in semantics, have certainty and have no external side effects. A shared node maintains a node generation number and an active candidate reference set; when a candidate is canceled, only the reference is removed; only when the reference is empty, the node is to be executed and the generation numbers match, the node is canceled. A node executes a snapshot of an immutable variable once, writes a barrier to prevent distribution to canceled candidates, and invalidates affected nodes according to a change set, so that range missharing, cross-candidate cancellation interference and old snapshot reuse are avoided.

Description

Technical Field

[0001] This invention relates to the fields of electronic data processing for engineering cost, hierarchical object scope encoding, variable request equivalence determination, shared computation graph, and concurrent task state control. Specifically, it relates to a method in which a processor parses variable identifiers in candidate computation tasks into engineering cost hierarchical node scopes and field processing semantics, generates normalized scope semantic tuples, locates shared buckets using request digests and performs complete semantic comparisons, establishes shared computation nodes only for completely equivalent, deterministic variable requests without external side effects, and controls the lifecycle of shared nodes through node generation numbers, active candidate reference sets, atomic state transitions, write barriers, and local change failures. Background Technology

[0002] Electronic cost data for construction projects typically consists of hierarchical objects such as projects, individual projects, unit projects, sub-projects, bill of quantities items, quotas or consumption quantities, and labor, materials, and machinery. Multiple candidate calculation tasks may simultaneously read the same field path, but the actual required unit project scope, bill of quantities set, filtering predicates, aggregation methods, units of measurement, and numerical precision are not the same; it is also possible that completely identical quantities, comprehensive unit prices, or aggregation results may be reused among different candidates.

[0003] If the system identifies duplicate calculations solely based on variable names, expression text, or source field paths, it is prone to incorrectly merging requests with the same path but different unit project scopes, or requests with the same scope but different filtering and aggregation semantics. If no data is shared at all, it will repeatedly read, convert, and aggregate large amounts of project list data. When a shared computing node is referenced by multiple candidate computing tasks, the rejection or cancellation of one candidate cannot directly terminate a node still needed by other candidates. When candidate references are attached, removed, and node startups occur concurrently, erroneous cancellations, old generation writes, or write results to canceled candidates may also occur.

[0004] Existing engineering cost data processing solutions mainly focus on matching bills of quantities with quotas, matching historical projects, and constructing or recommending cost indicators, but they still struggle to solve the following problems simultaneously:

[0005] When summary nodes and computable leaf nodes are mixed together, and the scope of the project object is not standardized, there may be duplicate aggregation of amounts or inconsistent scope boundaries.

[0006] Using variable names, expression text, field paths, or request summaries as the basis for sharing cannot prove that the requests are completely equivalent in terms of scope, filtering, aggregation, units, and precision of the project objects.

[0007] When the variable computation chain contains random calls, unversioned external state, or external write side effects, duplicate requests cannot be safely shared.

[0008] When candidate references are attached, removed, and shared nodes are started concurrently, the lack of node generation number and atomic state conditions may result in old references canceling new nodes or active references still existing while nodes are canceled.

[0009] When project data, variable mappings, or parameters undergo local changes, the lack of local failure and cross-version reuse rules based on full read dependencies may lead to the reuse of old snapshots or cause all caches to fail indiscriminately.

[0010] Only the result value or request summary is saved; it cannot be replayed or used to locate mis-shared, erroneous canceled, old generation writes, or cache invalidation boundaries. Summary of the Invention

[0011] I. Technical problems to be solved

[0012] This invention aims to provide a method for sharing equivalence requests and safely canceling nodes in the scope of engineering cost. It constructs a single processing chain by defining the scope of engineering cost level nodes, field processing semantics, complete equivalence determination, and concurrent state control of shared nodes. This reduces redundant reading and calculation while avoiding erroneous sharing between different engineering scopes, erroneous merging of summary collisions, the cancellation of one candidate affecting other candidates, writing of intergenerational results of old nodes, and reuse of invalid snapshots after local changes in the project.

[0013] II. Technical Solution

[0014] To solve the above-mentioned technical problems, the present invention employs the following steps performed by the processor of a computer system:

[0015] S101 Obtain the project version, engineering cost level nodes, and candidate calculation tasks; identify the computable leaf list and build a composite index. S102 Generate candidate execution descriptions and constraint read sets, and execute metadata read constraints; upon rejection, atomically update the candidate status and set the cancellation flag. S103 Parse variable mappings to determine the hierarchical node range, source field path, filtering, aggregation, transformation, unit of measurement, precision, and mapping version. S104 Normalize the scope semantic tuple, compute the request digest to locate the shared bucket, and perform full equivalence checks field by field within the bucket. S105 Verify the deterministic and non-external side-effect-free eligibility for sharing, assign record identifiers to complete tuples, create or reuse shared compute nodes, and atomically attach candidate references. S106 When a candidate is cancelled, it removes its own references at the generational level; shared nodes are cancelled only when the reference set is empty, the node is pending execution, and the generational match is achieved. S107 Execute shared directed acyclic dependencies Figure 1 Next, an immutable variable snapshot bound to the node generation is generated, and a write barrier is executed before being associated with a specific candidate. S108 Perform variable snapshot constraints and deterministic calculations; perform partial failures, cross-version reuse bindings, and replay checks based on the intersection of the dependency set and the change set.

[0016] The request digest serves only as location information for candidate shared buckets. Final equivalence determination is based on a field-by-field comparison of the complete normalized scope semantic tuples, with the complete tuple record identifier serving as the secondary identity within the shared node and variable snapshots. After execution by a shared node, an immutable variable snapshot is first generated, and then a barrier is written for each specific candidate execution, thereby preventing the erroneous propagation of candidate-level cancellation status to shared node-level cancellation.

[0017] The constraint read set and the shared node read dependency set are maintained separately: the former is used to distinguish between metadata read constraints and variable snapshot constraints based on the type of the read field; the latter contains source-level nodes and field dependencies, variable mapping dependencies, and versioned parameter dependencies, and is used to find intersection with the change set. When the project version changes but the dependency sets do not intersect, a cross-version reuse binding pointing to the original immutable variable snapshot is established for the new project version; when there is an intersection, the shared node and its downstream snapshots are invalidated and rebuilt with an incrementing node generation number.

[0018] III. Beneficial Effects

[0019] The boundaries of the engineering objects involved in reading and aggregation are identified by hierarchical nodes and leaf lists to avoid duplicate entries of summary nodes and explicit detail nodes;

[0020] By constraining the read set, inapplicable candidates are stopped before expanding quantities, unit prices, and aggregate variables, thus reducing the reading of invalid variables;

[0021] By parsing and normalizing scope semantic tuples through variable mapping, project version, hierarchical node scope, field path, filtering, aggregation, unit and precision are incorporated into the complete request semantics;

[0022] Hash collisions and erroneous sharing across different project scopes are prevented through "summary location of shared buckets, complete tuple comparison, deterministic and side-effect-free verification, and complete tuple record identification".

[0023] By using node generation number, active candidate reference set, atomic dereferencing, and candidate-level write barriers, we can prevent the cancellation of one candidate from affecting the writing of other candidates or old generation results.

[0024] By reading dependency sets, change sets, cross-version reuse bindings, immutable variable snapshots, and replay summaries through shared nodes, the system retains unaffected shared results while ensuring cache correctness. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the core processing steps of the present invention, including engineering level scope resolution, complete scope semantic tuple equivalence verification, shared node generation and active candidate reference management, as well as secure cancellation, write barriers, immutable variable snapshots, and local failures.

[0026] Figure 2 This is the overall flowchart of the present invention for hierarchical data acquisition, pre-constraints, variable mapping parsing, scope semantic tuple generation, request digest shared bucket, complete equivalence verification, shared node reference management, deterministic computation and replay verification;

[0027] Figure 3 This diagram illustrates the candidate task status, shared computing node status, node generation number, active candidate reference set, atomic dereference, and safe cancellation conditions.

[0028] Figure 4 A schematic diagram illustrating scope semantic tuple normalization, summary bucket location, field-by-field full comparison, shared qualification verification, shared node execution, and candidate-level write barrier.

[0029] Figure 5 A replayable traceability structure diagram consisting of source data, full-scope semantic tuples, bucket comparisons, node generations, reference changes, read dependencies, change invalidation, variable snapshots, and result summaries;

[0030] Figure 6 This is a schematic diagram showing the boundary between the core processing module of this invention and the peripheral engineering cost data platform, upper-level applications, combination optimization, review and knowledge update modules. Detailed Implementation

[0031] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. The following embodiments are illustrative of the invention and not intended to limit its scope. Equivalent substitutions can be made for the data storage format, index implementation, atomic operation mechanism, and deployment method without departing from the core processing chain of the present invention.

[0032] I. Terminology and Data Objects

[0033] Project cost level nodes Parent-child hierarchical nodes are formed by objects such as projects, individual projects, unit projects, sub-projects or sub-items, lists, quotas or consumption items, and personnel, materials, and machinery. Calculate leaf list nodes The list no longer has computable list child nodes in the list semantic hierarchy, and contains nodes with quantities, unit prices, amounts, or fields that can be used for variable aggregation. Candidate computation task record The processor-executable task record formed by candidate computation rules includes the scope of application, impact list, constraint identifier, variable identifier, computation model identifier, and rule version. Constraint Read Set The set of fields read by the constraint execution is used to objectively distinguish between metadata read constraints and variable snapshot constraints. Metadata read constraints The constraint read set contains only constraints for project context, candidate task metadata, node labels, or index hit fields. Variable snapshot constraints The constraint read set includes constraints on quantities, unit prices, amounts, engineering parameters, snapshots of immutable variables, data quality results, or calculation input calibers. Normalized scope semantic tuples The complete request semantics consist of project version, source object type, normalization level node range, source field path, filtering predicate, grouping dimension, aggregation operator, transformation chain, target unit of measurement and precision. Request Summary The summary calculated based on the normalized scope semantic tuple is only used to locate candidate shared buckets and cannot be used alone as a conclusion of request equivalence. Complete tuple record identifier The unambiguous record identifier obtained after field-by-field confirmation of the complete normalized scope semantic tuple is used as the secondary identity within the bucket for shared nodes and variable snapshots. Shared qualification token This indicates whether the variable computation chain is deterministic, has no external side effects, and its output is determined solely by the read dependency set and versioning parameters. Node Generation Number The version identifier of a shared node is incremented each time it is created, expires, or is rebuilt, and is used to prevent old references or results from affecting the new node. Activity candidate reference set The set of candidate tasks that still consume the results of a shared computing node; cancellation of a candidate task only removes its own reference. Immutable variable snapshot The read-only result generated after a shared node is executed once is bound to the complete tuple record identifier, node generation number, and snapshot version. Write barrier Before the snapshot of immutable variables or candidate results are associated with specific candidates, the candidate de-marking, candidate status version, node generation number, and active reference status are jointly verified. Shared node reads dependency set The shared node is a collection of source-level nodes, fields, variable mapping records, and versioning parameters that it actually depends on. Change collection When a project version changes, it records the set of dependency identifiers for the source nodes, fields, variable mappings, or versioning parameters that have changed. Cross-version reuse binding When the shared node reads a dependency set and a change set that do not intersect, an effective binding is established for the new project version to a snapshot of an existing immutable variable. Replayable traceable package A data package containing source data summary, complete semantics, intra-bucket comparisons, node generations, reference changes, read dependencies, write barriers, change invalidation, variable snapshots, and result summaries. Implement Adjustment Amount Snapshot Record the structured inputs that include the amount of the adjustment, unit of measurement, scope of application, price benchmark, parameter version, and source identifier.

[0034] II. Overall Data Structure

[0035] Project context recording Project Identifier, Project Version, Stage, Business Type, Specialization, Price Benchmark, Contextual Summary Save the project context required for candidate retrieval, variable processing, and consistent calculation methods. Leaf list index records List identifier, code, standardized name, characteristic term, unit of measurement, specialty, node path, source version, leaf tag Create a composite index and preserve the project-level path. Candidate execution description Candidate identifiers, hit list, constraint dependencies, variable identifiers, computational model, and estimated execution cost. A schedulable execution description is formed before variables are read. Candidate state record Candidate identifier, execution identifier, candidate state version, previous state, current state, event, reason code, update time The state transition of candidate tasks is updated and saved through atomic comparison. Constraint Description Record Constraint identifier, constraint read set, dependent constraints, rule version, cost level, output status Create an executable constraint queue and objectively distinguish constraint types. Variable mapping resolution record Candidate identifier, variable identifier, source object scope, source field path, filtering, aggregation, transformation, target unit, mapping version Before making a sharing decision, determine the scope of the actual project object and the semantics of field processing. Scope semantic tuple record Complete tuple record identifier, project version, source object type, normalized node range, path, filtered abstract syntax tree, grouping, aggregation, transformation, unit, precision, request summary Preserve the complete request semantics; the request digest is only used for shared bucket location. Shared qualification record Complete tuple record identifier, deterministic marker, no side effects marker, external snapshot identifier, and determination reason. Define secure sharing boundaries. Shared node operation records Shared node identifier, request digest, complete tuple record identifier, node generation number, node state, read dependency set, active candidate reference set, snapshot version Control the execution, referencing, and lifecycle of shared nodes. Immutable variable snapshot Snapshot identifier, complete tuple record identifier, node generation number, value, unit, source summary, data quality, snapshot version Save the execution result once and allow multiple candidates to reference it in read-only mode. Write barrier record Candidate ID, Candidate Status Version, Cancel Flag, Node Generation Number, Activity Reference, Write Decision Prove whether candidate-level distribution or writing is allowed. Change collection record Old project version, new project version, changed dependency identifier, affected shared nodes, expiration time Perform a partial failure on the intersecting nodes and downstream snapshots. Cross-version reuse of binding records New project version, shared node identifier, variable snapshot identifier, read dependency summary, validation result Securely bind unaffected snapshots to the new project version. Replayable traceable package Source data summary, tuple comparison record, read dependency, status and cancellation record, write barrier, change invalidation, model snapshot, result summary Supports replay, accuracy comparison, and difference localization. Implement Adjustment Amount Snapshot Adjustment identifier, amount of adjustment, unit of measurement, scope of application, price benchmark, source type, parameter version, confidence level Provides traceable adjustment inputs for dual-state amount subordinate implementations.

[0036] III. Leaf List Recognition and Composite Index

[0037] The processor performs a depth-first or breadth-first traversal of the project cost level nodes. When a node is a bill of quantities type, does not have computable bill of quantities child nodes, and has fields for quantity, unit price, amount, or participation in variable aggregation, the node is marked as a computable leaf bill of quantities node. Nodes with computable bill of quantities child nodes are only used as path evidence, cost balance evidence, or range limiting conditions, and are not included in the quantity and amount again.

[0038] The list name and list item feature text undergo full-width / half-width character encoding, case consistency, symbol cleanup, synonym mapping, and engineering terminology meta-coding. The list encoding simultaneously stores the complete code and multiple lengths of encoding prefixes. The composite index includes at least a stage index, a business type index, a specialty index, an encoding prefix index, a name meta-index, a list item feature meta-index, a unit of measurement index, and a source node path index.

[0039] IV. Candidate Tasks, Constraint Read Sets, and Pre-circuiting

[0040] Candidate computation rule records are structured and generated from standard references, engineering cases, expert experience, or historical verification records. They must include at least the scope of application, impact keywords, constraint description identifiers, variable identifiers, computation model identifiers, and version fields. These sources are solely for forming processor-readable candidate computation task records; runtime shared decision-making does not rely on natural language similarity, but rather on the engineering scope and data processing semantics formed after variable mapping parsing.

[0041] Each constraint description record explicitly stores the constraint read set. If the constraint read set contains only project context fields, candidate task metadata, node labels, or index hit fields, then the constraint is a metadata read constraint; if it contains any of the following: quantity, unit price, amount, project parameters, immutable variable snapshot, data quality result, or calculation input caliber, then it is a variable snapshot constraint. This classification is determined by field dependencies, not arbitrarily by business names or manual labels.

[0042] The processor first executes metadata read constraints. When any hard constraint outputs a rejection status, the processor performs an atomic comparison update with the candidate identifier, execution identifier, and candidate status version, writes the reason code, and sets a cancellation flag; variable mappings, variable requests, shared node reference appends, and candidate computation tasks that have not yet started are all marked as cancelled. Started tasks validate the cancellation flag before writing candidate status, appended references, or associated results. Manually processed statuses save missing fields and recovery dependencies, which are then restored from the specified dependency nodes after being supplemented.

[0043] V. Variable Mapping Resolution and Normalized Scope Semantic Tuples

[0044] Instead of directly merging requests based on abstract variable identifiers, expression text, or source field paths, the processor first parses the variable mapping record to determine the source object type, the set of hierarchical nodes involved in reading or aggregation, the source field path, filtering predicates, grouping dimensions, aggregation operators, transformation chains, target units of measurement, numerical precision, and mapping version, thus forming a variable mapping parsing record.

[0045] The hierarchical node identifiers are sorted and deduplicated, and the filtering predicates are parsed into a normalized abstract syntax tree. The formats of parentheses, whitespace, and constants that do not affect the logical results are unified, and only sibling logical condition items that are applicable to the commutative law and do not contain external side effects are sorted, while maintaining the order of operator precedence, nesting level, and non-commutative operands. The unit conversion chain, aggregation parameters, and transformation chain versions are serialized using a fixed field order to form a normalized scope semantic tuple.

[0046] VI. Summary bucket, complete equivalence comparison and sharing eligibility

[0047] The processor computes a request digest for normalized scope semantic tuples. This request digest is only used to locate candidate shared buckets. After hitting the same shared bucket, it still compares the project version, source object type, normalized node range, source field path, normalized filter predicate, grouping dimension, aggregation operator, transform chain version, target unit of measurement, and numerical precision field by field. Only when the complete tuples are equal are they assigned or reused with the same complete tuple record identifier. Requests with the same request digest but different fields retain different complete tuple record identifiers and establish independent compute nodes.

[0048] In addition to ensuring complete tuple equality, a shared eligibility check is performed on the variable computation chain. Only computation chains whose output is entirely determined by the shared node's read dependency set and versioning parameters, do not use unfixed random values, do not read external states that have not been snapshotted, and do not generate non-isolated external writes can be shared across candidates. Nodes that call random models, real-time external interfaces, or generate database writes must establish independent nodes unless they fix the random seed, create external response snapshots, and isolate side effects.

[0049] For example, the same field path "List Item / @Comprehensive Price" exists in both basement unit projects and above-ground unit projects. If only the field path or request summary is used as the key, it may incorrectly create identical requests; because the unit project identifiers participating in the aggregation are different, the normalization level node ranges are different, the complete tuples are not equivalent and cannot be shared. Even if two unequal requests are deliberately placed into the same summary bucket, field-by-field comparison within the bucket will still retain them as independent records.

[0050] VII. Shared node status, node generations, and secure cancellation

[0051] Candidate task status and shared compute node status are maintained separately. Candidate task status includes pending, mapping ready, shared attached, manually processed, rejected, canceled, and computed; shared compute node status includes pending, running, completed, canceled, and expired. Candidate status versions and node generation numbers belong to different objects and do not share the same status field.

[0052] A shared compute node's runtime record includes at least a request summary, a complete tuple record identifier, a node generation number, a node state, a shared node read dependency set, an active candidate reference set, and a snapshot version. When a candidate task attaches a reference, an atomic attachment is performed with the expected node generation number; when a candidate is cancelled, its own reference is atomically removed with the same generation number. A node is only converted from pending execution to cancelled if the active candidate reference set is empty, the node state is pending execution, and the comparison and swap operation based on the expected generation number is successful. A node that has already run or completed will not be rolled back due to a single candidate cancellation.

[0053] 8. Immutable variable snapshots and candidate-level write barriers

[0054] A shared computing node executes once according to the directed acyclic dependency graph, first generating an immutable snapshot bound to the complete tuple record identifier, node generation number, and snapshot version. Whether a shared node executes is determined by the node-level state, not by any candidate cancellation state.

[0055] Before associating an immutable variable snapshot or the result based on that snapshot with a specific candidate, the write barrier reads the candidate's cancellation flag, candidate state version, shared node generation number, and active reference state. If any check is not met, the association or write to that candidate is abandoned, but this does not affect the same shared node providing snapshots to other active candidates. This divides "node snapshot generation" and "candidate snapshot reception" into two processing phases.

[0056] 9. Shared node read dependencies, partial failures, and cross-version reuse

[0057] The shared node read dependency set is not simply a list of field names, but consists of source data read dependencies, variable mapping dependencies, and versioned parameter dependencies. Source data read dependencies must contain at least the source-level node identifier and field identifier; variable mapping dependencies must contain at least the mapping record identifier and mapping version; and versioned parameter dependencies must contain at least the parameter identifier and parameter version. The project version is stored as traceability information, but is not the sole condition for all dependencies to intersect without distinction.

[0058] When project data, variable mappings, or versioning parameters change, a change set is generated. The change set records the identifiers of the changed dependencies and intersects with the dependency set read by the shared node: if an intersection exists, the corresponding shared node and its downstream snapshots are invalidated, and the node generation number is incremented during reconstruction; if no intersection exists, the complete tuple record identifier, mapping version, computation model version, and dependency summary of the old snapshot are verified, and a cross-version reuse binding pointing to the original immutable variable snapshot is established for the new project version.

[0059] The cache employs a two-level identity: first, candidate cache buckets are located using request digests; then, a complete tuple record is used as the secondary identity within the bucket, which is associated with the variable mapping version and the computation model version. The project version is associated with a specific variable snapshot through current version binding or cross-version reuse binding. Therefore, digest collisions will not cause cache misses, and changes in the project version will not unconditionally invalidate all unchanged nodes.

[0060] 10. Standard version compatibility, data quality, and mapping conflicts

[0061] For XML exported from different national standards, provincial standards, or different versions of XSD, the processor first identifies the standard identifier and version, and then the corresponding version adapter maps the original nodes to nodes of a unified level. Strict XSD validation results are saved with data quality markers; differences in node order, allowed null fields, and version structure are not directly equated to the entire project being unparseable. If the required fields can be obtained through a defined mapping, the adapter version is calculated and saved; if critical fields are missing, the process enters manual processing or rejection mode.

[0062] When multiple sources are available for variable mapping, a deterministic sorting is formed using versioned priority configuration. In one embodiment, the sorting keys are, in order: source stage distance (ascending), source credibility (descending), mapping priority (descending), data version (descending), and mapping record identifier (ascending). If, after sorting, a unique identifier cannot be determined based on valid business fields, or if key variables are missing or unit conversion chains conflict, automatic selection is not performed, and the process is transferred to manual processing.

[0063] XI. Variable Snapshot Constraints and Deterministic Calculation

[0064] Variable snapshot constraints include engineering parameter boundary constraints, variable scope consistency constraints, data quality and confidence constraints, and computational input consistency constraints. When a variable snapshot constraint outputs a pass status, the processor invokes the deterministic computational model corresponding to the computational model identifier in the candidate execution description; when a rejection status or a manual processing status is output, the deterministic computation of that candidate is stopped and the reason code, missing fields, and recovery dependency points are recorded.

[0065] As an implementation method applicable to value engineering net savings calculation, benchmark state snapshots and optimized state snapshots are established for all affected list items under the same price benchmark, tax and fee caliber, and unit of measurement. For list item i, the benchmark quantity is denoted as Q_i0, the benchmark unit price is denoted as P_i0, the optimized quantity is denoted as Q_i1, and the optimized unit price is denoted as P_i1; the benchmark amount B_i = Q_i0 × P_i0, the optimized amount O_i = Q_i1 × P_i1, and the direct savings D_i = B_i - O_i; the B_i of newly added list items is zero, and the O_i of deleted list items is zero.

[0066] Gross savings are the sum of direct savings for each item in the bill of quantities. The snapshot of the adjusted amount records the adjusted amount value, unit of measurement, applicable scope, price benchmark, parameter version, and source identifier. Net savings are gross savings minus the adjusted amount recorded in this snapshot. When using differential form, it can be expressed as (Q_i0-Q_i1)×P_i0+Q_i1×(P_i0-P_i1) to avoid double counting of overlapping items for quantity differences and unit price differences. If the optimization ratio or adjusted amount comes from the knowledge default range rather than the project file, the result saves the upper and lower limits, assumed parameters, and source version, and is marked as a conditional result.

[0067] 12. Replayable traceability and unstructured input boundary

[0068] A replayable traceability package includes at least the source data version and content summary, variable mapping resolution record, fully normalized scope semantic tuple, request summary, shared bucket field-by-field comparison results, shared eligibility marker, full tuple record identifier, node generational changes, active candidate reference changes, write barrier verification, shared node read dependency set, immutable variable snapshot, change set failure record, cross-version reuse binding, candidate status and cancellation record, computation model version, and original result summary.

[0069] Before generating the summary, field names, hierarchical node sets, predicate abstract syntax trees, numeric precision, array sorting, null values, and character encoding are normalized and serialized according to a fixed field order. During replay, the same version is used for re-execution, comparing the replay summary with the original result summary; it can also compare the "reference mode without shared variable nodes" and the "optimized mode using scope equivalence sharing and safe node cancellation." When summaries are inconsistent, differences are output layer by layer: source data, complete tuples, intra-bucket comparisons, node generations, reference changes, write barriers, read dependencies, variable snapshots, and formula nodes.

[0070] Unstructured design specifications, reports, or expert opinions are not directly used as variable inputs for shared nodes. The content is converted into structured input records, including at least field names, values, units of measurement, source evidence, data version, and confirmation status, through deterministic rule parsing or manual input. These records must pass data structure, unit, evidence citation, and field conflict checks before participating in variable mapping; if checks fail, the process is moved to manual processing. This invention does not rely on an automated unstructured extraction process as a necessary technical feature.

[0071] XIII. Implementation Methods of Systems, Electronic Devices, and Program Products

[0072] like Figure 6 As shown, one embodiment of the system includes a hierarchical node and leaf index module, a candidate computation task and constraint reading module, a variable mapping parsing module, a scope semantic tuple module, a request digest shared bucket and full equivalence verification module, a shared qualification verification module, a shared computation graph and node generation management module, a candidate cancellation and write barrier module, a change invalidation and cross-version binding module, a variable snapshot constraint and deterministic computation module, and a replay traceability module. Each module exchanges structured data through project version, candidate execution identifier, full tuple record identifier, node generation number, active candidate reference set, shared node read dependency set, and immutable variable snapshot.

[0073] The electronic device includes a processor, memory, and a network interface; the memory stores program instructions that cause the processor to execute steps S101 to S108. Indexes, constraints, variable mappings, state transitions, and computational models are versioned; specific databases, programming languages, atomic operation implementations, and deployment platforms are not limited. A computer-readable storage medium stores the program instructions, and the computer program product includes programs or instructions that cause the processor to execute the above methods.

[0074] XIV. Real-world project verification and implementation methods

[0075] To verify the feasibility of this invention, a self-constructed single-process algorithm verification program was used to verify five anonymized real-world engineering project XML files, two XSD format definitions, and 92 candidate calculation rule records. The test environment consisted of a Linux x86_64 virtualization environment, Python 3.13.5, lxml 6.1.1, 56 logical processors, and 4GB of memory. Each mode was repeated five times, and the wall clock time was recorded using a high-resolution monotonic clock, with the median being used. The project name, construction unit, and address were anonymized as P1 to P5.

[0076] P1 GB1.0 Public buildings, hospitals 746 812 11,479 1 difference P2 HN2.0 Residential building with basement 1,322 1,909 27,704 60 differences P3 HN2.0 public buildings 884 1,521 22,097 18 differences P4 HN2.0 Public buildings and industrial plants 446 738 10,234 pass P5 HN1.0 Public building, with basement 1,925 2,420 36,642 8 differences

[0077] Five projects generated a total of 5,323 unified inventory records. Strict XSD differences mainly stemmed from node order, allowed null fields, and different version structures; the processor stored data quality markers and adapter versions, and did not directly equate locatable format differences to the entire project being incalculable.

[0078] XV. Efficiency and Correctness Verification

[0079] P1 746 79.392 25.593 3.10 times 1.714 46.33 times 99.84% 75.71% P2 1,322 147.984 48.325 3.06 times 2.449 60.44 times 99.90% 39.13% P3 884 98.801 32.567 3.03 times 1.938 50.97 times 99.91% 47.23% P4 446 51.194 16.791 3.05 times 1.266 40.43 times 99.90% 62.39% P5 1,925 238.472 73.151 3.26 times 3.128 76.24 times 99.90% 41.98%

[0080] The performance improvement includes a 3.03 to 3.26x increase in one-time cold start speed for index building; a 40.43 to 76.24x increase in repeated analysis speed for reused indexes; a 99.84% to 99.91% reduction in candidate and list comparisons or index record accesses; and a 39.13% to 75.71% reduction in variable reads. These figures support the overall efficiency of leaf indexes, pre-constraints, and on-demand variable evaluation, and do not separately represent performance multiples for full tuple comparisons, node generation control, or write barriers.

[0081] Different project scopes along the same path The field paths are the same; range A = 1.1.3, amount 79,048,189.60 yuan; range B = 1.2.1, amount 59,032,545.73 yuan. Different full-scope semantic tuples, not merged Having the same field path does not mean that the project scopes are equivalent. Forced digest collision Artificially causing two unequal requests to enter the same summary bucket The bucket contains two independent records that have not been merged. The request digest is only used for location; a full comparison determines equivalence. Event referencing and cancellation interleaved 100,000 sets of randomly generated atomic events are interleaved. There were 0 instances of accidental cancellation across candidate candidates; 0 writes after cancellation; and 0 instances of accidental removal of other references. Node generations, active reference sets, and write barriers work together to ensure the cancellation of isolation. Partial changes and cross-version binding Input the change sets that intersect with and do not intersect with the dependent sets, respectively. Intersecting nodes fail; disjoint nodes establish cross-version reuse bindings. Avoid reusing old snapshots and retain unaffected results.

[0082] XVI. Conditional Calculation Examples

[0083] Example 1: In Project P5, the processor locates 31 leaf lists related to earthwork, spoil, off-site transport, and backfill. The XML snapshot shows approximately 2,376,211.40 cubic meters of spoil or off-site transport, and approximately 85,470.38 cubic meters of backfill, with a related baseline amount of approximately RMB 11,515,900. Variable snapshot constraints require soil testing, backfill suitability, compaction degree, and site organization conditions to pass. Adjustments are made based on 20% to 30% of the versioned knowledge record and RMB 10,000 to 20,000, resulting in a conditional net savings range of approximately RMB 2,283,200 to RMB 3,444,800. This amount does not indicate that savings have been implemented; if any critical engineering condition is not met, a rejection status or manual processing status is output.

[0084] Example 2: In Project P1, the processor, based on the duct name and the characteristics of the list items, excludes smoke exhaust and fire prevention uses, locating 13 non-smoke exhaust duct leaf lists, with a total area of ​​approximately 14,388.32 square meters and a base amount of approximately RMB 3,197,000. When the relevant materials meet the constraints of fire resistance, strength, hygiene, and hospital setting, a conditional range of approximately RMB 479,500 to RMB 799,200 is formed based on a version-specific price difference parameter of 15% to 25%.

[0085] Example 3: In project P1, the processor locates a list of 5 pipe support items, with a base amount of approximately RMB 2.2475 million. Variable snapshot constraints are used to specifically review the configuration, load, spacing, and construction space of the seismic support. If approved, a conditional range of approximately RMB 224,700 to RMB 449,500 is formed based on versioned parameters of 10% to 20%. If the review fails, the traceability package saves the rejection status and does not output a positive net saving.

[0086] XVII. Alternative Implementation Methods

[0087] Leaf list indexes can use in-memory inverted indexes, relational database indexes, search engine indexes, or combinations thereof; normalized scope semantic tuples can be encoded as normalized JSON, binary tuples, or database composite records; request digests can use secure hashes, unencrypted hashes, or database index values, but the digest is only used for shared bucket location, and the full equivalence check within the bucket and the full tuple record identifier cannot be omitted.

[0088] Shared compute nodes can execute in a single process, a distributed task system, or a streaming compute engine. Node generation numbers and active candidate reference sets can be maintained by database row versions, compare-and-swap instructions, transaction locks, or mechanisms with equivalent atomicity. Shared node read dependency sets and change sets can be represented using sets, bitmaps, inverted indexes, or dependency graphs. Cross-version reuse bindings can be implemented using relational records, snapshot aliases, or version maps.

[0089] Candidate sorting, combinatorial optimization, expert review, and knowledge publication can be used as post-processing modules of the results of this invention, but they do not change the core processing chain of this invention, including hierarchical scope resolution, complete scope semantic equivalence, shared eligibility, node generation, active candidate reference, security cancellation, write barrier, local failure, and cross-version reuse.

Claims

1. A method for sharing equivalent requests for engineering cost scope and securely canceling nodes, characterized in that, Executed by the processor of the computer system, the process includes: acquiring the project version record, the set of cost-level nodes, and multiple candidate calculation task records for the project to be analyzed. The set of cost-level nodes includes node identifiers at least two levels from the project, single project, unit project, sub-project, and list item. The process also involves determining computable leaf list nodes from the set of cost-level nodes and establishing a composite index. For each candidate calculation task, the process executes metadata read constraints based on the constraint read set of the constraint description record. The constraint read set of the metadata read constraints only includes project context fields, candidate calculation task metadata, node labels, or index hit fields. Finally, the process outputs a rejection statement in the metadata read constraint. In the absolute state, the candidate task state is atomically updated based on the candidate state version, and a cancellation flag is set. For candidate computation tasks without a cancellation flag, the candidate variable identifier is parsed into a variable mapping parsing record. The variable mapping parsing record includes the project version, source object type, hierarchical node range involved in reading or aggregation, source field path, filtering predicate, grouping dimension, aggregation operator, transformation chain, target unit of measurement, numerical precision, and mapping version. The hierarchical node range, filtering predicate, and transformation chain are normalized to form a normalized scope semantic tuple, and a request digest used only for locating the candidate shared bucket is calculated. Within the candidate shared bucket, the normalized scope semantic tuple is fully equivalent field by field, and only when the complete tuple is valid is the tuple considered. When tuples are equal and the corresponding variable computation chains satisfy the conditions of determinism and no external side effects, the variable requests of multiple candidate computation tasks are merged into the same shared computation node, and an unambiguous complete tuple record identifier is assigned to the complete tuple; the node generation number, node state, shared node read dependency set, and active candidate reference set are maintained for the shared computation node; when a candidate computation task is attached to or dereferenced, an atomic operation with the expected node generation number is performed; when a candidate computation task is canceled, only the reference to the candidate computation task is dereferenced, and the shared computation node is updated to canceled only when the active candidate reference set is empty, the node state is pending execution, and the atomic state transition based on the expected node generation number is successful; The shared computing node is executed once according to the shared directed acyclic dependency graph, generating an immutable variable snapshot bound to the node generation number. Before associating the immutable variable snapshot or the result formed based on the immutable variable snapshot with a specific candidate computing task, the cancellation flag, candidate state version, node generation number, and activity reference state of the candidate computing task are verified by writing a barrier, and the immutable variable snapshot is only associated with the currently active candidate. Variable snapshot constraints are executed based on the immutable variable snapshot, and when the variable snapshot constraint outputs a pass status, a deterministic computing model is invoked to generate a candidate computing result record. When a rejection status or a manual processing status is output, the execution of the deterministic computing model is stopped and a reason code is recorded.

2. The method according to claim 1, characterized in that, Determining computable leaf list nodes from the set of project cost hierarchy nodes includes: when a node belongs to the list type, does not have computable list sub-nodes, and has fields for quantity, unit price, amount, or participating variable aggregation, the node is marked as a computable leaf list node; summary nodes with computable list sub-nodes are only used as path constraints, scope limits, or evidence of amount balance; a composite index of leaf lists is established based on project stage, business type, specialty, list code prefix, standardized name terms, list item characteristic terms, unit of measurement, and source data path.

3. The method according to claim 1, characterized in that, The constraint description record includes constraint identifier, constraint read set, dependent constraint identifier, rule version, expected number of field reads, expected number of node scans, and output status set; when the constraint read set contains any one of the following: quantity, unit price, amount, engineering parameters, immutable variable snapshot, data quality result, or calculation input caliber, the corresponding constraint is determined as a variable snapshot constraint; Candidate task status and shared computing node status are maintained separately. Candidate task status includes at least pending, mapping ready, shared attached, manually processed, rejected, canceled, and computed. Shared computing node status includes at least pending execution, running, completed, canceled, and expired. Candidate task status updates use atomic comparison updates based on candidate status versions, and generate idempotent execution keys based on project version, candidate identifier, execution identifier, rule set version, and computing model version.

4. The method according to claim 1, characterized in that, The formation of the normalized scope semantic tuple includes: sorting and deduplicating the individual project identifiers, unit project identifiers, sub-project identifiers, list item identifiers, or source path prefix sets involved in reading or aggregation; parsing the filtering predicate into an abstract syntax tree; normalizing the parentheses, whitespace, and constant formats that do not affect the logical result; and sorting only the sibling logical condition items that are commutative and do not contain external side effects, while maintaining the operator precedence, nesting level, and order of non-commutative operation items; and serializing the aggregation operator, grouping dimension, transformation chain version, target unit of measurement, and numerical precision according to a fixed field order.

5. The method according to claim 1, characterized in that, The request digest is used only for indexing candidate shared buckets; after hitting the same candidate shared bucket, the project version, source object type, normalization level node range, source field path, normalization filter predicate, grouping dimension, aggregation operator, transformation chain version, target unit of measurement, and numerical precision are compared field by field; if the request digest is the same but any field is different, different complete tuple record identifiers are retained and independent computing nodes are established; the deterministic and no external side effects conditions include: the output is determined only by the shared node reading the dependency set and versioning parameters, no unfixed random values ​​are used, no external states that have not formed a version snapshot are read, and the execution process does not generate non-isolated external writes.

6. The method according to claim 1, characterized in that, The running record of the shared computing node includes a request digest, a complete tuple record identifier, a node generation number, a node status, a shared node read dependency set, an active candidate reference set, and a snapshot version; when attaching a candidate reference, the node generation number is verified and atomically written to the active candidate reference set; when removing a candidate reference, both the candidate status version and the node generation number are verified. Only the pending state is allowed to be converted to the cancelled state when the active candidate reference set is empty; the running or completed state is not rolled back due to the cancellation of a single candidate.

7. The method according to claim 1, characterized in that, The write barrier reads the candidate cancellation flag, candidate state version, shared computing node generation number, and active candidate reference set before associating immutable variable snapshots or candidate computation results with candidate computation tasks. If any check fails, the association or writing to the candidate computation task is abandoned. When a candidate compute task is canceled while the shared compute node is running or has completed, the candidate compute task is only removed from the active candidate reference set, and snapshots of immutable variables that have been generated or are being generated for other active candidates are not rolled back.

8. The method according to claim 1, characterized in that, The nodes of the shared directed acyclic dependency graph include source field reading nodes, data type conversion nodes, unit conversion nodes, range filtering nodes, range aggregation nodes, correction coefficient nodes, and formula input nodes, and cyclic dependency detection is performed during graph construction; The cache locates candidate cache buckets using request digests, uses complete tuple records as identifiers for secondary identities within the bucket, and associates variable mapping versions and computation model versions. The shared node read dependency set includes source-level nodes and field dependencies, variable mapping dependencies, and versioned parameter dependencies. When the project version changes, a change set containing identifiers of the changed dependencies is generated, invalidating shared computation nodes and their downstream snapshots where the shared node read dependency set intersects with the change set, and establishing cross-version reuse bindings from the new project version to the original immutable variable snapshots for non-intersecting shared computation nodes.

9. The method according to claim 1, characterized in that, Obtaining the set of engineering cost hierarchical nodes includes: identifying the standard type and standard version corresponding to the original engineering cost document; mapping the original nodes to unified hierarchical nodes using the corresponding version adapter; and saving the XSD verification result, adapter version, allowed null fields, field conflicts, and source node path as data quality markers; when there are multiple available sources for variable mapping, deterministic sorting is performed according to the pre-versioned priority configuration, which includes at least the source stage distance, source credibility, mapping priority, and data version; and outputting a manual processing status or rejection status when the mapping result cannot be uniquely determined or key variables are missing.

10. The method according to claim 1, characterized in that, The variable snapshot constraints include engineering parameter boundary constraints, variable scope consistency constraints, data quality and confidence constraints, and computational input consistency constraints; each execution saves the constraint read set summary, immutable variable snapshot summary, evidence citation, output status, reason code, and rule version.

11. The method according to claim 1, characterized in that, The deterministic calculation model includes a dual-state amount calculation model. For any affected list item i, a baseline state snapshot and an optimized state snapshot are generated, containing the quantity, unit price, amount, price benchmark, and tax caliber. The baseline quantity is Q_i0, the baseline unit price is P_i0, the optimized quantity is Q_i1, the optimized unit price is P_i1, the baseline state amount is B_i = Q_i0 × P_i0, the optimized state amount is O_i = Q_i1 × P_i1, and the direct savings are D_i = B_i - O_i. The net savings are the sum of all direct savings minus the implementation adjustment amount recorded in the versioned implementation adjustment amount snapshot. The B_i of newly added list items is zero, and the O_i of deleted list items is zero. The implementation adjustment amount snapshot records the amount value, unit of measurement, scope of application, price benchmark, parameter version, and source identifier.

12. The method according to claim 1, characterized in that, It also includes generating a replayable traceability package, which includes the source data version and summary, variable mapping resolution record, fully normalized scope semantic tuple, request summary, field-by-field comparison result of shared bucket, shared qualification flag, full tuple record identifier, node generational change, active candidate reference change, write barrier verification, shared node read dependency set, immutable variable snapshot, change set failure record, cross-version reuse binding, candidate status and cancellation record, computation model version and original result summary; during replay, it is re-executed according to the same version, and the reference mode of non-shared variable nodes is compared with the candidate result summary generated by the optimization mode using scope equivalence sharing and safe cancellation, and the difference node is output when there is inconsistency.

13. A system for sharing equivalent requests for engineering cost scope and for secure node cancellation, characterized in that, include: The hierarchical node and leaf index module is used to obtain the set of hierarchical nodes for engineering cost and determine the scope of engineering objects; The module includes several modules: a candidate computation task and constraint reading module, used to generate candidate execution descriptions and execute metadata reading constraints based on the constraint reading set; a variable mapping parsing module, used to parse candidate variable identifiers into variable mapping parsing records; a scope semantic tuple module, used to form normalized scope semantic tuples based on the variable mapping parsing records and output them to the complete equivalence verification module; a request digest shared bucket and complete equivalence verification module, used to locate candidate shared buckets using request digests, compare complete tuples field by field within the bucket, and output complete tuple record identifiers; a shared qualification verification module, used to verify the determinism of variable computation chains and external side effects; a shared computation graph and node generation management module, used to construct or reuse a shared directed acyclic dependency graph based on the complete tuple record identifiers and shared qualification verification results, and maintain node generation numbers, node states, shared node read dependency sets, and active candidate reference sets; and a candidate cancellation and write barrier module, used to atomically remove the self-reference of cancelled candidates, cancel shared computation nodes only when the active candidate reference set is empty, the node is pending execution, and the generation matches, and execute write barriers before immutable variable snapshots are associated with specific candidates. The Change Invalidation and Cross-Version Binding module is used to invalidate affected nodes by reading the intersection of the dependency set and the change set based on the shared node, and to establish cross-version reuse bindings for unaffected nodes; the Variable Snapshot Constraint and Deterministic Calculation module is used to generate candidate calculation results based on immutable variable snapshots when the variable snapshot constraints are passed.

14. An electronic device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 12.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 12.

16. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the method described in any one of claims 1 to 12.

Images