A project risk monitoring method and system based on a versioned project event chain, an electronic device, and a computer readable storage medium

Abstract

The present application relates to a kind of project risk monitoring method, system, electronic equipment and computer readable storage medium based on versioned project event chain, belong to project data processing and computer information retrieval technical field.The method is associated with contract, supplementary agreement, finance, schedule, acceptance and work data, constructs the project event chain with version and effective state;Text data, structured data and risk case are established branch vector index, and old index record is invalidated, new record is incrementally updated when event changes;Based on current effective event, retrieve historical risk case, use current contract version and resource state to check candidate disposal suggestion and establish traceability relationship, while evaluating project execution health degree and platform availability respectively.The present application can reduce the invalid data involved in retrieval and the suggestion output that does not meet current constraint.

Description

Technical Field

[0001] This invention relates to the fields of project data processing, computer information retrieval, and project risk monitoring, specifically to a project risk monitoring method, system, electronic device, and computer-readable storage medium based on a versioned project event chain. Background Technology

[0002] As enterprise project management becomes increasingly digitalized, the sources of data generated during project implementation are becoming more diverse, typically including contracts and supplementary agreements, invoices, payment records, schedules, milestone completion status, acceptance documents, staffing, and work hour records. This data is often stored separately in contract management systems, financial systems, project management systems, and other business platforms, with inconsistent data structures, business keys, update times, and status identifiers across these systems. When analyzing project performance, it is usually necessary to first aggregate data from different sources before assessing costs, schedules, and risks. The accuracy of the correlation between data directly impacts the subsequent analysis results.

[0003] Existing project management platforms typically link data by project number, contract number, or business document number. When some records lack a unified number, the numbering is entered incorrectly, or the numbering rules are inconsistent across different systems, problems can easily arise such as the same business item being recorded repeatedly, different items being incorrectly merged, or some records failing to link. For scanned contracts, image invoices, and paper acceptance documents, optical character recognition (OCR) is required to convert them into processable data. The recognition results may contain errors in amounts, dates, entity names, or table row and column correspondences, further increasing the difficulty of data verification and cleaning.

[0004] Project data is also characterized by continuous change and the coexistence of multiple versions. During project execution, main contracts, supplementary agreements, contract amendments, schedule adjustment records, and acceptance change records may be generated successively. Sometimes, new documents only modify a few contents of the original documents, while the rest remain valid. When processing such data, some existing systems directly overwrite old records, making it difficult to trace historical data; others retain both new and old records but do not clearly distinguish their effective time and validity status, which can easily lead to replaced amounts, payment terms, delivery deadlines, or acceptance standards continuing to be used in statistics, retrieval, and risk assessment.

[0005] Contract texts, financial data, project progress data, and historical risk cases differ significantly in their data format and meaning. Contracts and supplementary agreements are primarily unstructured text, while financial, time, and progress data are mainly structured numerical values ​​or category fields. Historical risk cases also include risk characteristics, mitigation measures, and execution results. When storing or retrieving this data uniformly, existing platforms struggle to identify semantically similar but differently expressed content if only keyword matching is used. Furthermore, applying the same feature expression and retrieval method to different data types may affect matching results due to differences in data dimensions, value ranges, and meanings. Reprocessing all data after changes occur further increases computational load and update time.

[0006] In terms of risk management, existing systems typically provide reference measures based on preset rules, human experience, or similar historical projects. While measures from historical projects have some reference value, different projects may differ in terms of contract amounts, payment terms, delivery requirements, budget margins, remaining timeframes, and staff availability. Directly adopting historical measures based solely on the similarity of project characteristics may result in recommendations exceeding the current budget, violating contractual agreements, lack of available personnel, or inability to implement within the remaining timeframe. Furthermore, when recommendations lack clear case sources, contractual basis, and verification records, project managers need to search for relevant materials again, increasing review and decision-making costs.

[0007] Furthermore, the project's operational status differs from that of the monitoring platform itself. Project health is typically reflected by business metrics such as progress, cost, risk, and quality, while the monitoring platform's availability depends on operational conditions such as server status, database connectivity, network connectivity, heartbeat detection, and backup failover. Temporary network outages, service interruptions, or delayed data updates do not directly indicate an abnormality in project execution. Mixing platform malfunctions, data gaps, and abnormal project metrics in the same analysis can lead to incorrect project status updates and compromised alarm accuracy.

[0008] In summary, existing project risk monitoring technologies still need further improvement in terms of multi-source data correlation, version validity identification, heterogeneous data retrieval, applicability of disposal recommendations, and status evaluation. Summary of the Invention

[0009] The technical problem to be solved by this invention is: how to reduce the participation of invalid data in risk retrieval when multiple sources of project data are continuously updated and multiple versions coexist, and how to ensure that risk disposal recommendations based on historical cases are in line with current valid contracts and project resource conditions and are traceable.

[0010] To address the aforementioned technical problems, this invention provides a project risk monitoring method based on a versioned project event chain, executed by a project monitoring system, comprising the following steps.

[0011] S1. Obtain contract, supplementary agreement, invoice, payment, progress, acceptance and working hour data from different business systems, generate a unified project event identifier based on project number, contract number, business document number, event time and event type, and construct the current project valid event chain based on the source, version, effective time and valid status of each project event.

[0012] S2. Vectorize the text data, structured data, and historical risk cases in the project events respectively, and establish independent text vector indexes, structured feature vector indexes, and risk feature vector indexes. Link the index records in each vector index through a unified project event identifier. When a new project event is added, write the new project event into the corresponding vector index. When the content or status of a project event changes, mark the original version of the project event and its index records as invalid, and incrementally update the vector index corresponding to the changed project event.

[0013] S3. Extract the risk characteristics of the current project from the current project's valid event chain, generate a risk query vector, filter historical risk cases according to industry, project type, risk category, case validity status, and time range, and perform vector similarity retrieval and sorting on the filtered historical risk cases to obtain candidate historical risk cases.

[0014] S4. Generate candidate risk handling suggestions based on historical handling measures in candidate historical risk cases, and obtain contract constraints and resource constraints from the current effective contract version and current project resource status. Perform hard constraint verification and soft constraint verification on the candidate risk handling suggestions, eliminate candidate risk handling suggestions that violate hard constraints, reduce the ranking priority of candidate risk handling suggestions that violate soft constraints, and record the corresponding conflict reasons.

[0015] S5. Output risk handling recommendations that pass constraint validation, and establish the correspondence between risk handling recommendations and project event versions, historical risk case identifiers, contract clause versions, and constraint validation results; if there are no candidate risk handling recommendations that pass hard constraint validation, output constraint conflict information and manual confirmation mark.

[0016] In one optional implementation, step S1 prioritizes deterministic association of data from different business systems based on project number, contract number, and business document number. When a stable business primary key is lacking, candidate association records are generated based on business entity, amount, event time, and event type. The association confidence of these candidate association records is calculated, and candidate association records with an association confidence below a preset association threshold are set to a pending confirmation state.

[0017] In one optional implementation, within the same source system, data deduplication is performed based on the source system and the source business primary key; when a stable business primary key is lacking, data deduplication is performed based on key field summaries or file hashes. When field conflicts occur in data from different source systems, the current valid value is determined sequentially according to signed and effective contracts or supplementary agreements, audited financial system data, audited project management system data, and optical character recognition imported data, and the corresponding conflict records are retained.

[0018] In one alternative implementation, the main contract, supplementary agreements, and contract amendments are organized into a contract version chain, wherein the supplementary agreement covers the contract terms that are explicitly changed by it, and contract terms not changed by the supplementary agreement are inherited from the previous valid contract version. This clause-level version inheritance eliminates the need to regenerate all clauses in the main contract after the supplementary agreement takes effect; only the changed clauses are replaced.

[0019] In one optional implementation, when it is confirmed that records from different sources or different versions belong to the same business matter, the unified project event identifier for that business matter is retained, and a project event version identifier and a predecessor version identifier are set for each version. Version inheritance relationships for the same business matter are established through the predecessor version identifier, and business relationships between contract, invoice, payment, progress, acceptance, and work hour events are established through the associated event identifier. When the current project's valid event chain changes or reaches a preset monitoring period, risk feature extraction, historical risk case retrieval, constraint verification, and suggestion output are re-executed.

[0020] In one optional implementation, step S2 includes: encoding the contract text and contract terms, as well as the risk descriptions and historical handling measures in historical risk cases, into 768-dimensional text vectors and writing them into a text vector set; encoding and normalizing the financial expenditure data, working hour data, progress data, and acceptance data, as well as the financial, working hour, progress, and acceptance fields corresponding to historical risk cases according to a preset field list to form 32- to 128-dimensional structured feature vectors and writing them into a structured feature vector set; and encoding historical risk cases into 8-dimensional risk feature vectors and writing them into a risk feature vector set.

[0021] HNSW indexes are established for the text vector set, structured feature vector set, and risk feature vector set respectively, ensuring that the vector dimensions within the same HNSW index remain consistent. Structured feature vectors of different dimensions are written into independent structured feature sub-indexes. In the multi-path recall implementation, text query vectors, structured query vectors, and risk query vectors consistent with each index dimension are generated based on the current project's valid event chain. Index records for each historical risk case are associated with the source project event through a unified project event identifier, and candidate results from each path are merged using historical risk case identifiers. After normalizing the similarity of each path, the merged candidate results are sorted according to a preset fusion weight.

[0022] In one optional implementation, both the risk query vector and the risk feature vector corresponding to historical risk cases include project size, project type, project duration, team size, technology stack complexity, geographical distribution, customer industry, and historical deviation rate. Risk categories are determined based on overpayment, underpayment, schedule deviation, quality anomalies, personnel shortages, or changes in the external environment within the current project's valid event chain. Then, based on the risk category, cost deviation rate, schedule deviation rate, or time deviation rate is selected as the historical deviation rate.

[0023] In one optional implementation, the similarity threshold for historical risk cases is initially set to 0.8; when there are fewer than three valid historical risk cases with a similarity of not less than 0.8, the similarity threshold is reduced to 0.7. Historical risk cases with a similarity of not less than 0.8 are designated as preferred cases, and historical risk cases with a similarity of not less than 0.7 but less than 0.8 are designated as reference cases, and reference cases are restricted from being used alone as the basis for generating final risk management recommendations. When no preferred cases exist, only reference cases, their corresponding similarities, and manual confirmation tags are output. The initial candidate cases obtained through metadata filtering and similarity retrieval are sorted in two stages, and the top-ranked historical risk cases are determined as candidate historical risk cases.

[0024] In one optional implementation, step S4 includes: extracting contract amount, payment nodes, delivery milestones, breach of contract clauses, and acceptance criteria from the contract text and supplementary agreement text to form a structured rule template containing contract number, clause number, clause version, effective period, constraint object, constraint type, comparison relationship, and constraint value; matching actual project expenditures with the structured rule template according to the occurrence time and expense category of actual project expenditures to determine the revenue attribution period and cost collection category, and identifying overpayment, underpayment, or project events that deviate from the contract agreement.

[0025] Historical risk mitigation measures in candidate risk cases are parsed into candidate suggestion parameters. These parameters include at least the action type, target audience, estimated cost, estimated duration, number of personnel, skill requirements, subcontracting, and impact milestones. Based on the constraint attributes of each contract clause in the structured rule template, the corresponding contract clauses are set as hard or soft constraints for the candidate risk mitigation suggestions. Contractual constraints include the upper limit of contract amount, payment terms, delivery milestones, acceptance criteria, and breach restrictions. Resource constraints include budget margin, duration margin, and personnel availability. Candidate suggestion parameters are validated item by item based on contractual and resource constraints, and the priority of corresponding candidate risk mitigation suggestions is reduced according to the number and degree of violation of soft constraints.

[0026] In one optional implementation, the earned value, planned value, actual cost, number of days the project has been executed, total planned days of the project, remaining budget amount, and current risk exposure value are obtained at each sampling time within a continuous preset window, and a project cost feature sequence is formed according to the sampling time order. The project cost feature sequence is input into a cost prediction model including a Transformer encoder, a cost sequence regression output layer, and a cost overrun probability classification output layer to obtain a cost prediction sequence and cost overrun probability within a future preset time range. The cost prediction sequence and cost overrun probability are written into the current project valid event chain, and the cost overrun probability is used as an auxiliary input for risk category determination and two-stage ranking of candidate historical risk cases, without changing the dimension of the 8-dimensional risk query vector.

[0027] After obtaining new actual cost data, a corresponding new version of the project event is generated, and the input data and corresponding vector index of the cost prediction model are updated to ensure that the data version used for cost prediction, the cost event version in the current project's valid event chain, and the auxiliary input used for risk analysis remain consistent.

[0028] In one alternative implementation, projects with a cumulative completion rate exceeding 80% or those entering the acceptance and settlement phase are prioritized for classification as late-stage projects. Among projects not classified as late-stage, those with a cumulative completion rate of no less than 30% and no more than 80% and currently in the implementation or delivery phase are classified as mid-stage projects, and the remaining projects are classified as early-stage projects. The weights of schedule, cost, risk, and quality indicators are determined based on the project's stage. These indicators are then standardized, and the project execution health is calculated using the following formula:

[0029] ;

[0030] in, =1, 2, 3, and 4 correspond to schedule indicators, cost indicators, risk indicators, and quality indicators, respectively. For the first The weight of each indicator For the first The standardized value of each indicator.

[0031] The monitoring platform's heartbeat status, service online status, and backup switchover status are acquired through independent heartbeat detection nodes, and its availability is determined based on these metrics. If the monitoring platform failure lasts longer than a preset failure threshold, its availability is set to unavailable. The last valid value, calculation time, and data version of the project execution health are retained, and the project execution health is marked as temporarily unupdateable. Project risk alerts are generated based on the project execution health, and platform operation and maintenance alerts are generated based on the monitoring platform's availability.

[0032] The present invention also provides a project risk monitoring system based on a versioned project event chain, including a data acquisition module, which is communicatively connected to an external contract business system, a financial business system, and a project management business system.

[0033] The data acquisition module is connected to the event fusion and index management module. The event fusion and index management module is used to generate a unified project event identifier based on the acquired data, establish a project event version chain and a current project valid event chain, establish text vector index, structured feature vector index and risk feature vector index respectively, and incrementally update the corresponding vector index when a project event is added, its content is changed or its status is changed.

[0034] The event fusion and index management module is connected to the risk case retrieval module. The risk case retrieval module is used to extract risk features from the current project's valid event chain and generate risk query vectors. It performs vector similarity retrieval and sorting on historical risk cases that have been filtered by metadata to obtain candidate historical risk cases.

[0035] The event fusion and index management module is also connected to the contract rule processing module. The contract rule processing module is used to extract the contract amount, payment node, delivery milestone, breach of contract clause and acceptance criteria from the current valid contract version to form a structured rule template containing the contract number, clause number, clause version and effective period.

[0036] The risk case retrieval module and the contract rule processing module are jointly connected to the constraint verification module. The constraint verification module is used to generate candidate risk handling suggestions based on the historical handling measures in the candidate historical risk cases, and to perform hard constraint verification and soft constraint verification on the candidate risk handling suggestions based on the structured rule template, budget margin, schedule margin and personnel availability.

[0037] The constraint verification module is connected to the suggestion traceability output module. The suggestion traceability output module is used to output risk handling suggestions that have passed the constraint verification, and to store the correspondence between the risk handling suggestions and the project event version, historical risk case identifier, contract clause version and constraint verification results.

[0038] The event fusion and index management module is also connected to a health monitoring module. The health monitoring module is used to calculate the project execution health based on the current project's valid event chain, determine the monitoring platform's availability based on the monitoring platform's heartbeat status, service online status, and backup switch status, and output project risk alarms and platform operation and maintenance alarms respectively.

[0039] The present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the processor executes the computer program, it implements the above-described project risk monitoring method based on a versioned project event chain.

[0040] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the above-described project risk monitoring method based on a versioned project event chain is implemented.

[0041] Compared to existing methods of storing and processing contract, financial, progress, and acceptance data separately, this invention associates records from different business systems as project events by using a unified project event identifier, and constructs a current project valid event chain using version number, effective time, and valid status. This enables risk analysis to be based on current valid business facts, reducing the likelihood of old contract terms, old progress statuses, or duplicate records continuing to be involved in the retrieval.

[0042] Meanwhile, text data, structured data, and historical risk cases are each indexed with consistent dimensions, and records in different indexes are associated with a unified project event identifier. When a project event is added or changed, only the corresponding index is incrementally written or updated, and the original version of the index record is marked as invalid, thereby maintaining the correspondence between the project event version and the valid state of the index.

[0043] Furthermore, the risk case retrieval first filters cases based on industry, project type, risk category, case validity status, and time range, then performs vector similarity retrieval and sorting, and classifies the recalled cases into preferred and reference levels to reduce the possibility that low-relevant cases introduced by expanding the search scope when the number is insufficient will directly participate in the final suggestion generation.

[0044] In addition, candidate risk management recommendations are jointly verified by the current valid contract version and the current project resource status before output. Recommendations that violate hard constraints are eliminated, while recommendations that violate soft constraints are downgraded and the reasons for the conflict are recorded. At the same time, the correspondence between recommendations and project event versions, historical risk cases, contract terms versions and verification results is saved to facilitate subsequent review.

[0045] Project execution health and monitoring platform availability are calculated separately. In the event of a temporary platform failure or temporary inability to update project data, the last valid value of project execution health and its data version are retained to avoid treating platform malfunctions directly as project execution anomalies. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the project risk monitoring method based on a versioned project event chain provided in an embodiment of the present invention;

[0047] Figure 2 This is a schematic diagram of the structure of a project risk monitoring system based on a versioned project event chain provided in an embodiment of the present invention;

[0048] Figure 3 This is a schematic diagram illustrating the risk case retrieval, constraint verification, and suggestion output provided in an embodiment of the present invention.

[0049] Figure 4 This is a schematic diagram illustrating the separation of project health and platform availability evaluation provided in an embodiment of the present invention.

[0050] Figure 5 This is a schematic diagram illustrating the writing of cost prediction results into the event chain and the updating of risk analysis inputs in an embodiment of the present invention. Detailed Implementation

[0051] Example 1

[0052] This embodiment provides a project risk monitoring method based on a versioned project event chain.

[0053] like Figure 1 As shown, this method is executed by the project monitoring system. The system first obtains multi-source project data from the contract business system, financial business system, and project management business system. Then, it generates a unified project event identifier, constructs the current project's valid event chain, and establishes text vector indexes, structured feature vector indexes, and risk feature vector indexes respectively. Based on this, risk features are extracted from the current project's valid event chain, candidate historical risk cases are retrieved, and candidate risk handling suggestions are formed based on historical handling measures. The current valid contract version and current project resource status are then used to constrain and verify the candidate risk handling suggestions. Finally, the system outputs risk handling suggestions that pass the verification or constraint conflict information.

[0054] Specifically, the contract business system provides the main contract, supplementary agreement, contract change order, contract amount, payment node, delivery milestone, breach of contract clause and acceptance criteria; the financial business system provides invoice number, payment number, invoice amount, payment amount, expense item, invoice time, payment time, budget amount, actual expenditure and audit status; the project management business system provides project number, task number, milestone number, planned time, actual completion time, completion percentage, acceptance results, staffing and work hour records.

[0055] For data that can be read through business interfaces, the project monitoring system directly obtains structured records via application programming interfaces (APIs). For scanned contracts, image invoices, and paper acceptance materials, text content and table fields are obtained through optical character recognition (OCR) and layout analysis. Each original record retains at least the source system, source business primary key, collection time, and data version. Data obtained through OCR retains its source and pending verification status until reviewed, and does not directly replace data that has already been reviewed or signed and is in effect.

[0056] After obtaining the original records, the project monitoring system prioritizes deterministic association of records in different business systems based on the project number, contract number, and business document number. For example, if an invoice record contains a contract number, the invoice record is associated with the corresponding contract and project; if a payment record contains an invoice number, the payment record is further associated with the corresponding invoice, contract, and project. Records that have already formed a unique correspondence through stable business primary keys are not subject to candidate association.

[0057] In the absence of a stable business primary key, the project monitoring system generates candidate association records based on the business entity, amount, event time, and event type, and calculates the association confidence level of these candidate records. Business entities include contract entities, invoicing entities, payment entities, receiving entities, or project undertaking entities; event types include contract signing, contract modification, invoicing, payment, progress changes, acceptance, and work hour reporting. When the association confidence level reaches a preset association threshold, the record is associated with the corresponding project event; when the association confidence level is below the preset association threshold, the candidate association record is set to a pending confirmation status, preventing it from entering the current project's valid event chain.

[0058] In one implementation, the association confidence level is normalized to between 0 and 1, and the preset association threshold is set to 0.85. Automatic association is performed when the association confidence level is not lower than 0.85; otherwise, manual verification is initiated. This association threshold is determined based on the combined result of association precision and recall in the validation data.

[0059] Subsequently, the project monitoring system performs data deduplication within the same source system. When a source business primary key exists, duplicate records are identified based on the source system and the source business primary key. When a stable business primary key is missing, a key field summary is generated based on the business entity, amount, event time, and event type, or a file hash is generated based on the original file content to identify duplicate imported contracts, supplementary agreements, invoices, acceptance records, or other business documents. Records identified as duplicates are not used to generate duplicate project events, but their import source and collection time are retained.

[0060] When different source systems provide different data for the same field, the current valid value is determined sequentially based on the signed and effective contract or supplementary agreement, the audited financial system data, the audited project management system data, and the data imported via optical character recognition. When data at the same level conflicts, the record with the later effective date and an approved status is prioritized. The project monitoring system simultaneously saves the conflicting field, the original value from each source, the current valid value, and the conflict resolution result for subsequent verification of the source of the current valid value.

[0061] After completing association, deduplication, and conflict handling, the project monitoring system generates a unified project event identifier based on the project number, contract number, business document number, event time, and event type. Each project event includes at least the unified project event identifier, project number, contract number, business document number, event type, source system, source business primary key, version number, effective time, expiration time, and validity status. The unified project event identifier is used to link records of the same business transaction across the contract business system, financial business system, and project management business system.

[0062] The unified project event identifier serves as the event entity identifier for the same business matter. When the business matter is first identified, the event time is used to generate the unified project event identifier. Subsequent changes or replacements belonging to the same business matter use this unified project event identifier, and project event version identifiers are generated separately. The project event version identifier includes at least the unified project event identifier and the version number, and also stores the identifier of the preceding version. Related event identifiers are also stored between contract, invoice, payment, progress, acceptance, and work hour events to record business relationships such as contract-invoice-payment, task-progress-acceptance, etc. Therefore, the current project's valid event chain includes both version inheritance relationships within the same business matter and business relationships formed between different business matters based on event time.

[0063] The main contract, supplementary agreements, and contract amendments form a project event version chain based on version relationships. Event version V1 and event version V2 represent historical versions that have been superseded by subsequent versions, while event version V3 represents the currently valid version. Version inheritance relationships and status update relationships are maintained between different versions.

[0064] Supplementary agreements only cover explicitly amended contract terms; terms not amended by the supplementary agreement are inherited from the previous valid contract version. For example, the first version of the main contract stipulated a total contract amount of RMB 10 million, an initial payment of 30%, and four delivery milestones; the subsequent second version of the supplementary agreement only adjusted the initial payment to 20%. The project monitoring system generates a second-version contract event, marking the 30% payment clause in the first version and its corresponding index record as invalid, and setting the 20% payment clause in the second version as the currently valid clause; the total contract amount and the four delivery milestones remain unchanged and are inherited from the first version.

[0065] When the schedule, payment plan, or acceptance requirements change, the project monitoring system generates a new version of the corresponding project event and changes the valid status of the replaced version to invalid. Historical versions are retained for auditing, version comparison, and historical state restoration, but are not included in the current risk analysis by default.

[0066] The project monitoring system constructs a valid event chain for the current project based on the source, version, effective time, and valid status of each project event. If the current time falls between the effective time and the expiration time of a project event, and the event's valid status is valid, that event enters the current project's valid event chain. Project events without an expiration time continue to enter the current project's valid event chain as long as their valid status is valid.

[0067] Once the current project's effective event chain is formed, the project monitoring system performs vectorization processing on the text data, structured data, and historical risk cases in the project events.

[0068] The contract text and contract terms, as well as risk descriptions and historical handling measures from historical risk cases, are encoded into 768-dimensional text vectors using a text embedding model and written into a text vector set. Each text vector record stores at least the vector identifier, uniform project event identifier, project number, contract number, clause number, clause version, effective period, validity status, and, when corresponding to a historical risk case, the historical risk case identifier.

[0069] Financial expenditure data, working hours data, progress data, and acceptance data, as well as the financial, working hours, progress, and acceptance fields corresponding to historical risk cases, are categorized and normalized according to a preset field list to form structured feature vectors. In one implementation, projects with a small number of fields use 32-dimensional structured feature vectors; projects containing financial, progress, and personnel data use 64-dimensional structured feature vectors; and projects containing financial, progress, personnel, quality, and acceptance details use 128-dimensional structured feature vectors. The 32-dimensional, 64-dimensional, and 128-dimensional structured feature vectors are written into mutually independent structured feature sub-indexes, and the vector dimensions within the same structured feature sub-index remain consistent.

[0070] Historical risk cases are encoded as an 8-dimensional risk feature vector. The eight dimensions are, in order: project size, project type, project duration, team size, technology stack complexity, geographical distribution, client industry, and historical deviation rate. Project type, geographical distribution, and client industry are encoded using Bayesian smoothing target coding based on historical risk occurrence rates, and the encoding results are normalized to 0 to 1. Technology stack complexity is determined to be on a scale of 1 to 5 based on the number of technical components, the number of external interfaces, and the proportion of custom development, and then normalized to 0 to 1.

[0071] The historical deviation rate is calculated using the following formula:

[0072] ;

[0073] in, Historical deviation rate This is the actual value. For planned values, Take 10 -6 The meanings of A and P are selected according to the risk category: cost risk uses actual cost and planned cost, schedule risk uses actual schedule and planned schedule, and time risk uses actual time and planned time; the historical deviation rate calculation result is truncated to 0 to 1.

[0074] The project monitoring system establishes HNSW indexes for the text vector set, structured feature vector set, and risk feature vector set, respectively. Vectors within the same HNSW index maintain a consistent dimension; 768-dimensional text vectors, structured feature vectors of different dimensions, and 8-dimensional risk feature vectors are not written into the same index, thus avoiding direct comparison of vectors with different dimensions and business meanings in the same distance space.

[0075] In the multi-path recall implementation, a 768-dimensional text query vector, a structured query vector with dimensions consistent with the selected structured feature sub-index, and an 8-dimensional risk query vector are generated based on the current project's valid event chain. Historical risk case records in the text vector index, structured feature vector index, and risk feature vector index are associated with the source project event through a unified project event identifier, and candidate results for the same historical risk case are merged using the historical risk case identifier. After the similarity of each path is normalized, the merged candidate results are sorted according to a preset fusion weight.

[0076] In one implementation, the overall score is calculated according to the following formula:

[0077] ;

[0078] in, For the overall score, The normalized text similarity. The normalized structural feature similarity. This represents the normalized risk feature similarity. If a candidate result lacks one of its similarity scores, the weights corresponding to the existing similarities are renormalized before calculating the overall score.

[0079] When a new project event is added, only the new project event is written to its corresponding vector set and index. For example, when a new payment event is added, the structured feature vector index is updated; when a supplementary agreement is added, the text vector index is updated, and the system determines whether to update the structured feature vector index synchronously based on whether the supplementary agreement changes the budget, payment, or schedule fields.

[0080] When the content or status of a project event changes, a new version of the project event is generated, the original version and its index records are marked as invalid, and the new version of the project event is written to the corresponding index. Invalid index records are excluded by default during retrieval. The project monitoring system also saves the business data update time and the index completion time to determine the incremental index update delay.

[0081] When the current project's effective event chain changes or reaches the preset monitoring period, the project monitoring system re-extracts risk characteristics and re-executes historical risk case retrieval, candidate risk handling suggestion generation, constraint verification, and suggestion output; after the new handling result formed by manual confirmation is written into the event chain, the above re-execution process is also triggered.

[0082] After completing the construction of the current project's valid event chain and vector index, the project monitoring system extracts project size, project type, project cycle, team size, technology stack complexity, geographical distribution, customer industry, and historical deviation rate from the current project's valid event chain, and generates risk query vectors according to the same field order, category coding, missing value handling method, and normalization parameters as historical risk cases.

[0083] like Figure 3 As shown, before performing vector similarity retrieval, the project monitoring system first determines the risk category based on events such as overpayment, underpayment, schedule deviation, quality anomalies, personnel shortages, or changes in the external environment within the current project's valid event chain. When multiple risk categories exist for the same project, corresponding risk retrieval tasks are generated for each category. Subsequently, historical risk cases are filtered for metadata according to industry, project type, risk category, case validity status, and time range. Risk categories include cost overruns, schedule delays, substandard quality, personnel changes, and changes in the external environment, and can be further subdivided according to the risk's cause. Historical risk cases that have expired or exceeded the preset time range are not included in the retrieval set.

[0084] For historical risk cases filtered by metadata, the cosine similarity between the risk query vector and the risk feature vector is calculated using the following formula:

[0085] ;

[0086] in, This is the risk query vector for the current project. This is the risk feature vector corresponding to historical risk cases.

[0087] The initial similarity threshold for historical risk cases is set to 0.8. When there are at least 3 valid historical risk cases with a similarity of not less than 0.8, they are set as preferred cases; when there are fewer than 3 valid historical risk cases with a similarity of not less than 0.8, the similarity threshold is reduced to 0.7, and historical risk cases with a similarity of not less than 0.7 and less than 0.8 are set as reference cases.

[0088] Reference-level cases cannot be used alone as the basis for generating final risk management recommendations. Reference-level cases, together with preferred-level cases, can provide risk background or supplementary measures, and participate in candidate recommendation generation after a two-stage ranking and constraint verification. If no preferred-level cases exist, only reference-level cases, corresponding similarity scores, and manual confirmation tags are output; no directly executable risk management recommendations are automatically generated. The initial recall quantity can be set to 20. The two-stage ranking comprehensively considers case similarity, case time, historical management results, case completeness, project scale differences, and cost overrun probability to obtain candidate historical risk cases.

[0089] Candidate historical risk cases must include at least the case identifier, risk category, risk characteristics, risk occurrence process, historical mitigation measures, execution costs, implementation time, execution results, applicable conditions, and effective status. The project monitoring system generates candidate risk mitigation recommendations based on the historical mitigation measures and execution results in the candidate historical risk cases, and saves the source case identifier, case similarity, and case level for each candidate risk mitigation recommendation.

[0090] Historical response measures from candidate historical risk cases are parsed into candidate suggestion parameters using field extraction rules or a generation model with fixed output fields. Candidate suggestion parameters must include at least the candidate suggestion identifier, action type, target audience, estimated cost, estimated duration, number of personnel, skill requirements, subcontracting status, impact milestones, preconditions, and source case identifier. The generation model with fixed output fields takes historical response measures, execution costs, implementation time, applicable conditions, and a current project risk description as input, and outputs only the aforementioned preset fields. After output, field type, value range, and mandatory field validation are performed. If necessary parameters are missing and cannot be determined from the source case, the candidate suggestion is set to await manual confirmation.

[0091] Meanwhile, the project monitoring system extracts contract amount, payment milestones, delivery milestones, breach of contract clauses, and acceptance criteria from the currently valid contract version to form a structured rule template. The structured rule template includes contract number, clause number, clause version, effective period, constraint object, constraint type, comparison relationship, and constraint value.

[0092] Actual project expenditures are matched against structured rule templates based on their occurrence time and expense categories to determine the revenue attribution period and cost collection category. An overpayment event is generated when the payment amount exceeds the cumulative payment amount allowed by the current valid contract version; an underpayment event is generated when a payment milestone is reached but no corresponding payment record is generated; and a deviation from contractual agreements is generated when the actual expenditure's expense category, payment terms, milestones, or acceptance status are inconsistent with the contractual stipulations. These risk events are written into the current project's valid event chain before the next risk retrieval to determine the risk category and risk query content.

[0093] Return on investment is calculated using the following formula:

[0094] ;

[0095] Net present value is calculated using the following formula:

[0096] ;

[0097] in, For the first Net cash flow during the period The discount rate is... This is the initial investment amount. The evaluation period is specified. The rate of return on investment and net present value are retained as results of the project's financial analysis and do not replace the constraint verification of candidate risk mitigation recommendations.

[0098] Contract clauses in the structured rule template are set as hard or soft constraints according to their constraint attributes. Contract amount limits, payment terms, delivery milestones that must not be violated, acceptance standards, behaviors explicitly prohibited by the contract, and restrictions on breach of contract are set as hard constraints; personnel allocation that can be adjusted with approval, non-mandatory schedule arrangements, and budget reservation conditions are set as soft constraints.

[0099] Project resource constraints include budget margin, schedule margin, and personnel availability. Budget margin is determined based on current effective budget events and confirmed expenditure events; schedule margin is determined based on current effective delivery deadlines, estimated completion time, and time required for remaining tasks; personnel availability is determined based on personnel scheduling, allocated work hours, and skill requirements.

[0100] Candidate suggestion parameters, contractual constraints, and resource constraints are all included in constraint validation. For numerical constraints, the estimated cost, estimated duration, and number of personnel in the candidate suggestion parameters are compared item by item with the comparison relationships and constraint values ​​in the structured rule template. For categorical constraints, the action type, whether it is subcontracted, the target, and the impact milestones are matched item by item with the contractual prohibited behaviors and acceptance conditions. For example, if the subcontracting field of a candidate suggestion is "yes" and the currently valid contract terms prohibit subcontracting of core work, it is determined that a hard constraint is violated. Candidate risk management suggestions that violate hard constraints are eliminated; candidate risk management suggestions that do not violate hard constraints but violate soft constraints are retained, and their ranking priority is reduced based on the number of soft constraint violations and the normalized deviation of estimated cost, estimated duration, or number of personnel relative to the resource margin. At the same time, conflict reasons such as insufficient budget, tight schedule, or insufficient personnel are recorded.

[0101] For example, the current project is a cross-regional software implementation project with a team of 15 people. The actual progress is 8% behind schedule, with 45 days remaining. Historical measures provided by candidate risk cases include adding two implementation personnel, rescheduling some non-critical functions to later batches, and bringing in external vendor assistance. The current valid contract stipulates that core implementation work cannot be subcontracted, and the budget margin can only support adding one more implementation personnel. Bringing in external vendor assistance violates hard constraints and is therefore eliminated; adding two implementation personnel exceeds the budget margin, resulting in a budget conflict and a lower priority; rescheduling some non-critical functions to later batches does not violate hard constraints, but may compress subsequent delivery times, thus lowering the priority.

[0102] The risk handling recommendations that pass the constraint validation are correlated with the project event version, historical risk case identifier, case similarity, case level, contract number, clause number, contract clause version, and constraint validation results. When no candidate risk handling recommendations pass the hard constraint validation, no directly executable recommendations are output; instead, constraint conflict information and a manual confirmation mark are output.

[0103] Furthermore, the project monitoring system acquires earned value, planned value, actual cost, number of days the project has been executed, total planned days, remaining budget, and current risk exposure value for each sampling moment within a continuous preset window. This data is then used to form a project cost feature sequence of length L, with each sampling moment containing seven features, arranged in chronological order of sampling time. L is pre-set based on the project data collection cycle and prediction time range; missing sampling moments are filled in according to the same missing value handling rules as in the training phase.

[0104] like Figure 5As shown, the project cost feature sequence is input into the cost prediction model. The cost prediction model includes an input mapping layer, a positional encoder, a Transformer encoder, a cost sequence regression output layer, and a cost overrun probability classification output layer. The input mapping layer maps the seven features at each sampling time to a unified hidden dimension. The positional encoder preserves the sampling time order. The Transformer encoder extracts cross-time-time correlation features. The cost sequence regression output layer outputs the cost prediction sequence within a preset future time range. The cost overrun probability classification output layer outputs the probability that the predicted cost exceeds the current effective budget. During training, the weighted sum of the regression loss between the cost prediction sequence and the actual cost sequence, and the classification loss between the cost overrun label and the cost overrun probability, is used as the training objective.

[0105] In one implementation, the prediction timeframe is the next 14 days; short-cycle projects can be set to the next 7 days, and long-cycle projects can be set to the next 30 days. One training configuration for the cost prediction model is: batch size 64, learning rate 1×10⁻⁶. -3 The training lasted for 200 epochs, using the AdamW optimizer and a cosine annealing learning rate scheduling strategy. Prediction error was evaluated using mean absolute percentage error.

[0106] Cost prediction sequences and cost overrun probabilities are written as predicted project events into the current project's valid event chain. Predicted project events store the prediction generation time, prediction coverage, input project event version, and model version. The cost overrun probability is used to determine whether a cost overrun risk category has formed and serves as an auxiliary input for the two-stage ranking of candidate historical risk cases. It is not concatenated to the 8-dimensional risk query vector, thus maintaining the consistency of the dimensions between the current project's risk query vector and the risk feature vectors of historical risk cases.

[0107] After obtaining new actual cost data, a corresponding new version of the actual cost event is generated, the project cost feature sequence and the input data of the cost prediction model are updated, and the structured feature vector index is incrementally updated. The original predicted events are saved for error verification, and the latest valid predicted events are used for the current risk analysis.

[0108] like Figure 4 As shown, the project monitoring system also determines the project execution health and monitoring platform availability. The system prioritizes projects with a cumulative completion rate higher than 80% or those entering the acceptance and settlement phase as late-stage projects. Among projects not classified as late-stage, those with a cumulative completion rate of no less than 30% and no more than 80% and in the implementation or delivery phase are classified as mid-stage projects. The remaining projects are classified as early-stage projects. By sequentially judging late-stage, mid-stage, and early-stage projects, the criteria for determining these three phases do not overlap.

[0109] Project execution health is calculated using the following formula:

[0110] ;

[0111] in, =1, 2, 3, and 4 correspond to schedule indicators, cost indicators, risk indicators, and quality indicators, respectively. For the first The weight of each indicator For the first The standardized values ​​of the indicators; the schedule indicators adopt the schedule performance index. , Cost indicators adopt the cost performance index. , ,in To earn value, For the value of the plan, This represents the actual cost. Risk exposure is calculated by summing the products of the probability of occurrence and the degree of impact of the current effective risk events, and then normalizing the result to between 0 and 1.

[0112] Table 1. Dynamic Weight Settings for Project Phases

[0113] Project Phase Schedule indicator weights Cost indicator weight Risk indicator weights Quality indicator weights In the early stages, 0.4 0.2 0.2 0.2 In the middle period, 0.3 0.3 0.2 0.2 Later, 0.2 0.4 0.2 0.2

[0114] Project phase weights are satisfied:

[0115] ;

[0116] ;

[0117] ;

[0118] ;

[0119] For positive indicators such as schedule performance index and cost performance index, the standardized values ​​are calculated according to the following formula:

[0120] ;

[0121] For inverse indicators such as risk exposure, the standardized value is calculated using the following formula:

[0122] ;

[0123] in, This is the preset upper limit for risk exposure.

[0124] Quality indicators are calculated using the following formula:

[0125]

[0126] in, To achieve the qualified product rate, Subtract the customer complaint rate from 1. It is 1 minus the rework rate.

[0127] When the project execution health score is not lower than 0.80, the project status is determined to be good; when the project execution health score is not lower than 0.60 but lower than 0.80, the project status is determined to be acceptable, and a deviation prompt is output; when the project execution health score is lower than 0.60, the project status is determined to be abnormal, and a project risk alarm is generated.

[0128] Availability failures of the monitoring platform include power outages, network outages, server hardware failures, database service crashes, unavailability of critical middleware, core switch failures, and domain name resolution service interruptions. These failures are identified by independent heartbeat detection nodes.

[0129] The availability of the monitoring platform is determined by the following formula:

[0130] ;

[0131] in, To monitor platform availability, This is an availability correction factor for the monitoring platform when it completes switching or recovery within a preset fault threshold.

[0132] Table 2. Backup Switchover Status and Monitoring Platform Availability Correction Factors

[0133] Backup switching status Correction coefficient Automatic primary / standby failover with a failover time not exceeding 5 seconds. 1.0 Automatic or manual switching, with a switching time greater than 5 seconds but not exceeding 30 seconds. 0.8 No backup and recovery plan has been deployed and the main service is running normally. 0.6

[0134] The preset fault threshold is set to 30 seconds. If a monitoring platform failure occurs and switching or recovery is completed within 30 seconds, the correction coefficient is determined according to Table 2. If the failure lasts for more than 30 seconds, the availability of the monitoring platform will be set to 0, and a platform operation and maintenance alarm will be generated. At this time, the last valid value, calculation time, and data version of the project execution health will be retained, and the project execution health will be marked as temporarily unupdateable, instead of directly setting the project execution health to 0.

[0135] After the monitoring platform is restored, it acquires new data generated by different business systems during the fault period, generates corresponding project events and their versions for the new data, updates the corresponding vector index, and then re-executes risk feature extraction, historical risk case retrieval, constraint verification, and project execution health calculation based on the updated current project valid event chain.

[0136] In one verification implementation, the server uses an Intel Xeon Silver 4210 processor, 64GB of memory, and 1TB of solid-state storage. The operating system is Ubuntu Server 22.04 LTS, and the program environment is Python 3.11 and PyTorch 2.3.1. The text embedding model is bge-base-zh-v1.5. In the HNSW parameters, M is 32, efConstruction is 200, efSearch is 64, the initial recall is 20, and the concurrent query count is 50.

[0137] The test data comes from 80 anonymized historical projects from January 2022 to December 2025, including 32 information technology projects, 28 engineering projects and 20 manufacturing projects, resulting in 100,000 project event records and 5,000 historical risk cases.

[0138] Table 3 Test Dataset Partitioning

[0139] Data set Number of projects Number of project event records Number of risk cases training set 48 Approximately 60,000 3000 copies Validation set 12 Approximately 15,000 800 copies test set 20 Approximately 25,000 1200 copies

[0140] Data is organized chronologically by project completion date, with data from the same project entering only one dataset. The category encoder, normalization parameters, fusion weights, and retrieval thresholds are determined solely using the training and validation sets.

[0141] The retrieval performance comparison uses a relational database sequential nearest neighbor retrieval method. This method stores the same 8-dimensional risk features and metadata as in this embodiment in a relational database. First, it performs SQL filtering based on the same industry, project type, risk category, case validity status, and time range. Then, the application reads all filtered risk cases one by one, calculates the cosine similarity for each case, and sorts them to obtain the top 20 results. This comparison method does not establish HNSW or other approximate nearest neighbor indexes.

[0142] Cost forecast comparisons were conducted using four methods: the most recent three-period moving average, linear regression, ARIMA, and XGBoost. All methods used the same dataset, input features, and a 14-day evaluation interval. Manual cost estimates were provided by project managers based on current cost ledgers, remaining budget, actual progress, and historical experience, resulting in cost estimates for the next 14 days.

[0143] Risk warning comparison adopts a manual weekly report review method, in which project managers check project costs, schedules, quality and personnel status every week and record the time of the first risk warning.

[0144] Risk management recommendations suggest adopting a direct generation method without historical risk cases or contractual constraint verification. This method only inputs the current project risk description into the same generation model, without providing historical risk cases, currently valid contract terms, budget margins, schedule leeway, or personnel availability, and does not perform hard constraint verification or soft constraint verification.

[0145] Table 4. Verification Results of Search, Cost Prediction, and Risk Warning

[0146] Validate Project This embodiment Comparison method Verification results Response time for retrieving 100,000 records HNSW retrieval takes 40 to 60 milliseconds. The sequential nearest neighbor lookup time for relational databases is 180 milliseconds. HNSW's retrieval speed is 3 to 4.5 times faster than the control method. 14-Day Cost Forecast MAPE Transformer is 3.2%. The most recent three-period moving average is 11.6%, linear regression is 10.8%, ARIMA is 9.4%, XGBoost is 6.7%, and manual estimation is 12.0%. The Transformer reduces the error by 52.2% compared to XGBoost. Risk warning lead time On average, 16 days in advance Manual weekly report review is on average 5 days ahead of schedule The average lead time increased by 11 days. Risk warning recall rate 87% Human experience-based judgment accounted for 62%. Increase by 25 percentage points

[0147] The consistency evaluation of risk management recommendations involved 300 risk management recommendations drawn from 20 test projects. These recommendations were independently marked by three evaluators with project management experience based on historical execution results, current contract terms, and resource feasibility. The majority opinion was used as the evaluation benchmark.

[0148] Table 5 Consistency Verification Results of Risk Management Recommendations

[0149] Recommended generation method Number of recommendations consistent with the evaluation benchmark Consistency Direct generation method without historical risk cases and contract constraint verification 216 articles 72.0% The risk case retrieval and constraint verification method in this embodiment 281 items 93.7%

[0150] Through this embodiment, multi-source project data can form a valid event chain for the current project with clear versions. Different types of data are written into corresponding vector indexes and incrementally updated when project events change. Historical risk cases are filtered by metadata, retrieved by similarity, and sorted by hierarchy to form candidate measures. The candidate measures are then verified by the current contract and resource conditions. Cost prediction results are used in risk analysis with project events of different versions. The health of project execution and the availability of the monitoring platform are evaluated separately, thus forming a continuous and traceable processing relationship between data versions, retrieval basis, constraint basis, suggested output, and operating status.

[0151] Example 2

[0152] This embodiment provides a project risk monitoring system based on a versioned project event chain.

[0153] like Figure 2 As shown, the project risk monitoring system includes a data acquisition module, an event fusion and index management module, a risk case retrieval module, a contract rule processing module, a constraint verification module, a suggestion tracing output module, and a health monitoring module. Figure 2 The connections between the modules are shown according to the data transmission direction. The relationships between the text vector index, structured feature vector index, risk feature vector index, and event fusion and index management modules are also shown.

[0154] The data acquisition module is positioned between the external business system and the event fusion and index management module. The data acquisition module communicates with the external contract business system, financial business system, and project management business system, and also connects to the event fusion and index management module for data exchange.

[0155] The data acquisition module is used to obtain contract and supplementary agreement data from the contract business system, invoice and payment data from the financial business system, and progress, acceptance, and work hour data from the project management business system. The data acquisition module sends the source system, source business key, acquisition time, and data version along with the raw data to the event fusion and index management module.

[0156] The event fusion and index management module receives data output from the data acquisition module, generates a unified project event identifier based on the project number, contract number, business document number, event time, and event type, and establishes a project event version chain and a current project valid event chain based on the source, version, effective time, and validity status of the project event.

[0157] The event fusion and index management module manages the text vector index, structured feature vector index, and risk feature vector index respectively. The text vector index is used to store the text vectors corresponding to the contract text and contract terms; the structured feature vector index is used to store the structured feature vectors corresponding to financial expenditures, working hours, progress, and acceptance data; and the risk feature vector index is used to store the risk feature vectors corresponding to historical risk cases.

[0158] When a new project event is added, the event fusion and index management module sends a write request to the corresponding index based on the data type of the project event. When the content or status of a project event changes, the event fusion and index management module generates a new version of the project event, marks the original version of the project event and its index records as invalid, and sends an incremental update request to the corresponding index.

[0159] The risk case retrieval module is connected to the event fusion and index management module. The risk case retrieval module extracts project size, project type, project cycle, team size, technology stack complexity, geographical distribution, customer industry, and historical deviation rate from the current project's valid event chain to generate a risk query vector, and retrieves historical risk cases filtered by metadata from the risk feature vector index.

[0160] The risk case retrieval module sequentially performs vector similarity retrieval and two-stage sorting, and sends the resulting candidate historical risk cases to the constraint verification module. Candidate historical risk cases include case identifier, risk category, risk characteristics, historical handling measures, execution cost, implementation time, execution result, and applicable conditions.

[0161] The contract rules processing module is connected to the event fusion and index management module. The contract rules processing module obtains the current valid contract version from the current project's valid event chain, and extracts the contract amount, payment nodes, delivery milestones, breach of contract clauses, and acceptance criteria from the current valid contract version to form a structured rule template containing the contract number, clause number, clause version, and effective period.

[0162] The contract rule processing module sends the structured rule template to the constraint verification module. The risk case retrieval module and the contract rule processing module are jointly connected to the constraint verification module, enabling the constraint verification module to simultaneously obtain candidate historical risk cases and currently valid contract constraints.

[0163] The constraint verification module also receives the current project's budget margin, schedule leeway, and personnel availability status. It parses historical responses from candidate historical risk cases into candidate suggested parameters, including action type, target audience, estimated cost, estimated duration, number of personnel, skill requirements, subcontracting status, and impact on milestones. Based on the structured rule template and project resource status, the module performs hard constraint verification and soft constraint verification respectively.

[0164] The constraint verification module removes candidate risk mitigation suggestions that violate contract amount limits, payment terms, delivery milestones, acceptance standards, or breach of contract restrictions. For candidate risk mitigation suggestions that do not violate hard constraints but have insufficient budget margins, low schedule leeway, or insufficient personnel availability, the constraint verification module lowers their priority ranking according to the number and degree of violation of soft constraints and records the reasons for the conflicts.

[0165] The constraint verification module connects to the suggestion traceability output module. The suggestion traceability output module receives the verification results output by the constraint verification module, outputs risk handling suggestions that pass the constraint verification, and stores the correspondence between the risk handling suggestions and the project event version, historical risk case identifier, contract clause version, and constraint verification results.

[0166] If no candidate risk mitigation recommendations pass hard constraint validation, it is recommended that the source tracing output module output constraint conflict information and a manual confirmation flag. After a new mitigation result is formed through manual confirmation, this result can be written into the current project's valid event chain as a new version project event.

[0167] The health monitoring module is connected to the event fusion and index management module. The health monitoring module reads progress indicators, cost indicators, risk indicators, and quality indicators from the current project's valid event chain, determines the weight of each indicator according to the project stage, and calculates the project's execution health.

[0168] The health monitoring module also connects to an independent heartbeat detection node. Through this node, it obtains the monitoring platform's heartbeat status, service online status, and backup switchover status, and determines the platform's availability accordingly. The health monitoring module generates project risk alerts based on project execution health and platform operation and maintenance alerts based on platform availability.

[0169] When the monitoring platform malfunction continues to exceed the preset malfunction threshold, the health monitoring module retains the last valid value, calculation time, and data version of the project execution health, and marks the project execution health as temporarily unupdateable. After the monitoring platform recovers, the event fusion and index management module first processes the project data generated during the malfunction, and then the health monitoring module recalculates the project execution health.

[0170] Each module can be deployed on the same server, or separately on interconnected servers, virtual machines, containers, or compute nodes. Modules can exchange project events, index records, risk query vectors, candidate historical risk cases, structured rule templates, and constraint validation results through internal interfaces, message queues, shared databases, or remote call interfaces.

[0171] In one implementation, project data is stored using AES-256 encryption, and application programming interface (API) calls use token authentication. The system has three levels of access permissions: administrator, analyst, and executor. Administrators have permissions for index configuration, project event version maintenance, and user permission management; analysts have permissions for project querying, risk analysis, and viewing verification results; and executors can access risk management recommendations output after constraint verification.

[0172] In one implementation, projects with a small number of events and low concurrent query volume use the Chroma vector database; projects with a large number of events and high concurrent query volume use a Milvus distributed cluster. The specific type of vector database does not change the structural relationship between the text vector index, structured feature vector index, and risk feature vector index, which are independent of each other and linked by a unified project event identifier.

[0173] In this embodiment, after the multi-source project data enters the event fusion and index management module through the data acquisition module, it forms a risk case retrieval branch, a contract rule processing branch, and a health monitoring branch, respectively. The risk case retrieval results and the contract rule processing results enter the constraint verification module together, and then the suggestion tracing output module outputs suggestions, conflict information, and tracing relationships, so that the connection relationship, data flow, and processing function of the system modules correspond to the method processing process in Embodiment 1.

[0174] Example 3

[0175] This embodiment provides an electronic device. The electronic device includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor. The processor is communicatively connected to the memory. When the processor executes the computer program, it implements the project risk monitoring method based on a versioned project event chain as described in Embodiment 1.

[0176] Specifically, when the processor executes the computer program, it acquires contract, supplementary agreement, invoice, payment, progress, acceptance, and work hour data; generates a unified project event identifier and constructs a valid event chain for the current project; establishes a text vector index, a structured feature vector index, and a risk feature vector index, and performs incremental updates when project events are added or changed; retrieves historical risk cases based on the valid event chain of the current project, performs contractual and resource constraint verification on candidate risk handling suggestions, and outputs risk handling suggestions or constraint conflict information. The processor can also perform cost prediction and calculate project execution health and monitoring platform availability.

[0177] The processor can be a central processing unit, graphics processing unit, digital signal processor, or other processing unit with data processing capabilities; the memory can be random access memory, read-only memory, solid-state memory, or other storage devices capable of storing computer programs and project data. Through this embodiment, the aforementioned project risk monitoring method can be executed by a processor in an electronic device, realizing project event version management, risk retrieval, constraint verification, and suggestion output.

[0178] Example 4

[0179] This embodiment provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the project risk monitoring method based on a versioned project event chain as described in Embodiment 1.

[0180] When the computer program is executed, it enables the processor to complete the following tasks: acquiring multi-source project data, generating unified project event identifiers, constructing the current project's valid event chain, establishing and incrementally updating heterogeneous vector indexes, retrieving historical risk cases, validating candidate risk handling suggestions by constraints, outputting suggestions for tracing their origins, predicting costs, and monitoring health status. The computer-readable storage medium can be a read-only memory, random access memory, solid-state drive, hard disk, optical disk, flash memory, or other non-transitory storage medium capable of storing the computer program.

[0181] Through this embodiment, a computer program can carry the aforementioned project risk monitoring method in a storable and executable form, and complete the corresponding data processing process after being called by a processor.

Claims

1. A project risk monitoring method based on a versioned project event chain, characterized in that, Performed by the project monitoring system, including the following steps: S1. Obtain contract, supplementary agreement, invoice, payment, progress, acceptance and working hour data from different business systems, generate a unified project event identifier based on project number, contract number, business document number, event time and event type, and construct the current project valid event chain based on the source, version, effective time and valid status of each project event; S2. Vectorize the text data, structured data, and historical risk cases in the project events respectively, and establish independent text vector indexes, structured feature vector indexes, and risk feature vector indexes. Then, associate the index records in each vector index with a unified project event identifier. When a new project event is added, the new project event is written to the corresponding vector index. When the content or status of a project event changes, the original version of the project event and its index record are marked as invalid, and the vector index corresponding to the changed project event is incrementally updated. S3. Extract the risk characteristics of the current project from the current project's valid event chain, generate a risk query vector, filter historical risk cases according to industry, project type, risk category, case validity status and time range, and perform vector similarity retrieval and sorting on the filtered historical risk cases to obtain candidate historical risk cases; S4. Generate candidate risk handling suggestions based on the historical handling measures in the candidate historical risk cases, and obtain contract constraints and resource constraints from the current effective contract version and the current project resource status. Perform hard constraint verification and soft constraint verification on the candidate risk handling suggestions, eliminate candidate risk handling suggestions that violate hard constraints, reduce the ranking priority of candidate risk handling suggestions that violate soft constraints, and record the corresponding conflict reasons. S5. Output risk management recommendations that pass constraint verification, and establish the correspondence between risk management recommendations and project event versions, historical risk case identifiers, contract clause versions, and constraint verification results; If no candidate risk handling suggestions pass the hard constraint verification, output constraint conflict information and manual confirmation mark.

2. The project risk monitoring method based on versioned project event chain according to claim 1, characterized in that, Step S1 includes: Prioritize deterministic association of data from different business systems based on project number, contract number, and business document number; When a stable business primary key is missing, candidate related records are generated based on the business subject, amount, event time and event type. The association confidence of the candidate related records is calculated, and candidate related records with an association confidence of less than a preset association threshold are set to a pending confirmation status. Within the same source system, data deduplication is performed based on the source system and the source business primary key; or, in the absence of a stable business primary key, data deduplication is performed based on key field summaries or file hashes. When data from different source systems conflict in a field, the current valid value is determined sequentially according to the signed and effective contract or supplementary agreement, the audited financial system data, the audited project management system data, and the optical character recognition imported data, and the corresponding conflict record is retained; When it is confirmed that records from different sources or different versions belong to the same business matter, the unified project event identifier of the business matter is used, and a project event version identifier and a predecessor version identifier are set for each version, so as to establish a project event version chain according to the predecessor version identifier; the contract, financial, progress, acceptance and work hour events are arranged according to the event time, and the business relationship between each project event is recorded through the associated event identifier; Organize the main contract, supplementary agreements, and contract amendments into a contract version chain, so that the supplementary agreement covers the contract terms that are explicitly changed by it, and the contract terms that are not changed by the supplementary agreement are inherited from the previous valid contract version. When the current project's effective event chain changes or the preset monitoring period is reached, steps S3 to S5 are re-executed.

3. The project risk monitoring method based on versioned project event chain according to claim 1, characterized in that, Step S2 includes: The contract text and contract terms, as well as risk descriptions and historical handling measures from historical risk cases, are encoded into 768-dimensional text vectors and written into a set of text vectors; The financial expenditure data, working hours data, progress data, and acceptance data, as well as the financial, working hours, progress, and acceptance fields corresponding to historical risk cases, are encoded and normalized according to a preset field list to form a 32- to 128-dimensional structured feature vector, and written into a structured feature vector set. Historical risk cases are encoded into 8-dimensional risk feature vectors and written into a risk feature vector set; HNSW indexes are established for the text vector set, the structured feature vector set, and the risk feature vector set respectively, and the vector dimensions within the same HNSW index are kept consistent. In particular, independent structured feature sub-indexes are established for structured feature vectors of different dimensions. Based on the current project's valid event chain, generate text query vectors, structured query vectors, and risk query vectors with dimensions consistent with the text vector index, structured feature vector index, and risk feature vector index, respectively, and recall historical risk cases. The index records of each historical risk case are associated with the source project event through a unified project event identifier, and the candidate results are merged through the historical risk case identifier. After normalizing the similarity of each path, the merged candidate results are sorted according to the preset fusion weight.

4. The project risk monitoring method based on versioned project event chain according to claim 1, characterized in that, The risk query vector and the risk feature vector corresponding to the historical risk cases both include project size, project type, project cycle, team size, technology stack complexity, geographical distribution, customer industry, and historical deviation rate. Risk categories are determined based on overpayment, underpayment, schedule deviation, quality anomaly, staff shortage, or external environment changes in the current project's effective event chain. Cost deviation rate, schedule deviation rate, or time deviation rate are selected as the historical deviation rate based on the determined risk category. Step S3 includes: The initial similarity threshold for historical risk cases is set to 0.8; When there are fewer than 3 valid historical risk cases with a similarity of not less than 0.8, the similarity threshold will be lowered to 0.

7. Historical risk cases with a similarity of not less than 0.8 are designated as preferred cases, while historical risk cases with a similarity of not less than 0.7 but less than 0.8 are designated as reference cases. Reference cases are restricted from being used alone as the basis for generating final risk management recommendations. When no preferred cases exist, only reference cases, corresponding similarities, and manual confirmation tags are output. The initial candidate cases obtained through metadata filtering and similarity retrieval are sorted in two stages, and the top-ranked historical risk cases are identified as candidate historical risk cases.

5. The project risk monitoring method based on versioned project event chain according to claim 1, characterized in that, Step S4 includes: Extract contract amount, payment nodes, delivery milestones, breach of contract clauses and acceptance criteria from the contract text and supplementary agreement text to form a structured rule template containing contract number, clause number, clause version and effective period, subject of constraint, type of constraint, comparison relationship and constraint value; Based on the actual project expenditure time and expense category, the actual project expenditure is matched with the structured rule template to determine the revenue attribution period and cost collection category, and to identify project events that are overpaid, underpaid, or deviate from the contractual agreement. The historical handling measures in the candidate historical risk cases are parsed into candidate suggestion parameters. The candidate suggestion parameters include at least the action type, target, estimated cost, estimated construction period, number of personnel, skill requirements, whether subcontracting is required, and impact milestones. Based on the constraint attributes of each contract clause in the structured rules template, the corresponding contract clause is set as a hard constraint or soft constraint for the candidate risk disposal suggestion. Contractual constraints include the upper limit of contract amount, payment terms, delivery milestones, acceptance criteria, and breach restrictions. Resource constraints include budget margin, schedule leeway, and personnel availability. Candidate suggestion parameters are verified item by item based on contractual and resource constraints. The priority of corresponding candidate risk management suggestions is reduced according to the number and degree of violation of soft constraints.

6. The project risk monitoring method based on versioned project event chain according to claim 1, characterized in that, Also includes: The earned value, planned value, actual cost, number of days the project has been executed, total planned days, remaining budget amount, and current risk exposure value of the current project are obtained at each sampling time within a continuous preset window, and a project cost characteristic sequence is formed according to the sampling time order; Input the project cost feature sequence into a cost prediction model that includes a Transformer encoder, a cost sequence regression output layer, and a cost overrun probability classification output layer to obtain a cost prediction sequence and cost overrun probability within a future preset time range. The cost prediction sequence and the probability of cost overrun are written into the current project's valid event chain, and the probability of cost overrun is used as an auxiliary input for risk category determination and the second-stage ranking of candidate historical risk cases, without changing the dimensions of the 8-dimensional risk query vector. After obtaining new actual cost data, a corresponding new version of the project event is generated, and the input data and corresponding vector index of the cost prediction model are updated.

7. The project risk monitoring method based on versioned project event chain according to claim 1, characterized in that, Also includes: Projects with a cumulative completion rate higher than 80% or those that have entered the acceptance and settlement stage will be prioritized for classification as later stages; For projects not classified as late stage, projects with a cumulative completion rate of not less than 30% and not more than 80% and in the implementation or delivery phase are classified as mid-stage projects, and the remaining projects are classified as early stage projects. The weights of schedule indicators, cost indicators, risk indicators and quality indicators are determined according to the stage of the project. Standardize schedule, cost, risk, and quality indicators, and calculate project execution health using the following formula: ； in, =1, 2, 3, and 4 correspond to schedule indicators, cost indicators, risk indicators, and quality indicators, respectively. For the first The weight of each indicator For the first The standardized value of the indicator; The monitoring platform's heartbeat status, service online status, and backup switch status are obtained through independent heartbeat detection nodes, and the availability of the monitoring platform is determined based on these statuses. When the duration of the monitoring platform failure exceeds the preset failure threshold, the availability of the monitoring platform will be set to unavailable, the last valid value of the project execution health, the calculation time and the data version will be retained, and the project execution health will be marked as temporarily unupdateable. Project risk alerts are generated based on the project's health status, and platform operation and maintenance alerts are generated based on the monitoring platform's availability.

8. A project risk monitoring system based on a versioned project event chain, characterized in that, include: The data acquisition module is connected to external contract business systems, financial business systems and project management business systems to acquire contract, supplementary agreement, invoice, payment, progress, acceptance and working hour data. The data acquisition module is connected to the event fusion and index management module. The event fusion and index management module is used to generate a unified project event identifier based on the acquired data, establish a project event version chain and a current project valid event chain, establish a text vector index, a structured feature vector index and a risk feature vector index respectively, and incrementally update the corresponding vector index when a project event is added, its content is changed or its status is changed. The event fusion and index management module is connected to the risk case retrieval module. The risk case retrieval module is used to extract risk features from the current project's valid event chain and generate risk query vectors. It performs vector similarity retrieval and sorting on historical risk cases filtered by metadata to obtain candidate historical risk cases. The event fusion and index management module is also connected to the contract rule processing module. The contract rule processing module is used to extract the contract amount, payment node, delivery milestone, breach of contract clause and acceptance criteria from the current valid contract version to form a structured rule template containing the contract number, clause number, clause version and effective period. The risk case retrieval module and the contract rule processing module are jointly connected to the constraint verification module. The constraint verification module is used to generate candidate risk handling suggestions based on the historical handling measures in the candidate historical risk cases, and to perform hard constraint verification and soft constraint verification on the candidate risk handling suggestions based on the structured rule template, budget margin, schedule margin and personnel availability. The constraint verification module is connected to the suggestion traceability output module. The suggestion traceability output module is used to output risk handling suggestions that have passed the constraint verification, and to store the correspondence between the risk handling suggestions and the project event version, historical risk case identifier, contract clause version and constraint verification results. The event fusion and index management module is also connected to a health monitoring module. The health monitoring module is used to calculate the project execution health based on the current project's valid event chain, determine the monitoring platform's availability based on the monitoring platform's heartbeat status, service online status, and backup switch status, and output project risk alarms and platform operation and maintenance alarms respectively.

9. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the processor executes the computer program, it implements the project risk monitoring method based on a versioned project event chain as described in any one of claims 1 to 7.

10. 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 project risk monitoring method based on a versioned project event chain as described in any one of claims 1 to 7.

Images